If you’re a business that relies on computer systems or digital platforms then you should be aware of what technical debt is and how it can impact of you and your bottom line.
The term “technical debt” was coined by famous computer programmer Ward Cunningham as a rather apt description of how various compromises during the development process can lead to systems or code bases being (or becoming) outdated, not fit-for-purpose, or incomprehensible.
Technical debt can be fatal to a company. It hampers their ability to adapt and grow, can create bugs and security vulnerabilities, and ultimately can result in costly fees to consultants and programmers who are the only ones who can work with your platforms.
So why go into technical debt?
The same logic that applies to technical debt could also be applied to financial debt – sometimes you need to take a short term hit to achieve long term goals.
You may have a product that you need to get built as soon as possible as a proof of concept or for revenue generation. To do this, you will likely need to cut corners and deliver something that is a minimal viable product instead of a fully functioning end-product.
It may be that your budget or deadline won’t stretch to accommodate a debt-free platform and that you need to compromise the short term to achieve the desired goals.
What to do before you go into technical debt?
The analogy to financial debt applies here as well. After all, you’d never consider taking out a loan without knowing what the APR, monthly payments, and payment terms were.
In the case of technical debt it isn’t always laid out quite as obviously or as transparently as this, but with a little foresight and common sense you can manage things a bit more effectively.
Documentation is key
You should already know what the right solution is before you start compromising for the sake of deadline, budget, or expediency. Produce a proper specification detailing how things would work in a perfect work and where you would want to be if you had all the money and time you need.
Now decide which bits you can live without. This is your development roadmap.
Evolve, document, then evolve again
It’s important not to let these bits original documentation hold you back. Your business needs will evolve and your systems need to change to meet these.
These changes need to be assessed and analysed before reviewing the original documentation and updating this to ensure that they are still up-to-date and that your development roadmap is accurate. This is your guide out of technical debt and inaccuracy here probably means that you are heading down a technical debt black hole.
Evaluate and plan
That development roadmap isn’t just a wish list. It is a plan of action which means you need to act on it.
You may not be able to estimate exactly when you’ll be able to deliver each of the milestones, but you should still have a good idea of what priority these have and when you’re planning on starting. Of course, this may change – we don’t all know what the future holds – but just adjust the timescales appropriately and keep it on your radar.
Change management
PIE – Potential Importance Ease
An important part of change management is using source control. Don’t know what source control is? That’s fine, but your developers really should (or you should probably be finding some new developers) and they should be adopting.
But what if I’m already in technical debt?
Perhaps a better analogy here would be crying over spilt milk. If you’re in technical debt hell and don’t know how to get out then there’s no easy solution. Of course, this doesn’t mean that there isn’t a solution, but it can take more time and money than you’d like extricating yourself.
Check out our next article on the perils of technical debt for some tips on how you can get your technical debt ledger back into the black.