What is Technical Debt?

What is Technical Debt?

Technical debt is like financial debt. That’s the best way to think about it. It’s in the context of software. Financial debt comes with interest that you eventually need to pay back, technical debt makes future software changes harder and slower. Software needs to change over time.

The high cost of technical debt is invisible to businesses. And it is obvious and highly visible to developers.

This is why it’s fair to describe code as debt. This concept, introduced by Ward Cunningham, helps us understand the speed boost we get when rushing software development at the cost of slowing down later.

Why Code is Debt

Every line of code you write is technical debt. It has value too. It helps the business attract customers with automation. But, it also adds complexity to the owner of the codebase.

You'll have to "pay" for this complexity when making future changes. All code changes. Like any debt, if not managed, it can grow and become a heavy burden. The cost of tech debt is imperceptible to most people at the company. Yet it is obvious to developers.

Leasing Debt, the Business Part

From a business standpoint, technical debt is valuable. It can be leased and sold to others who need automation and new workflows. Most businesses often fail to maximize the value of their debt. This happens when they don't sell the value high enough to meet the cost of the debt.

Here's the deal, most businesses are sometimes okay with this! And it's pretty standard. Even public companies do this! This might be hard to hear, though the debt can always be paid down, the debt leasing line needs to grow. This is the only true metric that counts. Revenue growth from leasing the debt. Even at the cost of low margin due to the high cost of technical debt.

We all end up with unused and burdensome code. Understanding how to leverage the debt effectively is key to extracting its full benefit. And we someday need to pay it down.

Software Engineer Suffer the Most from the Debt

Technical debt is often created when developers rush to meet deadlines or take shortcuts in programming. "Oh, it's just an MVP, we don't need you to spend too much time on it."

However it eventually becomes the core product feature, and the debt is unsustainable. Every time we write code, we're adding to this debt. Reading and maintaining old code adds to the burden, making future modifications cost more and more.

Reducing the amount of code wherever possible can aid future development. This is the most critical part. If you take one thing away from this article, know that you want less code, simple code and no fancy abstractions.

The Clean Slate

When you start with an empty codebase, development moves at lightning speed because there's no technical debt hindering progress. Every line of code you add increments the debt counter. The goal should be to keep this debt minimal. Right from the start.

Prioritize simple and efficient solutions. Don't try and create an "easy framework". Just keep the code clean and small. Most codebases get rewritten anyway. Just keep it simple from the start.

Beware! Complexity is Appealing to Software Engineering Teams

As you add layers of functionality, technical debt multiplies exponentially. You might be a software developer that wants to organize a code base into files and directories. You've already failed. You failed the business. And you failed your team. You failed the future developer who has to come in later to read your code. Good news though, you can still succeed. It is best to not create any abstractions or optimizations. Keep it simple and clean. Few files, and few lines of code. No abstractions.

Complexity makes it harder for future developers to understand and modify the code, turning it into a liability. Simple, easy-to-understand solutions minimize this burden and provide a solid foundation for future teams.

Every new feature comes with a fundamental set of assumptions. Each assumption will contribute to technical debt. For instance, while building security gateway, we had to make various decisions to meet different needs. Each decision added complexity, making future changes harder. You're forever bound to consider the initial assumptions.

Tech Debt can Exceed Profitability

Not all features add value. This can have a negative value if not implemented well. The overhead technical debt they create outweighs the benefit, especially if the localized app doesn't attract new users. Features should add enough value to justify the complexity they introduce.

The value in software isn’t just in the code itself but in its usefulness to users. Poorly written but useful code is better than beautifully coded but useless functionality. Always focus on creating value rather than just writing code. Even though it's fun to write beautiful and organized code, it's usually too expensive.

Once a feature is added, it's almost always there to stay. Removing it involves extra work and risks upsetting customers. Be careful when adding features to avoid even more technical debt.

Avoiding Technical Debt

The only way to avoid technical debt completely is by not writing code, but that's impractical. Instead, focus on solutions that add maximum value with minimum code. Sometimes, non-coding solutions like using existing tools can be a better choice.

When adding new features, try to work within the constraints of existing assumptions rather than adding new ones. For example, when we wanted to add a reminder feature in Doorkeeper, we leveraged the existing messaging system, thereby reducing complexity and technical debt.

Real-world Example at PubNub

At PubNub, we added features like moderation dashboard for chat systems. It's amazing! It allows moderators to monitor chat feeds and manage users and chat messages. This meets the needs of our customers.

And now we have a new system we must maintain going forward. The code is debt. And we are now leasing our debt to our customers. Each feature adds complexity. And this is another line item of debt to be counted.

How to deal with Existing Debt Because You Already Have a Lot

Refactoring. And code reduction. This is like paying down the principal on a loan. It reduces the long-term cost of your technical debt. Every team should be regularly improving and simplifying their existing codebase. It can be a part of every sprint cycle. Future development becomes faster and less error-prone.

My favorite is code-reduction. Seeing lots of minus signs on the GitHub PRs.

As developers, our role extends beyond just writing code. We need to become champions of our product by defending it from poorly thought-out features. Understanding the purpose and value of each feature before adding it is crucial. Push back, ask questions, and ensure that each feature truly adds value. This just happened earlier today! And it happens most days really.

My Ultimate Approach on Technical Debt

As the CTO at PubNub, my biggest takeaway for you is this: Aim for simplicity and value. Reduce complexity to minimize technical debt. Always focus on creating the most value from the least amount of code. This approach not only makes future development easier but also helps businesses grow more sustainably.

Use languages like Rust with strict compilers that reduce debt early-on.

Keep code simple. Focus on providing valuable solutions, we can aid the growth of the business while minimizing the growth of technical debt. The business impact of your code is enormous. Strive to deliver the highest value with the least amount of complexity. Focusing on the least amount of code, and least complexity first.

Will AI Make Technical Debt Worse?

Yes. The AI code generators can write code so fast, that your debt climbs to the ceiling. Instant debt! 📈 It's the fastest way to grow technical debt.

Now to maintain the codebase, you must continue using the AI.

The AI must manage the code debt. And it requires guidance. An experienced engineer must do this. The engineer can ask the AI to optimize code blocks. And perform code-reduction tasks. Each line of code needs to be validated and verified.

AI can be used to reduce code debt too. And it still requires a budget and spending time to do this. It's still technical debt.