Have your developers ever mentioned technical debt? Or are you wondering if you have technical debt? Are you interested in doing something about it? Is it even necessary to do something about it?
Let’s first have a look at what technical debt is.
Wikipedia defines technical debt as:
Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
Wikipedia
This is in fact a great definition. When we request a change to our software, developers have several options in front of them. Any feature or change request can be implemented in various ways. And these different options have different repercussions.
A traditional choice is between a quick but dirty solution and a slower but more long-term solution. What does this mean exactly?
The Different Kind of Technical Choices
What developers refer to as a “quick and dirty” solution, is often a way of implementing a feature that doesn’t take very long to implement, but isn’t a quality solution. Think of it as a carpenter that can make a chair quickly, but of low quality. This chair has a greater chance of breaking when you sit on it. Another metaphor is an author writing a book. She can just write the new passage at the end of the previous one, or she could fit it in another passage where it fits well. This would require some rework on the existing pieces of the book.
The same applies to software development. The quick solution is one where we don’t take too many best practices into account. Ranging from automated tests, to well-structured code (like the book), we could choose to ignore these best practices.
The Consequences
But choosing for a quick and dirty solution has consequences. And that’s where the term technical debt comes into play. When an organization chooses the quick option in software development, they’re taking a loan.
They’re taking a loan at some fictional bank (or loan shark!), that they will have to repay later. If the organization keeps its loans limited, it may be able to pay the interest indefinitely. But if the organization stacks up the loans, it will eventually succumb to the interests.
Let’s make this more clear with an example.
An Example
John is the manager of a development team at Acme Inc. He runs the team that develops an application to manage inventory. The Acme customers have requested a new feature in this application: logging in with a company account. John asks the developers to implement this quickly because customers are pressuring him. The development team does so and all is well.
After a while, John gets feedback from other customers that want to log in with their Google accounts. John passes this information on to the developers and stresses the short deadline for this feature. The developers warn him that they can do it quickly, but they’ll need to look at the login code to set some things straight. John acknowledges this, but now is not the time.
This goes on for several other login features, over the course of months. But for each new feature, the “quick” solution doesn’t feel so quick anymore. What’s worse, the last few times the new features are deployed, some bugs arise that need to be fixed.
The Cost of Technical Debt
This is where the abstract concept of technical debt becomes real in terms of money.
Let’s assume a cost of a developer at €80 per hour. The initial quick and dirty solutions might take the developer half a day to implement and test. So €320.
However, each time the developer has to work in the code that contains the quick and dirty solution, she might be slowed down by a factor of 1.5. So the next feature could cost €480. This happens each time she has to touch this piece of code, and it can run up to multiple factors of the original work.
At a certain moment, you need to pay back the debt. This could mean a larger investment than just paying the interests, but in the long term, your company will win. To make it all worse, the longer you wait, the higher the interests and the higher the amount to pay it all back.
Here’s a hypothetical table to illustrate:
| Cost per feature | Increasing technical debt | Payback early | Payback late | Proper solution |
| Feature 1 | 320 | 320 | 320 | 480 |
| Feature 2 | 480 | 480 | 480 | 480 |
| Feature 3 | 720 | 960 | 720 | 480 |
| Feature 4 | 1080 | 320 | 1080 | 480 |
| Feature 5 | 1620 | 480 | 2160 | 480 |
| Feature 6 | 2430 | 720 | 320 | 480 |
| Total | 6650 | 3280 | 4000 | 2880 |
In the first column, I’ve laid out hypothetical features. In the second column, I’ve added the increasing cost of implementing features without regard for a clean solution. In the third column, I’ve doubled the cost of implementing feature 3, assuming the developers pay back the technical debt early. In the last column, I’ve let the developers pay back the technical debt later, but they still fix the issue.
Notice how in both scenario’s where the technical debt is paid back, we end up with a cheaper solution. Even when we implement the subsequent features in the quick and dirty way again, i.e. multiply the previous cost with a factor of 1.5.
Finally, in the last column, I’ve set out a hypothetical scenario where the developers just implement it right the first way. It ends up being cheaper.
Caveats
I realize that the table above isn’t based on real data. It would be hard to measure this exactly. Especially because after a feature is implemented in a certain way, you have no way of knowing how much another approach would have costed. Also, the proper solution was calculated quite arbitrarily and even in that case the development team would build up a minimal amount of technical debt.
Also, this is only a price calculation. Sometimes, it pays off to take the quick and dirty approach. Sometimes, it makes business sense to take a loan in order to be able to deliver faster. Maybe it’s because we can make an important customer happy. Or because we need to hit a deadline so that marketing can sell it. Maybe we know the application is temporary and will be thrown away later anyway.
Whatever the reason, it’s OK to take on technical debt. It only becomes problematic when it is done continuously without regards for the consequences that will come later.
Worst-Case Scenario: Complete Standstill
If this is done continuously, you are in for a bad surprise. I have worked on a project where each feature was difficult to develop, and always led to multiple bugs when deployed to production. This also led to a high employee (and freelancer) turnover. Not a good situation in today’s market.
Management realized how problematic the situation was, and had called me and a few talented other developers to fix things. Initially, they assumed it could be fixed in a one year time frame. After a few months of extremely difficult development, we went back to management with the bad news that, according to our rough estimates, this effort would take several years.
Understandably, this was not what they wanted to hear. But it was realistic. For years, the company had built up technical debt, without repaying it. When they finally wanted to repay this debt, they were unpleasantly surprised by the cost.
This led to a difficult position. On the one hand, the cost of fixing the application was enormous and would hinder the development of new features. On the other hand, not doing anything meant continuing along the path of constant bugfixes and developers leaving.
Better Sooner Than Later
Not many organizations are in such a bad situation, but it’s important to keep in mind that sooner or later, you should pay back the technical debt that you acquired. And later is fine, as long as later becomes new at some point in time. If not, your developers will leave, as might your customers, and your competitors could will move faster.