In this article I want to talk about a term that I think is just brilliant: technical debt! The term technical debt makes an analogy: it considers the use of quick, but poor, technical solutions to store up a form of debt. As with more conventional forms of debt, the immediate problem is solved, but trouble can be stored up for the future. The reason I like the term so much is because, by its use of analogy, it makes it much easier to communicate a concept that is, otherwise, rather tricky to explain.
All too frequently in software development, technical/design problems are solved sub-optimally in the interests of speed. Actually that is putting it too nicely. Such problems are often solved using quick and dirty hacks. This is usually done in the belief that it will get a solution in place quickly. Often the belief is actually correct, and this approach does indeed get a solution in place quickly. However, there is a price to be paid. The price manifests itself in the form of code being difficult to work with in the future, and therefore the risk to future deliveries is much increased.
Here lies the importance of the debt analogy: there is nothing wrong in principle with technical debt, but like any other kind of debt it must be managed, and it must be managed effectively. If debt is to be entered into then it is imperative that the debtor is in control of the debt – the debt must not be allowed to control the debtor!
The need to make a delivery in time, typically so as not to miss a market window, may make it necessary to accept a "quick hack" solution. However, such a solution can not be allowed to remain in place; if it is, then soon it will become difficult – and even practically impossible – to meet deadlines. For this reason, some planning is necessary; time must be made factored into the development schedule for solutions carrying such a technical debt to be reworked with more enduring solutions. Failure to do this leads to developers being unable to work with the code base, and ultimately the code base needing to be rewritten from scratch.
Typically, such rework is not carried out because (non-technical) management decide to spend the development time on new features – after all, the code works so why spend time rewriting any of it? Software developers then become frustrated because they perceive this as incompetence on the part of their management. This attitude is wrong on the part of developers! Technical debt is in the technical domain, and therefore it is not something non-technical management should be expected to understand – at least, not without it being explained to them in such a way that they, as non-technical people, can understand it. The responsibility here lies with the senior software developers, who have a responsibility do learn to communicate this issue to their management.
3 Comments
Mark,
you fail to make the main point of the “Technical Debt” metaphore clear.
This is that developers are wrong to assume that “time must be made factored into the development schedule … reworked with more enduring solutions”.
Consider a debt that many of us are familar with – a mortgage. When planning the next month’s finances very few of us factor in repaying the mortgage. What we do factor in is the cost of servicing the debt. Other debts are more expensive and we chose to pay them off immediately.
Applying the “Technical Debt” metaphore to software development makes it apparent that we have a range of options – if the cost is high (a credit card) we can pay the debt off rapidly, if it is lower (a tracker mortgage) then we can get better returns by investing our efforts elsewhere.
The choice between such options is a management issue – developers can help identify the debt and the costs of either servicing or repaying it. But it is a management decision which approach benefits the business most.
Alan
Alan,
Thanks for your comment – an interesting observation as usual. Note that I’ve delayed replying because I wanted to mull this over a little before posting a response.
Yes, you’re right, I didn’t make this very clear. I have to admit this was because I didn’t think it was useful to take the metaphor as far as you suggest. That is to say, I wouldn’t have regarded it as useful to think of a solution as incurring a technical debt unless there was a need to “settle up” promptly – normally, on the phase of development for the next release.
However, now I’m not so sure. I think a more fundamental way of looking at your point is this: any incurred technical debt, regardless of its size or the form it takes, needs representation in the risk register for the business (and not just for the project); this is the starting point for determining the consequent action to be taken.
I think this topic is worth a follow-up post, but I’ll have to think about it some more first.
– Mark.
On the “usefulness” of this:
/1/ “The metaphor also explains why it may be sensible to do the quick and dirty approach.”
/2/ “you only make money on your loan by delivering”
http://www.martinfowler.com/bliki/TechnicalDebt.html
Also, on a different stream of thought, look at the comments about making the debt explicit:
http://www.c2.com/cgi/wiki?TechnicalDebt