The Controversial Truth about Tech Debt

Of all the buzzwords invented by the software industry, Technical Debt is the most frustrating. I know this will be controversial, and I can already hear clean architecture zealots fulminating. So let me explain my thoughts.

What the f$%k is Tech Debt?

I ask during interviews “What is the definition of tech debt?” surprisingly every candidate has a different answer. It seems like the industry hasn’t converged. I classified the responses into the following categories:

Here are a couple of issues with those answers:

• Answers are vague, for instance, what’s an “old code”? 6 months a year…
• Answers focus on symptoms and not root cause. For instance “code nobody wants to modify?” why does nobody want to touch it? because it’s hard to understand, because the knowledge is lost, or because it’s a critical piece for the business and the pressure is too big?
• Answers where the problem is not clear. “Code is slow” Is that a problem? I worked on a maintenance script, that was run once a month to clean duplicates in the database history. It took 3 hours to run. I wasn’t an expert in SQL and I am sure the script could be optimised, yet the script did the job and nobody complained.

I am not even talking about the ego of the engineer who told me that “code written by someone else” was tech debt.

Regardless of the definition, every company has tech debt. There is always a piece of code nobody wants to touch, not optimised or using an old framework. When I worked for Amazon in 2014, part of the retail website was written in Perl. Java was the new norm. This code was 9 years old, and everyone was always afraid to modify it. Nobody knew Perl anymore, yet it was working and used daily by hundreds of thousands of clients.

One consensus

Despite so many different definitions, something is consistent. Tech Debt is bad! There is a lot of negativity around this concept. Candidates who asked me “Do you have tech debt?” were extremely worried when I transparently said yes. Some even told me they don’t want to work for a company that has tech debt.

Tech Debt is Expensive

The main argument to justify that Tech Debt is bad is the price. So I tried to get a sense of this cost. But unlike a loan where the interest rate is written on the contract, tech debt is hard to measure. I attempted to look at the velocity of the team by story point.

I noticed the velocity of the team working on the monolith was slower than the one working on the micro-service architecture. After a few months, I realised that tech debt wasn’t the issue. It was just the amount of features to maintain. Once we reached 3 microservices, the second team became slower than the monolith, despite everyone telling me the micro-service code was clean and well-architectured. The burden of maintaining multiple services became an issue.

On the mobile team, I compared the velocity of the Android and iOS teams. iOS development was faster with fewer bugs despite not using clean architecture principles.

To be fair, velocity is a bad metric; it’s inconsistent across teams and I learned not to rely on it. If you know a good measure for tech debt, let me know.

Respect what came before you

The conversation about Tech Debt can be summarised as: “They made mistakes in the past, we know better now”. I find that presumptuous. I remember a conversation at Amazon in 2014. An engineer complained that the team chose to use “Beaver”, an Amazon internal key-value storage, basically the ancestor of DynamoDB. He kept complaining that the SDK for “Beaver” was cumbersome and the permission system was not granular enough. Both were fair complaints.

He aggressively asked “Why did the team decide to use this crap instead of DynamoDB?”, a staff engineer with 20 years of tenure just replied, “DynamoDB was released in 2012, this project started in 2009”…

I’ve learned to assume good intentions. The team before you had different constraints but knew what they were doing. If you don’t understand a choice, ask about the context of the decision. It could have been the only valid choice at the time.

Is Tech Debt that bad?

Tech Debt started as a metaphor inspired by the finance industry, just like financial debt, technical debt accumulates interest, meaning that the longer it remains unresolved, the more work will be required to fix it later. It was a good way to explain how business teams prioritize maintenance work over new features. It became something terrible in the ecosystem.

But is debt a problem? To buy a house, you get a mortgage and pay monthly interest and principal. It’s positive because you couldn’t afford one upfront payment. Leveraging debt allows you to achieve a goal.

Starting a company requires initial funding. Entrepreneurs are praised when they raise money. The higher the better, but they are just borrowing money from investors expecting returns. Debt allows them to achieve a goal. Like a tool, it’s not a bad thing. That’s how the economy works. It’s the same for software development.

I joined an early startup in 2019, with a team of 8 developers. Two years later, a freshly hired developer complained that the first mobile app was built using React Native, instead of a native technology like Swift for iOS. I had to remind this person that before being a scale-up with 100+ engineers and 6 dedicated mobile developers, the initial mobile app was built by the only front-end engineer. He didn’t know any native language, so he used what he knew and released an MVP in less than a month. Thanks to this quick MVP, the company acquired thousands of clients. This sales traction allowed us to raise a series B, and with this money, we hired a dedicated mobile developer to build a native app. His salary was literally paid by financial debt that was raised thanks to the technical debt.

Conclusion

Let’s give tech debt some love. It’s a tool, it’s neither bad nor good, it depends on how you use it. If you borrow too much money and never repay interest you’ll be over-indebted. But making long-term loans for an investment can buy you time, get you clients, and unblock projects. It can be beneficial. So remember to respect what came before you.