Hacker News Reader

Comment by einhverfr | Hacker News Reader

Well, with LedgerSMB (http://www.ledgersmb.org), we forked from an absolutely horrid codebase. The author has been described by Matt Trout as "The guy Matt's Scripting Archive would have fired for bad coding." I mean the codebase was a total mess. Total, total, total mess.

After 6 years of refactoring we now have a framework in place to start on the financial logic. It shouldn't take us more than 6 years to get the rest rewritten.

One of the hidden costs of bad code is that it is contagious. After staring at bad code, it is very hard to write very good code. So it takes several revisions to go from bad code to good code, to get the patterns right, etc.

View on HN

>One of the hidden costs of bad code is that it is contagious.

That's why the debt analogy fits so well - because technical debt compounds. If your codebase is already heavily in technical debt, when developing new features or fixing bugs you are faced with three equally unpalatable options:

1) Do it properly (takes: 1 month)

2) Don't make it worse; don't make it better (takes: 1 week)

3) Just do a quick hack to work around all of the other hacks (takes: 30 minutes)

As a developer with a pushy boss who doesn't understand technical debt and a tight deadline, the rational choice is pretty obvious: take 3, go home at a reasonable hour to your family, still meet the deadline and drown your professional sorrows in alcohol.

But that isn't taking into effect the contagion issue. In theory your view is the way it works. In practice doing it "properly" comes out half-properly because you spent all your other time maintaining horrible code so that it infects your thought processes and design.

The problem is this. Let me put it clearly:

If you are maintaining bad code, it will take you several tries to come up with a good architecture to replace it. You will make better progress having someone entirely outside do the architecture themselves.

OTOH, if employers are going to use credit scores to decide whether to hire you, then technical debt may be an even better metaphor if you factor that in ;-)

12 years to clean up? That must be worse than starting from scratch.

Well, a 200k line codebase, maintaining it for current users. Yeah might have been better to start from scratch.

OTOH what one gets by going this way is a community of users, and therefore it will still beat Hurd 1.0 to completion. Starting an ERP from scratch without funding as a multi-vendor effort would lead to something that would never be released.

But you should see the legacy code. The code we forked from was a textbook of how not to write (secure, maintainable, bug-free, etc) software.

Reply on news.ycombinator.com