Technical debts[1] are one of the most despised things by software engineers.
Talk with any engineering manager or product manager. They will anecdotally tell you how much engineers complain about tech debts and how they would like to stop product development to solve technical debts.
The question is: do we really need to solve technical debts? To answer this, we need to ask another question: why are they called debts?
The term debts (even if some authors prefer the word technical liabilities[2]) was invented to describe the process to non-technical people.
It seems that the original meaning[3] was slightly different. Still, nowadays, the most understood meaning is: you borrow some time by producing a quick (and sometimes dirty) solution, postponing (paying back the time) the refactoring and the refinement of the solution.
The primary source of confusion is that debt for non-technical people is often a positive word. After all, we all take debts in our lives: a mortgage to buy a house, a loan to buy a car, or to get a university degree (well, if you’re unlucky to study in one of these countries that require student loans).
To engineers, the meaning is always negative: instead of doing the right thing now, we deliver a half-baked solution. Then we move to the next half-baked solution, never looking back at fixing things.
This is one of the common frictions between product managers (product owners in the Agile world) and engineers, with engineering managers/leads caught in the middle.
I think that what engineers and managers miss is the complete analogy with regular debts. You take a debt today for a specific long term goal that you won’t be able to attain otherwise at first. But while you’re repaying your debts, the end goal is evident in your mind and sometimes already in your possession.
I believe this is where engineering leaders have to opportunity to show authentic leadership. Show your teams that it’s ok to take tech debts if the end goal is clear. And by clear, I mean that the end goal should never be only to deliver faster.
If the short term goal (deliver something quickly) it’s also the long term goal, then frustration arises amongst engineers.
When the team has the time to look back at work done, they will get annoyed as the refactoring will often require a complete rewrite or re-architecture, and at that point, repaying the tech debt will be too costly in terms of time commitment.
Moreover, a solution designed purely to be delivered faster will always be fragile and anti-resilient, creating reliability and security problems.
The long term goal (build something exceptional) should always guide the design and the implementation. When you make the conscious decision to cut a corner and take a tech debt, then repaying it will become easy.
A solution designed to be exceptional, with a few conscious decisions of cutting the scope, will be delivered quickly and create tech debts that are not liabilities. Extending or refactoring won’t require a complete re-architecture.
Leaders should encourage team to take explicit tech debts, with a clear contract.
References:
[1] https://en.wikipedia.org/wiki/Technical_debt
[2] https://www.allankelly.net/archives/415/technical-liabilities-not-technical-debt/
