Technical Debt – A Primer

[Reading Time: 5mn – Presentation: 30mn]

A few weeks ago, I had the opportunity to do a presentation on Technical Debt to a panel of corporate IT managers of a large European bank.

Ward Cunningham introduced the Technical Debt financial metaphor around 20 years back, in an effort to allow non technical people to understand why money needs to be spent continually on software products. Well, I think his message is still very valuable today.
Following this presentation and the workshops and discussions which ensued, some patterns seemed to emerge.

Coders are not to blame
The original definition of Technical Debt implies defects: anything in the code that has not been done right. Code quality immediately comes to mind and chances are that the blame falls on the developers. But actually, this is just one aspect of the whole concept, because it’s not just about code: it could be a bad design, lack of testing strategy, lack of functional documentation, etc…

Design for change
Focusing for a moment on the design thing: as software architects, we all know that there is no such thing like a “done” software application. Software needs to evolve with time. It needs to adapt to its changing environment. To continue its duty. To perform to the level expected or decided at inception. So one could say that not following the “design for change” rule is something “that has not been done right”. A kind of Design Debt.

Measure & Control
Corporate IT (where IT people build Enterprise Applications as defined by Martin Fowler) is in need of tools to measure, control and make Technical Debt visible, and they also need rules to enforce Software Quality. These aspects were also tackled during the presentation and more specifically addressed in the workshops which followed.

Obsolescence
Hardware and software obsolescence management is part of a normal IT product lifecycle. Put this way, it should not be considered Technical Debt because it is not a defect. It is not something that has not been done right. Still, quite a few managers tend to consider it as one of the main sources of Technical Debt. This is most certainly related to the lack of a dedicated adaptative maintenance budget.

Conclusion?
I will probably be posting again on the subject which definitely has implications on many aspects of the whole development lifecycle and needs everyone to be involved from sponsors to business analysts, from IT managers to developers.
In the meantime, here are some slides of the presentation for you.

Leave a Reply

Your email address will not be published. Required fields are marked *