Technical Debt – Does it really matter

Cutting Code – Has it really been 40 years?
February 22, 2017
Words really do matter….choose the right ones carefully
February 22, 2017

Technical Debt – Does it really matter

There is alot of press on the topic of Technical Debt. Much of it indicates that this debt is a crisis situation, some material declares it is the root cause of most project failures.

Before getting into technical debt specifically, let’s step back and take a look at two debt situations in general.

A) Today I was looking at some bills and reviewing two specific debts. The first was for approximately $4K and the other was ten times higher at $40K. Which one concerned me the most? An astute reader will probably guess the smaller one if for not other reason that otherwise there would be little reason for this example. Some more details. The $4K debt is due and payable this month, the larget debt is over the next 4 hears, with a monthly payment of only $400 dollars. The smaller debt is having a 10x impact on this months budget compared to the larger debt.

B) At one point in my life, I was earning under $15K per year (it was the 1970’s so this was not so horrible, I had a nice apartment, car, etc.), then I accumulated some debt to the total of about $5K;. It nearly destroyed me. During the late 1990’s I had debts well in excess of $500K, most of it mortgage debt on my home; yet it caused no problems. The reason is that the impact on my day to day (monthly) budget was drastically different between these two situations.

Now to look at Technical Debt, this is a metaphor Ward Cunningham coined the back in 1992, and it has since been taken on by the industry to describe the consequences of poor software architecture and bad coding. There is a site dedicated to Technical Debt with generally focuses on the “crisis” point of view. The following was taken from that site:

“There is a growing concern on tech debt not simply because of the costs associated with it but also because mounting technical debt can delay delivery and turn into lost customer satisfaction. The impact of technical debt is often contrary to the many proposed benefits of agile development. Technical debt is the left over work from quick and dirty software – this debt is paid back from the extra efforts later on by developers to clean-up the messy code. When technical debt accumulates over time it can begin to affect the actually financial debt of an organization – either through extra man hours needed, profits lost due to late delivery, or poor user satisfaction.”

Serious consequences indeed, but there is one key element that is easy to overlook; the use of the word “can” rather than “inevitibly will”. Martin Fowler has a great post that highlights the difference between “possiblity” and “surity” when considering technical debt:

“The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.”

Instead of looking at Technical Debt itself, it is much more effective to look at the impact of this debt..

Consider now a codebase where a certain portion is riddled with design and implementation problems. This is Technical Debt. Now examine the following scenarios: Despite the condition of that code quality….

  1. all functional aspects are met, there are no impactful performance issues, and the code is stable (not likely to be changed in the near future).
  2. there are scheduled changes to functionallity and the code will need significant changes
  3. there are bugs (functional or performance) that are having a serious negative consequence on daily production use.

In the first case, any attempt to address the Technical Debt will incur cost and risk, and given that resources are typically finite, also means that other potentially valuable work will not be done. Addressing the technical debt would have a net negative influence.

The other two cases are varying degrees of similar situations. In both cases the code that contains the technical debt is going to need to be changed, independent of the fact that the current design/implementation is poor (i.e. contains significant debt).

Because of this the modified code is going to need to be tested throughly. Therefore the cost of this testing can be excluded from the sub-total which corresponds to the removal of technical debt. This will typically have a very positive influnce of the net impact of remediating the technical debt. Additionally, the existence of the technical debt when there is work that needs to be done is likely to increase the cost of doing that work unless the underlying problems are also addressed.

Focusing on the elements of Technical Debt which is incuring the largest relative ongoing cost provides the means to achieve the maximum return on the investment.

Leave a Reply

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