The technical debt quadrant
Is technical debt ALWAYS bad?
It’s a question we’ve touched on a lot in earlier blog posts. Whether you’re a scale-up CTO or tackling legacy issues at an enterprise insurance organisation, managing technical debt is a challenge.
One model we often refer to is Martin Fowler’s technical debt quadrant.
It takes a simple approach to interrogate the complex matter of technical debt:
- “Did we incur this technical debt deliberately or inadvertently?”
- “Was that decision prudent or reckless?”
These two questions give you the four quadrants of technical debt:
Let’s take each quadrant in turn and consider the role of DevOps in managing the inherent risk.
Deliberate & Reckless
In this quadrant, you know you are making a design choice that will inevitably create technical debt.
Have you considered the long term impact of this decision? Are you tracking the technical debt level as it’s incurred? Do you have a plan (and future budget) for paying it off? Are you doing anything to limit the ‘blast radius’ if this decision blows up in your face?
Failure to consider factors like these is what tips deliberate technical debt into the reckless territory.
CIOs and CTOs are under immense pressure to achieve things quickly, particularly in rapidly growing start-ups and scale-ups. Nevertheless, deliberate acquisition of technical debt without a sensible examination of the risks is rarely a successful strategy.
I once worked on a project where product testing had shown numerous bottlenecks caused by suboptimal design decisions. The product didn’t meet the speed and user concurrency goals set in the high-level design. More testing and code refactoring was advised to repay the technical debt and address the performance issues. However, this expert recommendation was ignored in favour of ploughing on with a high-profile (and expensive) launch event.
End result, the system didn’t cope with the load placed on it during the launch, leading to negative reviews. Within six months the project had folded.
The reckless decision to ignore technical debt causing poor performance resulted in an epic fail.
Deliberate & Prudent
A prudent approach can be defined as ‘acting with or showing care and thought for the future’. So, this quadrant is about making informed decisions to take on technical debt.
In this scenario, decision makers carefully weigh the risks versus the rewards. They plan how to deal with the consequences of their decision, particularly if the worst case scenario should materialise.
Eric Ries, author of the book Lean Startup talks about why incurring technical debt is often the right choice for a startup. As engineers we tend to want to design and build the most robust and high-quality products we can. This can sometimes lead to ‘feature bloat’ and over-engineering of the solution.
What we really need to do is get our Minimum Viable Product (MVP) into the hands of prospective customers quickly. Firstly, to see if it’s a product they are willing to pay for. And secondly to discover what features they want (rather than what we think they want).
This is the message at the heart of the Lean StartUp build-measure-learn loop as shown below.
Now let’s look at the ‘unknown unknowns’ of the inadvertent decision tree.
Inadvertent & Reckless
This is the quadrant of ‘things you really should have known but didn’t’.
Everyone has gaps in their knowledge. No one can be expert in all the myriad fields of modern technology. Nevertheless, there are certain things that it’s reasonable to expect IT professionals (or teams) to know, or at least endeavour to find out.
In essence this is what lawyers would call the ‘reasonable man test’. Is it reasonable to assume that someone in that position would or should possess that knowledge? And does ignorance equate to negligence?
Take someone who has ten years’ experience in Java programming. It’s reasonable to assume they understand the fundamentals of object-oriented programming, like inheritance or abstraction. Ignorance of these principles could result in a buggy application with unexpected application behaviour or poor maintainability. This would be considered ‘inadvertent but reckless’ technical debt.
A team with access to industry knowledge and best practice should be able to avoid this type of technical debt.
To put it another way…this is the ‘ignorance is no excuse’ quadrant.
Inadvertent & Prudent
Which leads us to the final quadrant – inadvertent and prudent technical debt.
Unlike your reckless counterparts, you and your team have done your best to leverage industry best practice or vendor guidance. You’ve also invested time and effort in learning to keep your skills up to date. Is this a perfect recipe for avoiding technical debt?
Unfortunately not.
IT as a profession is constantly innovating and learning new and better ways of doing things. Remember the opening words of the Agile Manifesto:
“We are uncovering better ways of developing software by doing it and helping others do it.”
Sometimes the only way to learn is to do – just like in Eric Ries’ build-measure-learn loop discussed earlier. When you’re doing something novel, you inevitably hit that point where you say: “Ah! If only I had known this before I would have done it differently”.
In some ways this is the hardest technical debt quadrant. No amount of analysis or big upfront design can anticipate or predict what you’ll learn over a product’s lifetime. The only way to learn, is to do.
But you can anticipate the refactoring that you might need to do once you’ve ‘learnt from doing’. And this time can be built into your product lifecycle. You can also do ‘spikes’ or proof-of-concept prototypes to aid initial learning before committing to larger pieces of work. The goal here is to maximise the learning opportunity, as quickly as possible. In this way, you can move from ‘inadvertent’ to ‘prudent’ for more of your technical debt.
Better products, lower total-cost-of-ownership
I hope this short journey around the technical debt quadrant helps you manage your technical debt better. Paying attention to these principles should allow you to build better products with lower total-cost-of-ownership. Remember, the interest on your technical debt is always accruing. The sooner you can pay it back, the less it will cost!
Source: devopsgroup
