Technical Debt

Technical debt is a concept which I never fully realized how accurately it is named. (I have to thank some colleagues for listening and discussing this subject on several occasions)

For those not ‘in the know’…technical debt refers to dirty pieces of code/db design/UI clutter/… that build up over the time of a project. They can be due to changing requirements, time pressure, developer oversights, … . Essentially it’s the stuff you don’t want but somehow hardly ever get round to really cleaning up, as they don’t necessarily generate bugs or functional problems. And rest assured, every piece of software (of a significant size) has it. As all developers know, there is no such thing as perfect code so there’s always an area to refactor, improve or otherwise clean out.

Back to the name though…Technical debt really is a debt. Extremely comparable to monetary debt. In a typical situation monetary debt comes from you buying something that costs more than you can afford at that time. So what you do is: you get an instance to give you what you want and you work out a plan to repay them. That plan entails a couple of things. It looks at what you can afford to pay them based on your current paycheck, it looks at the length of time it will take before you are without debt again and they will charge you an extra fee on top of the amount you borrow for their service. But above all, based on these conditions they will set a limit to the amount of debt you can accumulate.

Oddly enough, technical debt isn’t all that different. You create that same amount of debt when building software, for reasons I mentioned before. However the big difference is that there is no governing body that puts a limit on the debt you can accumulate. It doesn’t take a rocket scientist to figure out this is indeed a baaaaad situation. If you keep on building your debt it means that maintenance becomes harder (i.e. you *pay* more for doing a small change than in a clean codebase), new features become “just another hack” in the software, there are exception routines everywhere and this spiral keeps spinning down. Eventually this will drag down your development velocity and ultimately will grind your project to a halt.

This is where, for me, good product ownership (/project management) comes in. The product owner can help here in several ways…

1. Understand how technical debt gets created (i.e. understand the implications of selecting a specific implementation)
2. Allow developers time to gradually work away that debt. This also means standing up to the business and actively refusing new features* (just like you wouldn’t buy that Porsche if you know that you can’t pay off your house anymore if you did)

*actively refusing is obviously more than saying no. It means working out a plan on where features can fit in and/or look at the scope. The essence is really to work away technical debt as part of the entire planning routine.