Recently my colleague Jeffrey Thalhammer of Imaginative Software
sent me a pointer to Steve McConnell's article on Technical Debt: http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
Instead of sending Jeff an email with all my notes, I'm sending him a pointer to this posting.
Overall I thought the article plus the comments were very good. The comments and back-and-forth really add a lot of value the the article and I suggest anyone reading the article make their way all the way through the comments.
I think we should write a version of this aimed entirely at non-technical people.
McConnell does acknowledge that estimating the "interest payments" is very difficult. One of the (maybe not so obvious?) reasons is that involves calculating the expected lifetime of the system, because as the article says:
When a system is retired, all of the system's technical debt is retired with it. Once a system has been taken out of production, there's no difference between a "clean and correct" solution and a "quick and dirty" solution.
So having a realistic estimate of the expected lifetime of the system make a huge difference it the expected cost of the debt.
I also like the attention that the article and comments gave to the issue of why different people may have different attitudes towards technical debt. For example, the article says:
The reason most often cited by technical staff for avoiding debt altogether is the challenge of communicating the existence of technical debt to business staff and the challenge of helping business staff remember the implications of the technical debt that has previously been incurred.
and commenter Robin Barooah said:
This might further explain why business people are prepared to accept technical debt - they aren't the ones who are going to have to pay it off. The developers suffer real consequences because they aren't learning or growing by having to rework code that they knew was being done to substandard quality in the first place.
I think Barooah's comment is spot-on and indicates an often unarticulated and under appreciated difference between financial and technical debt.
The article summarizes some of this by saying that:
The main issue seems to be that, unlike financial debt, technical debt is much less visible, and so people have an easier time ignoring it.
I would amend that to say "so some
people have" cf. Barooah's comment above, but I basically agree: making the "technical debt" more visible is fundamental to improving how it is handled. That means means finding ways to make it visible to people with different perspectives: Finding indicators that are equally meaningful to both business and technical staff would be a big help.
Technorati Tags: agile, estimating, programming, software development