Why not all technical debt is created equal
There is a lot of talk in tech circles about “technical debt” … for those unacquainted with the concept, here’s a definition for you:
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.
While it’s generally accepted that technical debt can be used strategically to a business’ advantage, everything I read makes two assumptions that I think are fundamentally flawed:
- The concept that technical debt is black and white: it either is, or is not technical debt, and all technical debt is the same.
- All technical debt must be repaid in the fullness of time.
Let’s look at these two points individually:
What is the interest rate on your technical debt?
To be absolutely clear — I am in no way suggesting you should write terrible code with zero consideration of the future implications.
However, you can still write robust, future proof and performant code even if it’s not the “textbook” solution. It’s about being commercially strategic.
A practical example:
Assuming an MVC architecture, putting SQL queries in view files might be considered the 1000% APR payday loan of technical debt; conversely putting a few inline styles within views is still ‘wrong’ but isn’t the end of the world — it’s the 4% APR option.
In reality your compromises are probably more complex than this, but the principle is the same — the ‘cost’ of technical debt in the second example is far lower because you’ve limited the scope of the compromise.
Fact: a lot of technical debt gets written off.
In reality it is highly unlikely that you’ll have to pay back all technical debt.
A disruptive business needs to be experimenting and evolving constantly. Many of those experiments will fail, leaving only a small proportion of the ‘compromised’ code actually requiring refactoring in the fullness of time.
If the ‘best solution’ takes 10 days to develop, but you can deliver a functional but ‘affordably’ technically indebted solution in 2 days, then you have time to run 5 experiments in the time it would’ve taken you to write just one ‘perfect solution’.
The result of this is that you’ll have a much better idea of which ‘experiment’ is going to deliver the most commercial value for your business. In the example above, even if you end up refactoring 4 out of the 5 experiments (not likely) then you’ll still have time in hand.
The Disclaimer
I’m not saying this is right for every business. If you work for a bank, the government or a corporate, there is likely (a) a ton of change control governance, and (b) a lot of people with ‘job preservation’ comfort zones.
But if you’re starting something new, have limited funds, or need to move quickly to disrupt and/or gain a competitive advantage, then accepting a level of technical debt in return for being able to experiment quickly could be the difference between success and failure.
Don’t just take my word for it
I have first hand experience in several businesses of leveraging technical debt to gain a competitive advantage (and paying it back when required), but I’m not alone in promoting this approach to managing development:
“Move Fast and Break Things” was Facebook’s mantra for years.
Jeff Bezos of Amazon was quoted saying “Failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment.”
I have lost count of how many businesses with great ideas I’ve seen either run out of money, or sell their souls to investors to finance their pursuit of the ‘perfect solution’ to a problem that they don’t even fully understand because they’re not in the market yet.
You’ve got to be in it to win it, and an affordable level of technical debt is a no-win-no-fee deal.
My top 3 tips for affordable technical debt:
In practical terms, a lot of academically trained developers struggle to see where the line needs to be drawn.
The key to overcoming this is encouraging and developing the commercial awareness of your engineers . Explain the context of why they’re building a feature, and what it’s commercial value is to the business — ultimately it’s going to to be them that call the compromises so your perspectives need to be aligned.
Here are my top 3 tips on getting it right:
- Less moving parts: like anything, more moving parts (more lines of code) means more things to go wrong. Don’t over complicate your code for the point of principle, to cater for an edge case, or an improbable future development. Write clean and concise code.
- Stick to the basics: don’t repeat yourself, do one thing, single point of truth. Being tidy will not only isolate your compromises, but will make any eventual refactor far easier.
- Pick your battles: are you developing a critical part of the application, or a value-add feature? Maintain perspective and work smart to identify where you can afford to compromise.
