Prioritize tech debt as if time and money matters
I’ve been reminded about this rule by a friend of mine recently. Each company running IT systems, including the flashy machine learning ones being built today, faces this dilemma at some point in their lifetime. The dilemma is usually: there is nobody left who understands a specific system, or it no longer builds, or making changes takes more and more time, or that one can’t build anything new without spending weeks on various upgrades first. This is because every IT system in the world requires regular maintenance and regular reviews of decisions made in the past. In most companies, there just isn’t enough people to deal with it. And it is not something that brings new revenue. At best helps to control the cost side of the P&L. New functionalities and products are usually the things that bring in the revenue. Tech debt falls to oblivion.
Over time, through experience, I learned a few common tech debt laws. I try to counteract them when developing software. These are:
- Temporary solutions tend to have a permanent nature
- The more functionalities you’ll add to an existing system over time, the less new functionalities you can add in the future
- Systems which don’t fail don’t get much attention
- Data store schema/structure designs last forever
- It takes at least twice the amount of time to fix a bad technical solution, than it took to build it
- Forcing teams to follow a specific architectural path leads to overcomplicated systems
- I don’t really need it, but I’ll still build it, because I want to show off results in systems nobody can understand (in many cases including the author)
In all of the companies I ever worked at, I always strive to put a strong focus on technical health, being informed by these laws. And it is worth every second of my time (some of my strategies are described here and here). But I still make mistakes 🙂
In terms of how to measure tech debt, my list includes:
- Amount of context a developer need to keep in their head when building software (how many other things they need to modify or keep in mind), which impacts the cost and time required to make a change (measured by change lead time and deployment frequency)
- Amount of things that can break after the change and how long it takes to recover from breakage, which impacts the chance of system being perceived as unstable and thus not used (measured by change fail rate and mean time to recover)
- The time required to upgrade every system in the company to most recent software, SaaS or hardware versions (else risking security and performance issues or being unable to hire new talent)
- Direct financial cost incurred by the company to pay for support of outdated or underperforming software, SaaS and hardware
- The time it takes new joiners to be onboarded to a system
Gustaw Fit 