Two things I bet you didn't know about Technical Debt:
- It can make you bankrupt.
- At least one type of technical debt is good.
Technical Debt is a software engineering concept, and is defined as follows:
Technical debt is is a measure of the amount of duct tape holding your system together, plus the amount of rust¹ that it has accumulated.
Technical debt is is a measure of the amount of duct tape holding your system together, plus the amount of rust¹ that it has accumulated.
Duct tape represents improvisations, which are present in every software system, as a result of:
- Pressure to produce too fast, and not doing things properly.
- Quick fixes that were needed to "plug leaks".
- Experimenting with various features before deciding whether to pursue them.
Rust: Even a well designed and implemented software system will not continue working forever.
It will slowly degrade, as if it is rusting. This is because it doesn't exist in a vacuum.
It will slowly degrade, as if it is rusting. This is because it doesn't exist in a vacuum.
- Business processes change and assumptions break. The world is constantly changing, and businesses must adapt to survive. Software is designed and written based on various assumptions. These assumptions gradually become invalid. The gap between the current situation and the ideal situation will tend to widen steadily.
- Integrations with third parties change over time. Changes are required to keep up with evolving third party APIs, cloud infrastructure and security patches.
- Scaling issues. As the business grows, the system may need to handle significantly more traffic, and perform an order of magnitude more operations. As a result, its performance may drop below acceptable levels.
What does not count as technical debt?
— Bugs.
Any functioning software system starts accumulating technical debt from the moment it is born.
Whether or not you decide to pay back the principal, the interest is deducted automatically on a regular basis, in terms of the following:
- Lost productivity — it takes longer to deliver new features.
- Lost business — due to breakdowns, missing features, bad performance, security issues.
If you let technical debt get out of control, there can be additional consequences:
- Employee churn — It is frustrating to work on an ageing system that is not well maintained, has frequent breakdowns and emergencies, and is generally perceived as being disrespected by the business. In addition, opportunities to learn and grow professionally in such an environment may be perceived as being limited.
- Default or bankruptcy — I was recently asked to help a company that had let their technical debt get so out of control that they were seriously considering rewriting their whole system. In a different language. In the business world, this would be equivalent to defaulting on a loan, or even going bankrupt.
Strategies for controlling technical debt
- Clean up after experiments — It's fine to go into tech debt when experimenting with new features. Not just fine — I actually recommend² it. However, after the experimental phase you must replace the duct tape with properly engineered solutions, or remove it altogether.
- Budget for it — Allocate a constant, fixed percentage of engineering capacity in each sprint, or planning period, for the express purpose of paying down technical debt. I usually frame it at 25% and negotiate from there.
- Track technical debt — Use your issue tracking system (Jira, Linear, etc.) to tag and track technical debt.
- Identify technical debt hotspots — Use your source code control system (GitHub, GitLab, etc.) to identify technical debt hotspots. These are modules where there are a lot of frequent fixes that may indicate instability or too much improvisation.
When you address technical debt as a matter of routine, the curve looks like this:
"Can you help me?"
Yes, my mission is to help clients to transform their engineering outcomes.
🤙 Contact me via my LinkedIn profile.
🤙 Contact me via my LinkedIn profile.
Thank you for reading this far!
- I first saw technical debt called "rust" in an article by Jim Highsmith, one of the authors of the Agile Manifesto: Technical Debt is Rust You Can't See.
- As a child, I had always been taught that being in debt is bad. I have since learned that this is simply not true: there can also be "good" debt. A good debt can be when you borrow money and leverage it to create a cashflow-positive situation. For example, it's possible to borrow money to buy a house, and then rent it out for more than your monthly mortgage payment. Of course, there are risks. Similarly, technical debt can be advantageous in some situations.