Technical Debt: How much have you been paying for that?

Long time ago Ward Cunningham brought the idea around the term “technical debt”[1]. After it others like Steve MaConnell[2] introduced more thoughts on this metaphor. It is quite interesting see this ongoing in a real scenario. And in additional to that to see the team getting used with the situation, defraying interest each release cycle, and more, without hope to amortize the debt during the software life time.

In a previous post I wrote about the “Quick-and-Dirty”[3] approach, where I put the phrase: “we need to keep in mind a way to clean it as time goes by.”. I guess it can explain what you must do after decide to acquire a debt, because you need to address some issues that in a specific moment are more important than the design/code quality. Situations like that can happen, for example time-to-market or even when stackholders push pressure.

I think that the technical debt can be in evidence on different spots(design, code, dependence management, and others), and this is really “fun” when the “software” decides to charge you. Just pay attention the moment before and after each delivery. Where are the stress points, and if they are continuous, I mean, the team are always complain about the same things. The test process is always messy and not easy to reproduce, build process is always broken and just one guy on the team knows about that, we don’t have a static code analyze tool in place, because otherwise it will show those several “poor” design/code that we built and we forgot to clean and we are saying most of the time: “throw away this software and go to implement from scratch”. When you are in this stage, your debt is really bad.

Now imagine this situation: you got a money from a bank, and just postpone to pay, when you think that you have the enough money you discover that the current debt amount is so high that you need at least to work one more year saving money to pay the debt. It is exactly what happens when you decide improve/refactor the design/code or poor solutions that you did a long long time ago. Then, if you take a technical debt, keep always looking back shortly to your stuff, otherwise it will be impossible to improve.

[1] – http://c2.com/doc/oopsla92.html
[2] – http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
[3] – http://mmayworm.blogspot.com/2009/04/where-is-boundary-between-rapid-and.html