Technical Debt (TD) is a topic of increased significance in Enterprise circles. But what do we mean by Technical Debt?
Google throws up some useful definitions for Technical Debt as follows:
- “The cumulative consequences of corners being cut throughout a software project’s design and development”, as originally coined by Ward Cunningham.
- “It is the cumulative total of less-than-perfect design and implementation in your project” by James Shore.
- “Everything that makes your code harder to change”. A pithier explanation provided by Tom Poppendieck.
I will leave it to the reader to Google there bios, suffice 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 broader 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 outflanked by the technologists, at which point the minimization of Technical Debt starts to exist as a goal in isolation. The prevailing narrative 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 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 the 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. In many instances, such Technical Debt represents a “known unknown” much of which is not addressed within the scope of a due diligence exercise.
What can we do?
We should recognise that the management of Technical Debt is 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.
The acknowledgement and proactive management of Technical Debt should be an integral part of any organisation 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 significant unavoidable ‘heavy lifting’ at scale provided by people who have served their time in the trenches.