Among all the buzzwords invented in the software industry, technical debt is the most disappointing. I know this will be controversial, and I can already hear the clean architecture enthusiasts. So, let me explain my thoughts.
What is technical debt?
In interviews, I ask, "What is the definition of technical debt?" Surprisingly, all candidates have different answers. It seems like the industry has not converged. I categorized the responses into the following categories.
Here are some issues related to these responses.
- For example, what is "old code"? 6 months to a year...
- Answers focus on symptoms rather than root causes. For example, "No one wants to touch it." Why does no one want to touch it? Because it's hard to understand. Is it because knowledge is lost or it's a critical part of the business and there's too much pressure?
- Answer where the problem is not clear. Is "code is slow" the problem? I performed a maintenance script job that ran once a month on database records. It took 3 hours to run. I wasn't an SQL expert and wasn't sure if the script could be optimized, but the script did the job and no one complained.
I don't talk about the engineer who called "code written by others" technical debt.
Every company has technical debt regardless of the definition. Anyone who doesn't always optimize or use old frameworks doesn't want to touch it. When I worked at Amazon in 2014, part of the retail website was written in Perl. Java was the new standard. The code was 9 years old, and everyone was always afraid to make changes. No one knew Perl anymore, but tens of thousands of customers used it every day.
One Consensus
Despite many different definitions, there is some consistency. Technical debt is bad! There is a lot of negativity associated with this concept. A candidate asked me, "Do you have technical debt?" I was very concerned when I answered honestly. Some even said they didn't want to work in a company with technical debt.
Is Technical Debt Expensive?
The main argument justifying that technical debt is bad is cost. So, I tried to understand this cost. However, unlike loans with interest rates written in contracts, technical debt is difficult to measure. I tried to see the team's speed in story points.
I saw that the team working in a monolith was slower than working in a microservices architecture. A few months later, I realized that technical debt wasn't the issue. It was the amount of functionality that needed to be maintained. When we reached 3 microservices, the second team became slower than the Monolith. The burden of maintaining multiple services became the issue.
I compared the speed of the Android and iOS teams in the mobile team. Even without using clean architecture principles, iOS development was faster due to fewer bugs.
To be fair, speed is a bad metric. It's not consistent within a team, and I learned not to rely on it. If you know a good measure for technical debt, please let me know.
Respect What's in Front of You
Conversations about technical debt can be summarized as follows. I discovered that inference. An engineer complained that the team chose "Beaver" as the ancestor key value in Dynamodb internally at Amazon. He complained that the SDK for "Beaver" was cumbersome and the permission system was not granular enough. Both were fair complaints.
He actively asked, "Why did the team decide to use this garbage instead of Dynamodb?" An engineer with a 20-year tenure replied, "Dynamodb was released in 2012, and this project started in 2009."
I learned to assume good intentions. They had different constraints, but I understood what they were doing. If you don't understand a choice, ask about the context of the decision. It may be the only valid choice at the time.
Is Technical Debt That Bad?
Like financial debt, which started as a metaphor inspired by the financial industry, technical debt accumulates interest just like financial debt. That is, there are many tasks to be resolved later, even if they are not deciphered. It was a good way to explain how the business team prioritizes maintenance operations over new features. It became a terrible thing in the ecosystem.
But is debt a problem? To buy a house, you take out a mortgage and pay monthly interest and principal. It's positive because you can't handle a lump sum payment. Leveraging debt allows you to achieve goals.
Starting a company requires initial funding. Entrepreneurs are praised for raising money. It's borrowing money from investors who expect a return, the higher, the better. Debt enables you to achieve goals. It's not inherently bad, like a tool. It's how the economy works. It's the same with software development.
In 2019, I joined a startup with a team of 8 developers. Two years later, a newly hired developer complained that the initial mobile app was built using React Native instead of basic technologies like Swift for iOS. Before scaling up with over 100 engineers and 6 dedicated mobile developers, I had to remind him that the initial mobile app was built by a single frontend engineer who didn't know the native language, used what he knew within a month, and released an MVP. Thanks to this quick MVP, the company acquired thousands of customers. With this sales traction, we were able to raise Series B and with that money, hired dedicated mobile developers to build the core app. His salary was paid off the financial debt raised due to the technical debt.
Conclusion
Give some love to technical debt. It's a tool, neither bad nor good, it depends on how you use it. If you borrow too much money and don't repay the interest, you'll be overextended. But creating long-term loans for investment buys you time, secures customers, and unlocks projects. It can be beneficial. So, respect what's in front of you.