Technical Debt

I first came across the concept of Technical Debt whilst reading a recent copy of the Microsoft Developers Journal called the MSDN Magazine. It struck a chord, as it's a concept that all software developers are familiar with.

In every software system, there are areas of the code that are difficult to change, that strike fear into us when we are required to change them. Those areas of the code that make you think "Oh please no". They are difficult to modify or extend, and thus working in those areas are prone to making the system less stable. They will also generally require a greater degree of regression testing to ensure that you have not inadvertently modified other areas of the system.

The phrase was initially coined by Ward Cunningham, and uses the metaphor of finance. There are certain kinds of debt that are cheap to repay, where the interest rates are low and repayments incur little cost. Then there are those kinds of debt that are difficult to repay as the repayments are high. A credit card would be a good example of the latter, where their high interest rates make them an option that should only be considered as a last resort.

The major downside of Technical Debt is that is has an associated cost. Being difficult to modify will lead to longer development lead times. It will require additional testing, particularly regression testing. All of this extra time and effort involves greater cost.

It also ensures that the software system in which the Technical Debt finds itself will be less likely to be able to respond to customer changes, or fluctuations in demand or functionality. If there is a swing in customer demand, and the system needs to change to be able to respond to this swing, it will require far greater resources to make those changes in a software system which has a higher degree of Technical Debt.

I remember whilst working as a Senior Software Engineer at the Kettering based software house Pegasus, one of my colleagues telling me how he disliked modifying certain areas of the underlying Framework code, as it was like "playing Kerplunk with the code". What he was referring to of course, was that the code was so interlocked and tightly integrated, that making a change in one area of the code, would often result in changes being made inadvertently in other areas of the code. This would lead to longer development / testing cycles, and would be fraught with frustration.

I have already discussed in previous articles how to prevent Technical Debt through the use of Design and Design Patterns. I won't bother covering how to repay back already existing Technical Debt, as this too has been covered in an excellent MSDN Magazine article.

Technical Debt is a simple concept that every software developer both understands and can sympathise with. If left unchecked, it can lead to significant cost implications, so it is worthwhile investigating and taking the time to remove it. There is a strong financial incentive to make the case for removing Technical Debt, and this should be proposed as a project as early as is convenient.