Episode 41

I’ve seen recently a nice movie based on actual events – the Deepwater Horizon. Aside from being well made and entertaining, the movie had an additional value to me. It was a story of what happens to a project with insufficient tests and short sighted management putting pressure to release unfinished product with monstrous technical debt. It blows up in huge ball of fire.

Technical debt

Ward Cunningham coined the term technical debt while working on financial software. The idea is, that when developing software, you can often go in two directions. You can spend more time and implement the new functionality cleanly, soundly and with respect to existing architecture. If the functionality does not fit the existing architecture or design, you apply appropriate effort to alter it. The second direction is to focus on delivering working code quicker, but without focusing on entire system and its future. This way the overall state of code base worsens, and should be fixed later in order to keep the development speed at the current level. The time, or the money, we save now is a debt that needs to be paid later. The later it is paid, the more interests you will have to pay in addition to the money you saved now.

Silent strangler

Sadly, in many software projects the technical debt is not being taken care of. Non-technical business people often don’t understand the mechanism and pressure developers to add additional features as fast and possible, incurring more and more debt, and not paying the debt already present. It leads to development that is gradually, asymptotically slowing down. Each feature takes more time to do, because it is harder and harder to find out how to change irregular, chaotic, ugly and incomprehensible system. The quality drops alongside, because such systems are more error prone. The further it goes, the more time is required to make things better, and more difficult it becomes to explain this to business people. “Are you saying that we need to stop earning money for three months and do some magic changes that have no value? Are you insane? The client is not paying for this, blah, blah, blah…” We have all been there. The problem is, that revenue from features is here and now, and is measurable, while dealing with technical debt pays off only in a longer run, and exact numbers here are very hard to estimate.

Conscious choice

Technical debt is not necessarily bad. Same as debt in real life. We choose to be in debt, because we can use it to our advantage – start a profitable business, buy a comfortable house, reach possibilities we otherwise wouldn’t be able to. Perhaps our company is in a situation where delivering a feature with a given deadline is super business critical. We earn pile of money we wouldn’t ever see had we instead choose to implement the feature carefully and with appropriate rewrites and changes in the design. Often this is an optimal strategy. Also often however, the fact that there is a debt that needs to be paid is subsequently silenced, which leads to problems. Keep in mind that, as uncle Bob said, technical debt should be a conscious choice, not an accident. Crap code is just a crap code, mess is just a mess, not technical debt. Do not excuse technical incompetence or laziness with technical debt.

Big picture

Some developers, often inexperienced yet vigorous, have a tendency to save the world and pay the debt on their own. Sometimes the problem is that they are too eager and lacking a wider perspective, which might be especially problematic in large systems. And that perspective might be that some particular module or large piece of functionality  is scheduled to be rewritten from scratch, perhaps to do more flexible engine or other extended functionalities that would be too difficult to do in existing code base. I was this person some time ago, but I have grown out of it, not exactly smoothly at some points. Paying debt should be a conscious and calculated action, as well as creating it in the first place.

Communication

So, if you see that your code is rotting more and more, your development is slowing down to a crawl, new features are more and more painful to implement, that is likely a sign, that you have a lot of debt. At some point, you have to stop generating more and pay back. Yes, this means you will not implement features, but this is the only way. It is so basic, really. Any reasonable person understands that in real world, if you engage in a debt, you have to pay back at some point or you will have to face the unpleasant consequences. It won’t cease to amaze me why some business people don’t understand this in software development or simply choose to ignore the reality. What to do then? As a professional developer your responsibility is to educate people who require education. Sometimes the problem has more depth. Your product owner might understand. His boss might understand. But another person in the chain might not. You may show them those fancy charts with exponentially rising values and explain that they will pay anyway, just more. And as quality deteriorates alongside rising debt, in extreme cases, the payment might come as damages for a platform that finished in a spectacular explosion, like Deepwater Horizon.