The term “technical debt” was first introduced by Ward Cunningham as a metaphor. It was in the early 90s, when the rift between developers and business people was growing wide. The business people would urge developers do release untested, ugly code. The developers tried to explain why this was a bad mistake. (Not like today, right?)

The metaphor of debt in code and design goes like this: We start at an optimal level of code. In the next release, we’re adding a new feature. This would take E effort (assuming estimations are viable. Work with me here).

If our level of code was less than optimal, the effort will be E + T. Where T is the technical debt. Writing bad code is like going further into debt. We take the loan now, and we repay the debt later. The bigger the mess, the larger the delay in the next release.

It’s a good metaphor. And like everything good, we managed to botch it too.

Most projects are still released much earlier than the developers have wanted. Assuming that developers are not just being stubborn (again, work with me), you would think that the metaphor has failed us. We didn’t manage to get the message across to the business.

Au Contraire!

We’ve done an awesome job explaining. The business people understand it. They are just willing to take the loan now.

Can you blame them? First, they want something out there, in the field, that will sell now. According to their experience with developers, business people don’t know when, or even if, the next release will happen. In our complex world, we don’t know what will happen in time for the next release. Maybe working on the code now will make it easier to work on for the next release, but the next release may include completely different features, on different code.

Let’s assume that there is a discussion at one point before release. It’s about delaying the release and making the code better or releasing now. My money is on the decision of early release at the cost of less quality. The business would rather have something now, and damn the torpedoes.

But it’s not just that.

Complexity is very cruel. It makes it hard to evaluate the actual technical debt in hindsight. So you can say to your boss, “that decision you made last time cost us extra 3 weeks”, but the number would be completely made up. We can’t really know how much was really spent extra just because the code wasn’t good enough. What if it was, but a whole new team worked on it that didn’t know it before?

If hindsight doesn’t work, you can probably guess that the estimated repayment on current technical debt is even more problematic. Unfortunately, that doesn’t stop people from trying.

In SonarQube, for example, has a module that lets you calculate your technical debt. It takes into account code duplication, coverage and complexity metrics, along with all kinds of numbers, puts them all in a bowl and comes up with a number you can show your boss at the point of decision. How cool is that?

Ok, first things first: don’t show this to your boss. She will not be impressed with a made up number, concocted by a black magic formula. Besides, if you have something that predicts the future, use it to become your own boss.

When I first saw this, the tech debt number (in man-days) was presented for everyone (yay for visibility!). Most people ignored it, because the number was so big, contemplating a plan of how to close the gap (as if it was accurate) was really out of the question.

We’re using tools, again to avoid uncertainty, and create a simple mirage. Some people will even believe it. And make decisions based on it. As with any estimates, if you don’t have data, they aren’t worth much. And no, you can’t translate code duplication into man-hours, unless your developers are mindless typists.

Technical debt is a good metaphor to explain, but it fails in both the goal we want it to achieve, and burns any trace of reliability on the way.

It’s time to let it go.