Technical debt in agile development

There is an interesting post called Agile: Does Technical Debt Exist?. It’s already one and half years old but I’ve just noticed it. It claims that there is no such thing as technical debt in an agile development environments. Even though it does contain some good arguments and actually points at some common mistakes made when defining technical debt, it comes to the wrong conclusion.

First, there is always a trade off between short term features and time to market versus long term goals. This is still a sort of technical debt even though it is a conscious business decision to focus on short term customer satisfaction and not address long term goals. Technical debt is not only about the trade off between bad code and reaching a release date. It’s very often a conscious decision, very often not only a technical decision but a business decision.
Similarly, taking a loan to buy a house when your kids can still enjoy living in a house has nothing to do with poor financial judgement. It just means you accept the fact that you’ll have to repay the loan with interest in the future but it is more important to you to live in a nice house while the kids are still kids. From a purely financial point of view, you’re of course better off just saving money for 20 years and then buy a house without loan. It’s the cheapest option. But maybe you do not need a house in 20 years from now… So although the term debt often has a negative aftertaste, it doesn’t have to be bad.

Bad code on the other hand, code which will ‘bite you in the ass’, is something completely different. It is not technical debt though. If it will bite you in the ass in the future but not now, then you are simply balancing future velocity against current velocity as long as velocity is measuring something relevant (end user features).

I think this quote shows that the author as a certain idea of what technical debt is and assumes that technical debt is just the result of stupid decision involving not doing something now without getting any advantage now. It is really the case. I think technical debt is created in most cases based on a conscious decision because the short term effect is more valuable than the long term cost. Of course there are cases where technical debt is created because of a lack of knowledge or understanding of your own tools and products. But I really think it’s not the 80% case.

No debt is incurred, just choices made.

Well, in most cases debt is incurred because of conscious decisions, choices. Making choices doesn’t mean, no debt is incurred.

Technical debt is a dangerous notion because it achieves nothing apart from making everyone pissed off with everyone else.

I guess it does happen very often that the notion of technical debt creates a circle of finger pointing. But I do not think that the technical debt metaphor is always the cause for this. I think it’s mostly related to the culture in the organization. With measurements of the technical debt, you make things apparent which would otherwise only come to the surface when you have to implement a feature affected by the debt and it takes more time than expected. If there is a finger pointing culture in the organization, it will happen latest at this point in time. Whether the technical debt metaphor is used or not…

Technical debt can be a mean to argue for meaningful clean up activities which do not bring immediately visible results but represent a mid to long term huge benefit. But like all weapons it can be used in a wrong way. You need to be careful how you use it and make sure it is not used as a trigger to discuss how bad developers are. The author is right when he says that these shortcuts taken in development projects are very often not only decided by the developers themselves but are often decisions made by the whole organization based on the benefits to the end user / customer.

Leave a Reply

Your email address will not be published.