How to Keep from Drowning in Technology Debt

Are you drowning in technology debt? No, we’re not talking dollars and cents or Dave Ramsey’s debt snowball. We mean the kind of debt that piles up when you cut corners with your software stack in order to launch a software project more quickly.

Root causes of technical debt may lie in substandard programming, lack of skill, pressing deadlines, or patched-together systems. Debt can also take the form of a calculated risk designed to launch a product sooner for quicker results.

The Lowdown on Technical Debt

Programming pioneer Ward Cunningham first coined the term “technical debt” as a metaphor for launching a product based on the knowledge you have, even if that knowledge is incomplete. In this sense, you are in “debt,” because you will have to go back later and modify the code as you encounter insufficiencies or bugs.

Over time, the concept of technical debt has evolved to include writing code poorly with the intention of working out the bugs later.

Essentially, when you incur technical debt, you’re borrowing time to launch your product sooner, while acknowledging that you’re going to have to eventually pay that time back.

The benefits seem obvious: you can reach revenue and productivity goals earlier by hitting an aggressive deadline.

But many companies fail to count the costs. If the software doesn’t work as intended, you could be dealing with unhappy customers, mushrooming support costs, and plummeting employee morale.

It’s easy to forget that you’ll have to spend time later refactoring the program to incorporate newly acquired knowledge. If you don’t, you’ll eventually be doing nothing but fixing bugs—the equivalent of paying only the interest on your credit card without ever making progress on the principal.

Good Debt and Bad Debt: Understanding the Risks

In the financial world, we understand the concept of good debt (like your house) vs. bad debt (like a high-interest credit card). We take on good debt with the understanding that we’re making an investment that will increase in value over time. Bad debt, in contrast, decreases in value over time and ends up costing much more than it’s worth.

Martin Fowler has done an excellent job of carrying this concept over into the technical arena with his technical debt quadrant:

In this graph, Fowler describes four kinds of technical debt:

Prudent and Deliberate

Prudent debt means that you have made a careful, intentional decision to adopt a software product roadmap in order to release the product sooner. This is the preferred way to operate because it gives the greatest opportunities for strategic solutions and future-proofing.

Reckless but Deliberate

This kind of debt is by nature deliberate, because you have assessed the risks and chosen to move forward with a strategy that will yield results in both the short and long term. In this scenario, you know the strategy isn’t sustainable long-term, but you’re willing to move ahead because you have a plan for filling in the gaps later. For example, you realize that beginning to capture revenue sooner will improve your overall ROI significantly, and so you launch an MVP version of your software with plans to iterate with future phases.

Reckless debt can also be deliberate when you have a team who understands best practices such as unit tests, but chooses to press ahead without them for the sake of a quick release. Sometimes, this choice is forced by aggressive timelines that were set without regard to the true effort required to develop software. C-level executives who choose a timeline before scope should beware of creating this kind of technical debt.

Prudent but Inadvertent

In this example, you’re trying to build software the right way, but a knowledge gap causes you to make poor decisions somewhere along the way. This may be on the developer level—your code quality is poor because you hire an individual or a firm that isn’t up to snuff on best practices. Or it could happen because your business doesn’t understand what users want, or what parts of the business process it makes the most sense to automate using software. You’re on the road of good intentions, but you end up in software purgatory because you didn’t know the right questions to ask or the right people to work with. You realize somewhere along the way that you missed something big, but it’s too costly and time-consuming at that point to pivot toward the software solution you should have had the whole time.

Reckless and Inadvertent

This is a project marked by bad planning and bad code. This approach—which no one would recommend, of course—creates crippling problems later on as you scramble to fix the mess. If you can’t or won’t take the time to write clean code, you’ll undermine the project from the get-go.

No matter what approach creates technical debt, when it starts to accumulate, you either have a plan for paying it back or you don’t. If you don’t have a plan, you’ll be unable to move forward with new features and upgrades. Instead, you’ll be scrambling to fix the problems that keep popping up before they derail your company.

If you find yourself knee-deep in technical debt, what should you do?

How to Solve a Technical Debt Problem

