The concept of Technical Debt1 concept was designed to try and communicate to non-technical stakeholders the issues with the solution. Specifically, the long-term issues with the solution. However, its abstract nature often leaves non-technical stakeholders grappling with its implications for decision-making.
Drawing parallels with a financial loan, the concept of Technical Debt suggests that every action taken by the development or engineering team either adds to the solution’s assets or liabilities. Each new feature introduced can be seen as accruing a certain level of debt, which can be offset by efforts to enhance the system. This analogy, however, presumes that the solution behaves like a financial product, growing simultaneously in terms of business value (assets) and system issues (debt), and makes a large assumption that it is all balanced by the decision makers and is a conscious decision, or at least a balanced decision.
What the technical team needs to do is identify an analogous process within the business that causes “wear-and-tear” and requires regular “maintenance”. Below are two short stories to help understand this concept.
The Bakers Oven Debt
There was an amazing bakery, the master baker was Tom, and he was known far and wide for his delicious bread. However, his oven, an old heirloom, was showing signs of wear and tear.
One day, a wealthy merchant named Richard, who knew nothing about baking, became a partner in Tom’s bakery. He was intrigued by the profits but didn’t understand the intricacies of baking. Tom was excited as the new funds could be used to improve the critical processes.
Tom explained, “Richard, our oven is like ‘Technical Debt.’ It’s old and inefficient, and it slows down our baking process. If we don’t address it now and spend some money on it, it will cost us more in the long run.”
Richard, puzzled, asked, “Why call it a debt?”
Tom replied, “Imagine our oven as a loan. Every loaf of bread it bakes adds a tiny bit to its ‘debt’ because it strains the oven a little more. But if we spend time and money now to maintain or upgrade it, we ‘pay off’ some of this debt, ensuring it runs efficiently.”
Richard pondered and finally understood. He agreed to invest in a new oven. The bakery flourished, and they baked more loaves in less time. The concept of ‘Technical Debt’ was no longer an abstract term for Richard, but a tangible understanding that proactive investment leads to long-term gains.
The Bank Ledger Debt
In the heart of a bustling city, there was a bank managed by a shrewd banker named John. The bank was prosperous, but it relied on an old, manual ledger system for record-keeping.
One day, a wealthy investor named Lindsay, who had no banking experience, became a partner in John’s bank. She was excited about the profits but didn’t understand the banking operations. John was excited by the influx of funds to give a boost to improve critical systems.
John explained, “Lindsay, our ledger system is like ‘Technical Debt.’ It’s outdated and inefficient, and it slows down our banking process. If we don’t address it and spend the time to improve it now, it will cost us more in the long run.”
Lindsay, puzzled, asked, “Why call it a debt?”
John replied, “Imagine our ledger as a loan. Every transaction it records adds a tiny bit to its ‘debt’ because it strains the ledger a little more. But if we spend time and money now to maintain or upgrade it, we ‘pay off’ some of this debt, ensuring it runs efficiently.”
Lindsay pondered and finally understood. She agreed to invest in a new digital banking system. The bank flourished, and they processed more transactions in less time. The concept of ‘Technical Debt’ was no longer an abstract term for Lindsay, but a tangible understanding that proactive investment leads to long-term gains.
Smell of Technical Debt
As a non-technical stakeholder, it is tempting to constantly be asking for more and more features to be added. When this goes unchecked without the ability to let the technical team pay down the technical debt, you get into situations where new features take longer and longer and longer to implement. Eventually, you get into a position where you are stuck and the best path forward, is to start over. There are a few hints (or smells) that your technical debt has built up and needs to be paid back before something breaks. Some of the indicators may include:
- Lack of ongoing maintenance.
- Lack of, or minimal tests such as:
- Integration,
- User Acceptance,
- Unit,
- Behavioural,
- Performance,
- etc.
- Patching for security is incredibly slow.
- Similar features take drastically different amounts of time to implement.
- Bugs are part of the system.
- Some features are only partially implemented.
- The system is described as “old”, or “legacy”.
- A sense that the system has not been architected, it has just been built.
While each system will need to have the technical debt reduced in a bespoke way, it first needs to be identified that it is there, and then agreed that it needs to be reduced.
The compromise
It is not possible to build any software without technical debt. But it is possible to be more deliberate about it. As part of a maturing Software Development Life Cycle (SDLC), the team should be considered and understanding when they can purposefully take the short cuts to meet the deadline, with the compromise that they can come back and implement a better solution. This will allow the tech teams to be more agile and maintain a feature implementation velocity that is desirable by the non-technical stakeholders.