Coding on a Credit Card

For the last year or so, I’ve been hanging around quite a few legacy software systems. I’ve even had the joy of maintaining one: we all know it has been dying for a few years, and now that its end is in sight, I’m just trying to make it as comfortable as possible as its soul retires into the legacy software afterlife. It has become Just Another Legacy System (JALS). The thing about these JALSs is that the code sucks. It looks like virtual baby vomit. How did this JALS get so bad, you wonder?

Gregor Hohpe tried to answer this question in a talk he gave a little while ago, “Where did all the beautiful code go?” As he points out, I don’t think anyone really sits down at the start of a project and says, “Let’s write some crap code! Now ship it!” It’s just that somewhere along the way, there is a critical point when someone makes a decision that weighs technical elegance and beauty against a business requirement to ship some software. Evil is tempting, so inevitably when faced with such a decision — which happens virtually every other day in my world — there is a collective sigh among participants that says, “OK, we’ll put in this hack. It’s not a good solution, and we know it will make code changes more difficult in the future, but we’ll do it so we can move forward more quickly.” Sounds relatively innocent, right? The problem is that once a group or individual allows this bit of evil slip into the code, it lowers the bar. The next time the project is faced with a similar decision, the temptation to side with evil is even stronger now that you’ve polluted the water: “The last hack didn’t turn out too bad… another can’t hurt!” Developers aren’t going to care so much about pristine code anymore, and on it goes until you end up with JALS.

If you want to look at this in economic terms, the software takes on some technical debt every time a team decides to go for the quick, dirty (and evil) solution. It’s kind of like coding on a credit card and you’re only making the minimum payments. Of course, taking on short-term debt can be an optimal long-term approach in some business and personal situations. We all know that. The key difference between technical debt and monetary debt, however, is that your cost of borrowing “technical currency” increases with every transaction, whereas the cost of borrowing monetary currency is constant over multiple transactions (assuming the same interest rate). At its root, the cost of borrowing technical currency is derived not only from the cost necessary to “undo” the damage, or pay back the technical debt, but also from the simple fact that maintaining code of declining quality costs much more than maintaining clean code. Even worse, given the declining quality of the code and complex series of last-minute hacks, the operational costs of keeping JALS running soar off the charts! Our poor JALS developers become increasingly demoralized and broken… until they find new jobs, of course. Given this unfortunate scenario, our JALS quickly reaches mafia-level interest rates. With broken kneecaps and missing teeth (those hit men can be nasty!), JALS drags itself along, carrying its team of tired developers behind it.

I think one reason that we see so many examples of JALS is that many developers and (especially) managers fail to understand the economics of what they’re doing. They assume that the cost of taking on technical debt is constant, which as I have demonstrated, is not the case. If a developer is lucky enough to have an extremely technically-adept manager who is also still a developer, I think these economics are more thoroughly understood. These managers are themselves rare. So, in most cases, it’s up to the developer to stop the formation of JALS, and those developers who do so will be rewarded by their peers. At least I’ll certainly give you a pat on the back.