Technical Debt: The good, the bad and the downright ugly

Technical Debt (TD) is a topic of increased significance in Enterprise circles. But, before we start to discuss Technical Debt in detail, it is perhaps wise to define Technical Debt within the scope of this post. As ever Google is our friend and a rudimentary search throws up some use ful definitions. A term coined by Ward Cunningham to describe "the cumulative consequences of corners being cut throughout a software project's design and development". According to James Shore, it is the cumulative total of less-than-perfect design and implementation in your project. A pithier explanation is provided by Tom Poppendieck who defines technical debt as everything that makes your code harder to change. I will leave it to the reader to Google who these characters are. Suffice it to say that they have served their time at the sharp end.

What can we say that is seemingly 'good' about Technical Debt?

Frankly there is not a lot that is good about Technical Debt, however there is an important point to be made here.  To do that we need to look beyond the design and development of a product in a wider context.  If we look at a product that is engaged with an expanding user base, which people are prepared to pay for directly or through a subscription model.  A natural by-product of pushing the product hard, presumably in the face of vigorous competition is a certain amount of Technical Debt. There are notable instances where the product management function gets out flanked by the technologists, at which point the minimization of Technical Debt starts to exist as a goal in isolation. The normal pattern here is a loss of engagement, significant opportunity loss and in the worst case a failed product. 

What is the 'bad' side of Technical Debt?

The bad is when we have built up a level of technical debt that starts to really impact our capacity to change our product in response to market demands or projected growth. The analogy in the physical world would be inertia, an inherent resistance to change in speed and direction - a lack of agility perhaps? The outcome can be to effectively stall product growth, leading to a loss in competitive edge.

Moving on to the downright 'ugly' aspect of Technical Debt.

A distinction may be made between the Technical Debt that we build up through the passage of time - Bad Technical Debt and the sort of Technical Debt that we inherit, typically as a result of a merger or acquisition - Legacy Technical Debt. Legacy Technical Debt can be a little like an iceberg, a large proportion is not apparent particularly within the scope of a due diligence exercise. On occasion acquisition targets fall into the category of organizations that have stalled, a contributing factor being the 'Bad Technical Debt'.

What can we do?

We should recognize 'Technical Debt Management' as a subtle trade-off between a theoretical construct of the perfect codebase and product reality. This can be considered an art as opposed to a science. The acceptance that incremental modular approaches such as micro-services are a better bet than big bang rewrites is timely and helpful. However, the acknowledgement and proactive management of Technical Debt should be an integral part of any organization that leverages acquisition as a strategic enabler for growth. Biting off more than you can chew and chewing hard might not be good enough. The solution is a combination of smart transformation, incremental approaches such as microservices and some serious unavoidable 'heavy lifting' at scale provided by people who have served their time in the trenches.