Since technical debt can take different forms, people have conflicting opinions about how to manage the debt you’ve already incurred. Companies that have adopted prudent, deliberate risk management strategies most likely already have a plan in place for paying back that debt, so we won’t address those scenarios here.

But what about the other categories?

In some ways, dealing with technical debt is similar to dealing with financial debt: you pay off the high-interest debt first. Steve Garnett categorizes debt based on the potential for providing value to your organization:

He recommends placing highest priority on those projects that will be valuable to the business both now and in the future, and working your way through technical debt from most to least valuable:

Now that we’ve identified which kinds of technical debt to fix and when to fix them, let’s take a look at a step-by-step process for managing your technical debt efficiently:

Define It

Technical debt includes any shortcuts the coding team made in order to meet deadlines. Understand the difference between desirable architectural changes and debt incurred by not following coding best practices or by taking the wrong approach at the outset. If necessary, call a meeting that includes both your development team and end-users. Users will know where system bugs are causing workflow blockages, and developers will know where coding inefficiencies make it difficult to move forward with new features. One key here: track bugs and errors so that you can diagnose true issues instead of just dealing with symptomatic problems.

Measure Costs

Assess problem costs by tracking metrics. Determine which issues create the biggest revenue and productivity problems, and which ones have minimal costs.

Prioritize Fixes

Based on your cost assessment, determine which issues to address first. Some applications may be OK with maintenance fixes, while others need to be redesigned right away. Applications directly related to the success and profitability of the company should be addressed first—especially if they are essential to future business needs. Note here that some low-priority issues may need to be fixed before developers can effectively triage larger issues. That means you need to balance business needs with software development fundamentals when making your priority list.

Identify Bottlenecks

When critical tasks flow to a single person, bottlenecks happen. Identify those bottlenecks and make a plan to solve them. That may mean assigning additional developers, or it could mean removing other responsibilities for the developer at the crux of the issue. Having a project manager or quality control engineer test usability and report issues can help to do this. Team leaders may need to share responsibility for efficiency at this stage to make sure projects keep flowing smoothly through the pipeline.

Test Continuously

If you save your testing for a separate sprint, you encourage careless coding. Instead, build testing into your agile sprints so that bugs can be squashed before moving on to the next stage. And don’t consider a sprint done until it passes unit tests with thorough coverage.

Depending on the extent of your technical debt, working through the debt elimination process may feel burdensome and time-consuming. But just as financial debt repayment yields big dividends if you commit to the process, technical debt repayment will also free you up to move forward—if you invest the time and energy to take care of it now.

One more tip: try to touch things once and once only. As you work to fix technical debt, see where the areas you’re working on overlap with your product roadmap. If possible, group fixes and upgrades together so that developers only have to touch an area once. This will take good communication between your developers and project leaders. Developers will need to say when this is possible and when it’s unwise, and leaders will need to trust their developers’ conclusions and support them in their work in order to truly make progress.

Living the Debt-Free Life

We’ve already discussed a few situations in which technical debt might make sense for your business. But what about the rest of the time? How do you avoid future technical debt?

Answer: Adopt a higher quality development process.

At Worthwhile, we have built our reputation on delivering quality software so that our clients have no regrets. We use Django and Python to build a system that integrates seamlessly into your current business structure. Our process also includes robust testing methodology so there won’t be any surprises.  We also offer warranty periods after software launch and ongoing security and version upgrades to keep your software up-to-date over the lifecycle of your business application.

Making the commitment to avoid unnecessary technical debt may require a philosophical shift for your team members and stakeholders. By committing to quality coding on the front end of the project, you can keep timelines and budgets from spiraling out of control in the long run.

So how do you know when you have a technical debt problem?

When it takes your team longer to pay off interest (fix bugs and maintain functionality in the code of a flawed app) than to pay down principal (allow new information to shape your software strategy), you know it’s time for a debt reduction strategy.

Maybe Dave Ramsey’s debt snowball has something to teach us after all.

About Worthwhile Storyteller

We'll never tell you a lie, but we might tell you a success story that protects the intellectual property of our clients and partners. Our Worthwhile Storyteller is an amalgamation of all of our thoughts, experience, and expertise brought together to give you the facts about our relentless improvement in the software development space.