What is technical debt (and what is too much)?
Technical debt is often a bit of a contentious buzzword around the workplace.
For some, it’s the software development hill to die on. For others, it’s just a side note to the list of inevitable characters that come along for the ride. It’s the family member that no one really wants around, but they’re a part of the furniture now, sorry.
But whether technical debt an eye-widener or eye-roller for you, it’s important to have a shared internal understanding of what it even is–and how much is too much.
This article will take you through:
- What is technical debt in software development
- Systems versus causes of technical debt in software development
- What is the real cost of technical debt?
- Is all technical debt bad?
What is technical debt in software development?
Technical debt is is basically the cost of using shortcuts and quick fixes during software development.
For many of us, it comes down to a case of “Release to production quickly, not perfectly.”
Efficiency can drive us to take shortcuts like:
- Putting perfect code management aside
- Not completing the right documentation
- Building on dependencies that aren’t documented or are to change or expire
Technical debt is the outcome of taking such shortcuts. It’s the “payback” we’ll most likely have to deal with in the future.
Important to note: You might mistake the term technical debt for “code mistakes,” or generally “bad code” you might create for the sake of speed. This is not quite true, and it can be a damaging myth.
It’s better to think of the debt as a symptom of coordination and process issues. In other words, the debt can come from skilled teams not set up to succeed.
Symptoms vs. causes of technical debt in software development
It’s tempting to spend a lot of energy looking at what shortcuts your team makes, and try to mitigate those. That said, you might find it worthwhile to look into why those shortcuts happen in the first place.
If we treat shortcuts in software development as a symptom, what’s the cause?
According to Codescene’s report on technical debt, unplanned work is the leading cause of debt accrual:
“If your organization spends more than 15% on Unplanned Work, then that’s a warning sign that delivery potential is wasted. Technical debt is likely to be a significant chunk of that waste.”
Unplanned work could include unexpected reworks of projects, bugs, or changing priorities at the last minute.
The impact of unplanned work on the debt reminds us of the pressure we place on dev teams to work both flexibly and at speed, even in the most strict and regulated industries in the world.
What is the real cost of technical debt?
Just as technical debt isn’t just a code issue, the cost isn’t just a technical one, but a business one.
Through the lens of payback being “a technical thing that you can go back and fix,” it’s easy to underestimate the very severe and very real consequences of the debt.
Examples::
- Legal costs and even lawsuits
- Wasted engineering time
- Higher staff turnover, especially senior and talented developers who don’t want to spend the majority of their time fixing legacy code
- Long lead times to implement new features, meaning missed deadlines and the knock-on effects for wider teams
- Poor UX for the end user
- More pressure on tech support teams
- Less resources for testing and experimenting
Just from a resource perspective, engineers spend 33% of their time dealing with debt. Developer inefficiency from technical debt can lead to a $3 trillion impact on global GDP
In an example closer to home, you could equate that to having only 70 percent of your engineering force working on actually enhancing your digital products.
Is all technical debt bad debt?
The above list of potential outcomes will get anybody’s back up, but not all debt is created equal. When it comes to technical debt, it’s not necessarily a bad thing in and of itself.
In all areas of business, teams constantly face decisions around prioritization. You might complete tasks with specific deadlines or within tight restrictions, often in a mix and sometimes at odds.
What you call a “shortcut”, others might call “a necessary prioritization.” But how do we know if this decision, or type of debt, is a good one or not?
Instead of thinking in terms of good vs. bad–which brings a ton of emotive gut reactions–it’s probably better to consider making your debt a conscious investment decision:
- Is the goal outcome worth the cost we took on?
- What’s our return vs. investment?
- Is the risk accounted for and controlled?
One way to keep a handle on your debt is to differentiate between planned and unplanned technical debt.
Unplanned vs planned technical debt
If you treat technical debt as a conscious investment decision, that means you can plan for it.
Conversely, an investment without a plan isn’t really an investment. It’s a gamble based on luck.
Unplanned technical debt is often caused when a team doesn’t anticipate or understand the long-term consequences of certain design decisions. The type of stuff that happens when teams are under pressure to deliver a project on a tight deadline.
It can also occur when developers aren’t familiar enough with the technology they are working with or when there is a lack of communication between the development team and other stakeholders.
Examples of unplanned debt include:
- Using a library or framework that is not well-suited for the task at hand
- Choosing a design pattern that is difficult to maintain or scale
- Not properly commenting or documenting code
Unplanned technical debt is your biggest risk factor for “bad debt” and is susceptible to spiraling further out of control.
Planned technical debt is when your team knowingly takes on the debt in order to meet a specific goal. It’s managed, and the ROI is deemed worth it.
Examples of planned technical debt include:
- Using an older library or framework that is well-understood but no longer actively maintained
- Choosing a design pattern that is simpler to implement but less flexible in the long-term
- Writing code that is easy to understand but less efficient
The key thing here is that the debt is managed with care. If not, planned debt can quickly spiral into unplanned, even with the best intentions.
How to manage technical debt in software development?
Whatever your stance on where it falls in the buzzword scale, managing your technical debt should be seen as a core part of your DevOps.
Need a quick inspirational statistics? Gartner reports that companies who have a strategy for the debt will ship 50% faster.
Good vs. bad, planned vs. unplanned, your technical debt has a significant impact on the long-term success of a project. So, how do you manage it?
- Have a clear understanding of what technical debt is and how it can affect a project.
- Establish a process for regularly reviewing and assessing the technical debt of a project.
For example, you can create a debt backlog, which is a prioritized list of technical debt items. The backlog should be reviewed regularly. You should prioritize items based on their potential impact on the project. - Set up a clear set of coding standards and guidelines for the development team. You should design your guidelines so that they minimize the amount of debt your team introduces during the development process.
For example, you can use code reviews, pair programming, and automated testing to help reduce the amount of debt you’ve introduced. - Have a plan for addressing and paying down technical debt.
Allocate a specific budget for debt reduction, or dedicate a specific amount of time each sprint for addressing technical debt items. Set a timeline for when you’ll address debt items, and to regularly track progress towards that goal. - Invest in communication. Encourage people to raise concerns they have about technical debt, and keep stakeholders informed about the potential impact of the debt on the project. Clearly communicate the trade-offs and the plan for addressing it in the future.
In other words: Understand, assess, plan, and communicate.
What are your technical debt principles?
Principles are a short list of “rule of thumb” guidelines that act as your North Star when making decisions and prioritizations. As organizations and teams grow, they’re a tool for helping you to work more inline with one another, with shared intentions, understanding and more confidence to make decisions.
Having organization-specific principles means that you can have a shared culture on a decision that’s appropriate for:
- Your development and DevOps culture overall
- Your team structure and growth
- How much is too much debt for your organization
How much is too much technical debt?
So, we’re defining, planning and we’re tracking. Great. But while some technical debt is inevitable, the ultimate question seems to be: How much is too much?
Some key things to measure when assessing how much debt is too much for your organization:
- The cost of maintaining and updating the software over time. As your debt increases, so will this cost.
- Development speed. As your debt increases, your speed will decrease.
- Risk. High levels of technical debt can increase the risk of bugs, bad user experience, risks to sensitive data, and time to fix issues.
- Team capacity. If not managed properly, technical debt has a common symptom of draining the time and focus of your skilled workers. Is this the best use of their time?
Codescene offers a really helpful way of calculating the impact of your debt based on how much of your work is unplanned work:
“If your organization spends more than 15% on Unplanned Work, then that’s a warning sign that delivery potential is wasted and technical debt is likely to be a significant chunk of that waste.”
While it’s tempting to look for a one-size-fits-all number to define “too much”debt, what’s clear is it’s worthwhile to discover how the debt impacts your business.
We’re seeing more and more organizations set up dedicated functions for handling technical debt. This not only gives more control back to development teams, but positions them as decision-making leaders your business.
