How to Identify Technical Debt in Your Software

Tech debt is scary, but there are some simple ways to ensure it doesn’t get out of control. Find out how to identify technical debt so you can stay in control of your software.

Ugh. It seems like the type of thing that could have been avoided, but there it is, like a lurking gravitational collapse that may eventually swallow you up…

It’s tech debt…

And you may have more of it than you think.

But… What, exactly, is technical debt?

Technical debt is the term used to describe the time (and money and resources) that will need to be spent in order to rebuild a software item that’s already been “completed.”

While technical debt is often the result of rushed development decisions, it usually accumulates under four basic scenarios:

1. Your definition of complete software does not include adequate review or testing.

2. Your development decisions are involuntarily rushed because your process is disorganized.

3. Your development decisions are intentionally hasty to accelerate a project (meaning, you actively choose a more easily deployed solution over a more perfect solution that would require more development time at the outset)

4. Tech debt can accumulate on the sly.

In this way, tech debt is quite like financial debt; you can take-out a “loan” knowing you will eventually have to pay it back, or– your tech debts can accrue over time, little-by-little.

This gives you the opportunity to address it little-by-little, but if you close your eyes to tech debt, it will eventually unleash itself like Cthulhu from the depths and you’ll realize that, just like that, your software is barely above water.

How to Identify Technical Debt in Your Software 1

Ultimately, tech debt can drown software. If you don’t actively prevent and pay back technical debts, they can be as crushing as their financial counterpart.

As you can see (or, maybe, as you know from personal experience), tech debt can be ugly– and neglecting it? That’s even worse. But if you learn to recognize technical debt and if you actively build coding habits around avoiding and eliminating it, tech debt can be no sweat.

The first step towards getting out of tech debt is recognizing that your in it. That process is the focus of the following advice…

How to Identify Technical Debt

The most telltale indicator of technical debt is user feedback.

The purpose of software is to serve the user. Ultimately, everything a software developer does is motivated by enhancing user experience. If, instead, your UX is clunky or convoluted, it may be the result of old and unpaid technical debts.

As a software system grows, technical debt will arise in areas that are more-or-less forgotten and also in those that are highly refactored. Both neglect and perpetual change create opportunity for tech debt to accrue.

To combat continued accumulation of old technical debt, pay attention to the ways users behave while using your software. Notice areas where they struggle and areas where they drop-off altogether. Review the code construction of those features and you might find some revealing truths about your software’s performance.

Because bad code is just plain bad.

How to Identify Technical Debt in Your Software 2

The silver lining, though, is that bad user experiences can lead to good changes within your coding structure. If deficient code is rebuilt (or removed altogether) you might considerably improve your UX (which is a really good thing).

You can also identify tech debt by listening to your software.

Just like a slow leak precedes a flat tire or a sore throat signals the common cold, your software will tell you if it needs help.


Monitor load speeds, test speeds, performance issues, and, most importantly, audit the errors that come from within your system. If you don’t have something in place to gather information about errors within your software, implement one.
DevSquad uses Bugsnag, and it helps us be accountable to everything we build. If your give your software a voice with which it can inform you of potential technical issues, you are empowering yourself against compounding technical debt.

Using a tool like Bugsnag reduces the margin for human error and it puts potentially hidden issues at the forefront of your process. Like pinning your electric bill to the refrigerator or setting a reminder to pay rent on Friday, a monitoring tool will help you address technical debts before they become problematic.

Not surprisingly, another combatant of tech debt is conscientious software developers.

A good coder can smell tech debt. That doesn’t always mean that he wants to dig into it like a Christmas pie but, most savvy developers can sense tech debt when they see it.

For one thing, technical debt can make code incomprehensible. As if it might actually be the result of dark magic, even experienced coders can look at a pile of festering tech debt and think, “how in the name a Java did this happen?

In other words, tech debt is often messy, and code that is difficult to read, can also be extremely difficult to repair. For this reason, many developers will simply live and let live. Meaning, they ignore it. But avoidance is like adding another nail in the coffin…

You see, just like financial debt, unpaid technical debts can create a snowball effect where, the longer you ignore it, the more it’s going to grow.

To reduce tech debt, you have to create development habits around two ideals:

1. minimizing the amount of tech debt you take-out in the first place

— and —

2. actively eliminating the tech-debt that already exists

I know it’s hard, but it’s best to deal with technical debt as soon as you recognize it.

Because (yes… there’s more…)

Technical debt can be volatile, too.

You know that saying about poking the bear? The one that says, well… don’t poke the bear?

Technical debt is like that. It’s like an angry Grizzly that, if provoked, might break all your bones and/or devour you (perhaps like a Christmas pie).

How to Identify Technical Debt in Your Software 3

If you’ve ever gone toe-to-toe with a rough section of tech debt you know that is NOT a overly dramatic analogy. In fact, if you HAVE encountered a rough section of tech tech, it probably taught you to avoid it in the same way you would avoid a mama bear in the woods.

But those development habits create bigger problems in the long run. In fact, it’s probably what created the tech debt in the first place…


Lastly, I want to reinforce that fact that…

You can identify (and prevent) tech debt by being constantly aware of how it occurs.

Just like good developers can smell bad code, they can also produce it. Of course, unforeseeable things will befall you as you develop software products, but don’t put your developers in the kind of position where they are forced to or feel pressured to write bad code.

You can do better than that…

So– take adequate measures to monitor your software. Audit software performance and user behaviors, listen to user feedback, plan for everything (so you never have to cut corners), enforce accountable development habits, and never ignore the monster. If you do, it will only get scarier.

It’s also wise to stay involved with your development team. Bad coders can make tech debt problems even worse. Check out this other article on how to identify a bad developer.

Have a scary story of your own? Tell us about your close encounters with technical debt!

Want to avoid scary software development stories in the future? We can help with that… Get our free email course here >>

how to build a software product


Mallory Merrill is product manager and editorial director for DevSquad, a true Agile software development company in Salt Lake City, Utah. Working for more than a decade in the technical world of content- and software-writers, Mallory aims to bridge the gap between code and copy. Her work is driven by a passion for language, and the belief that effective communication is the backbone of all healthy businesses.

Leave a Reply

Notify of