Technical debt: How to take it on and manage it responsibly

They say slow and steady wins the race, but in the frenetic world of software development — you snooze, you lose.

Businesses that don’t get products out the door or seize emerging opportunities with both hands often fall by the wayside. But how do you complete features and products faster with limited resources? The answer: Take a shortcut.

It may seem like bad practice to cut corners when it comes to coding, but when speed yields greater returns than perfection, it’s the only way to go. Of course, shortcuts don’t come without a cost — and the same is true in software development. It even has a name: technical debt.

Like financial debt, it can be both good and bad, depending on how you manage it. Stay on top of it, and it could be your business’ route to speedy growth. Ignore it, and you’ll end up in a black hole that could sink the entire operation. Read on for definitions, examples, and tips!

What is technical debt?

Technical debt (aka ‘tech debt,’ ‘design debt,’ or ‘code debt’) is what happens when developers take shortcuts to complete a product or function faster. As a result, you’ll have to revisit and improve features in the future — whether that’s fixing bugs, completing missing documentation, or revisiting legacy code. Other types of technical debt include knowledge that the dev team doesn’t share around the organization and code that’s too complex to modify quickly.

Originally coined by software developer Ward Cunningham (the guy who’s credited with inventing the wiki), technical debt was a neat metaphor he used to explain to non-techy stakeholders why it’s important to budget for refactoring (the process of restructuring existing code).

The helpful phrase caught on. Years later, when asked about how he came up with the technical debt metaphor, he said the following: “With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money, you’ll be paying interest. I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back, and as you learned things about that software, you would repay that loan by refactoring the program to reflect your experience as you acquired it.”

So, when you choose speed over perfection, at some point, you’ll need to go back and address that ‘debt.’

As Ward Cunningham goes on to say, “The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

What are the benefits of technical debt?

Not all debt is bad. Managing it well can bring huge benefits, including helping you or your company reach your goals faster. This is especially true for businesses that need to grab emerging opportunities and/or test product or market fit. But as with financial debt, you need to pay back technical debt. Accumulated debt can slow you down, cause your products to break down, overwhelm your developers, or even sink your company.

“The cost of never paying down this technical debt is clear; eventually the cost to deliver functionality will become so slow that it is easy for a well-designed competitive software product to overtake the badly-designed software in terms of features,” says Junade Ali in Mastering PHP Design Patterns.

“In my experience, badly designed software can also lead to a more stressed engineering workforce, in turn leading to higher staff churn (which in turn affects costs and productivity when delivering features). Additionally, due to the complexity in a given codebase, the ability to accurately estimate work will also disappear. In cases where development agencies charge on a feature-to-feature basis, the profit margin for delivering code will eventually deteriorate,” he adds.

To summarize, here are some things technical debt is:

• A tool for achieving goals quickly
• Something that has consequences

Three types explained

In Essential Scrum. A Practical Guide to the Most Popular Agile Process, author Ken Ruben uses the following three categories to define technical debt:

• Happened-upon technical debt: This is debt the dev team didn’t know existed until it was exposed during routine product use or maintenance. For example, the team is adding a new feature and spots a work-around was added to the code years ago and left unchanged. It can also be caused by ‘bit rot,’ which happens when code deteriorates over time, altering its function and usability.
• Known technical debt: This is debt the developers know about and is visible.
• Targeted technical debt: This is known debt that the dev team will revamp.

This has been further split into a multitude of subcategories, the most popular being intentional and unintentional technical debt. Let’s go into those in a little more detail.

• Intentional tech debt (aka ‘deliberate debt’) happens when organizations leave room for improvement in their code for the sake of speed.

• Unintentional tech debt (aka called accidental, passive, outdated, or inadvertent debt) happens when the code needs improvement for a number of unintentional reasons. E.g., poor work the first time around, or code that’s simply out of date and needs a refresh.

The Technical Debt Quadrant

Beyond what we’ve already explained, Martin Fowler (who, alongside Ward Cunningham, was one of the 17 authors of Manifesto for Agile Software Development), created something he calls the ‘Technical Debt Quadrant.’

Fowler took the two-part definition and added more nuance with the goal of digging out more relevant questions.

Rather than asking whether something was technical debt or not, he thought it more worthwhile to ask whether the debt was ‘reckless’ or ‘prudent.’ From there, look at the ‘deliberate’ or ‘inadvertent’ categories.

The quadrant creates four new technical debt categories:

• Reckless and Inadvertent
• Reckless and Deliberate
• Prudent and Deliberate
• Prudent and Inadvertent

Deliberate and inadvertent is the same as intentional and unintentional, whereas prudent and reckless are entirely different from any of the other categories.

Prudent arises when the team has made careful, informed, and purposeful decisions. Reckless happens when the team accrues a debt without discretion.

Answering whether the cause of the debt was prudent or reckless behavior isn’t an easy question to address. The team needs to be self-aware enough to know when it’s doing good work (or not), and that’s down to nurturing a team culture of accountability — something we’ll go into in a little more detail later on.

How to manage technical debt

As with financial debt, burying your head in the sand is not a good strategy. Managing it takes awareness, monitoring, and a commitment to keeping it under control.

This isn’t easy. It often feels less important to go over old work than to work on getting something new out the door. Teams and project managers are busy and often under the pedal to keep releasing updates and new products. It’s important for managers to learn how to prioritize. Part of this lies in seeing the importance of technical debt recovery.

Here’s an eye-opening stat: Stripe estimates that ‘bad code’ costs companies globally almost $85 billion.

Image Source

Meanwhile, Research by Gartner says that companies that have a strategy for technical debt will ship 50% faster. So how do you get it under control? Here are some tips.

• Invest in company culture: Getting everyone working from the same book is vital. This means putting procedures in place that keep people accountable (and ensure everyone’s following the same instructions).
• Follow DevOps practices: Having teams that are siloed isn’t great for collaboration or communication. Follow DevOps (or DevSecOps) practices to get people working together cohesively.
• Invest in your codebase: Perform in-depth QA tests and consider automating your continuous delivery pipeline.
• Invest in a project management tool for developers, such as Backlog: This makes it easier for developers to identify, report, track and prioritize debt reports without making big changes to their workflow. And, because you store information in a central repository, no wires cross or duplicate jobs exist.

Final thoughts

Just like in the real world, debt is both good and bad. If you manage it well, it can help you grow and thrive in a fast-moving market — but ignore it at your peril.

Managing technical debt efficiently begins with company culture. If you put procedures in place that ensure code is refactored as a matter of routine, give development teams time and space to work on improving code, and invest in project management tools that make it easier to track and manage improvements, then a little bit of debt needn’t be cause for concern. It could even be the thing that helps your business pull ahead of the pack.