Back to all posts

What Is Technical Debt and How To Manage It: A (Not Boring) Guide To Erase the Pain

When you are in software development mode and moving quickly towards a goal, it’s super easy to put the blinders on and go, go, go. You sense everything isn’t quite perfect but you’ll take 85% because hey it’s better than 50% and if you slow down, everyone slows down, and THEN WHAT. So that 15% of Uh-Oh just sits there, not being awesome and not getting fixed.

Well, you know what happens when something just sits there eating chips while nobody watches—it gets bigger. So you slap a bandaid on it, because easy fixes are, well…easy. But taking the easy way out for the sake of speed doesn’t just eventually slow you down, it brings you and your product progress to a screeching halt.

You need to understand technical debt before it bankrupts you. Let’s take it step by step:

  1. What is technical debt management?
  2. Understanding the technical and non-technical causes of debt.
  3. How to avoid technical debt (and if you can’t, how to manage it).
  4. What are the different kinds of technical debt?
  5. Mistakes to avoid when managing technical debt.
  6. Pro tips for managing technical debt.
  7. Some final thoughts.
  8. FAQs

What is technical debt management?

What is technical debt management?

In its most basic form, technical debt is the gap between expectation and reality. Your company expects a certain standard of quality when it comes to software development. But when the actual state of the code base of your product doesn’t meet that standard, that’s the tech debt gap.

Technical debt can actually increase over time, even while your product progresses. And your company’s standard of quality can change over time, too. What you considered great code when you were in the garage writing the first iteration for a few hundred beta users is going to be very different when you have millions of users relying on your service.

Now, in order to determine where the gaps are, you have to get each piece of functionality to a “ready to release” state, aka “done.” To get to that point, it has to go through a simple checklist (if you’re a startup), or a more robust one (if you’re a more mature organization).

For example, a startup may include on their checklist:

  • Code review
  • Full code coverage with unit tests
  • Ensure there are no high or critical bugs

A more mature organization checklist has the above, plus:

  • Basic documentation
  • Architectural review and sign off
  • Security pen test sign off
  • Scalability test
  • Maintainability review
  • And possibly more

No matter how big your company is, or how you define “done,” it’s critical that the definition is standardized, well-defined, and adopted company-wide. If it is fragmented, you’ll have individual teams—or worse, individual developers—deciding when thundercats are a go. (And we all know how hard it is to herd cats.)

So, once you’ve defined the definition of done and wallpapered your office with it, it’s time to assess whether you’ve met the ready to rock standard or not. Assess with each team to see what parts need to be brought up to “code” and then estimate the amount of time required to do just that. What is missing is your technical debt.

The last part of managing your technical debt is important. You need a smart, crisp policy of how to handle it. Your best bet? Prioritize bringing up the base where it will need changes for future enhancements.

Avoid any extreme policies. And don’t put a bandaid on a gaping wound. Weak solutions = weak product.

Slamming on the brakes to pause software development so you can clean up technical debt is just as bad as pretending it’s not happening while you’re going 100 miles an hour. Technical debt is real.

Allocate time to fix it wisely so it doesn’t steal mojo from all of the other new feature needs.

READY TO SKIP TO THE END AND JUST MAKE YOUR TECH DEBT PROBLEM GO AWAY?

CALL US—WE’RE ON IT

Understanding the technical and non-technical causes of debt.

Understanding the technical and non-technical causes of debt

There are six main ways technical debt accumulates. But not all technical debt is tied to the tech itself. When you understand that this invisible part of growth can’t be ignored—especially as you grow—you’re one step closer to getting ahead of it. The six ways technical debt snowballs are:

  1. When you don’t know what tech debt is (you’ve read this far, so this isn’t your problem)
  2. When you know what it is, but don’t know how to measure it
  3. When you know how to measure it, but you don’t do it
  4. When you measure it, but then choose not to address it
  5. When you don’t enforce quality standards
  6. When you level up from idea validation to scaling

That last one is actually the number one cause of technical debt accumulation. Every time you raise the bar, the code that was written prior to that falls short. That missed reach is your tech debt. As you grow and increase expectations, until your product catches up, you’ve got debt—you can’t expect a two-person development team to reach goals meant for a much larger group effort.

Other more common scenarios occur early on when operational speed is more important than quality. We’ve all been there. A client needs something yesterday? Well, the client is always right, so which corner can we cut today to get there faster?

So even though a development team knows better, sometimes they can’t actually do better. If company culture or leadership forces shortcuts, it’s either because they don’t understand the technical debt ratio, or that they aren’t measuring it to begin with.

NOT MEASURING? HELLO, RED FLAG. YOU NEED MORE SUPPORT ELIMINATING YOUR TECHNICAL DEBT.

WE’RE HERE TO HELP

How to avoid technical debt (and if you can’t, how to manage it)

Let’s be honest. You will not be able to avoid technical debt if you grow. And growth is the goal, right? Right. The good news is, there are ways to minimize how much technical debt accumulates, as well as the resulting impact.

Where to start? Call us, obvs. But also, invest your time into a lot of automated tests. Make code coverage for automated unit tests a top priority for your development teams. Why is this piece so important? Because if you need to rewrite a code base, and you have unit tests for your whole application—including that area of code specifically—you can proceed with confidence knowing that whatever changes you make won’t break anything.

The reality is that most companies who have not invested in good automated tests either don’t refactor much or are afraid to deal with technical debt. It’s the head-in-the-sand approach. Cute, right? Nope. In fact, the chances that it will break something important and they won’t catch it with manual testing is way too high.

From where we stand, we like to follow the Golden Rule of Technical Debt. (What? It’s a thing!)

The Golden Rule is, always know how much debt you can live with at any point in time and how long it will take to pay it down

If you know your definition of done, and you can estimate how much time is needed to pay down your technical debt fully, you have the number you need.

A good measurement tool we’ve found is to measure it in terms of full team time. So, hypothetically, if the whole team stopped everything and just worked on reducing the debt to zero, how long would it take? If your answer is around 6-9 months, you’re in good shape.

Why is 6-9 months the magic number? Because if you’re keeping time with your competitors and are pretty comparable in terms of innovation, putting that innovation on hold for six months isn’t going to break you (it might feel like it, but ride the wave, you’ll come out the other end hanging loose).

Now, if you have so much debt that putting all hands on deck still wouldn’t dig you out for three years, you’ve got a problem on your hands. To state the obvious, that is a long time and will be a big setback. Even if you only put half the team on it, that’s six years of digging (and of doubling your R&D costs).

What are the different kinds of technical debt?

What are the different kinds of technical debt?

Since existing technical debt is anything that falls short of the current quality standard that you expect from new code, it can cover anything. But usually it falls into the following categories:

  • Maintainability: Debt accumulates when your code is hard to maintain and modify because of how it was built. This can also include documentation and other code standards such as style.
  • Scalability: Code that doesn’t scale well creates debt. Generally speaking, it should be easy (and cost effective) to scale code to around 5-10x usage.
  • Security: Code that isn’t secure or has vulnerabilities creates debt.
  • QA: A poor experience due to bugs in the system=debt.
  • Automation test coverage: You can avoid debt buildup when you have the code covered with auto tests—everything from unit tests to end-to-end scenario tests.

It’s super important to note that automation is critical when attempting to understand and address technical debt. If your development teams do everything manually, as you scale you will need an ever-growing number of engineers to maintain and develop the code base.

The smartest, most productive teams use automation. Whatever intellectual work they’ve done is only done once—and then it is done over and over again automatically. With automation, new work is always interesting, consistency is ensured, and the team doesn’t need to hire more and more people.

A second important note is that a quality standard is hard to increase beyond a certain point. If you aim for perfect code, you won’t ever be able to release any new features. The most critical thing here is that you refrain from asking your team to deliver against a standard it has no muscles to do. Set them up for success instead by setting a standard that has an understanding of the expected speed of new feature development embedded into it.

Mistakes to avoid when working to manage technical debt

Let’s say you’re building a house on a tight schedule and you find a buzzing wasp’s nest in one of the walls. Do you pull every contractor over to tear the wall down and get each last insect gathered up, losing precious time and missing the deadline? No, you don’t. You allocate some manpower to fixing it, while most everyone else keeps hammering away. And you make darn sure there are no more nests in the vicinity.

Similarly, you can’t go from one extreme to another when managing technical debt. Most companies unearth debt they didn’t know existed and in a panic, argue that everything has to pause while the debt is managed. For other important parts of the product process, sure, everyone in the pool. For tech debt, never.

It’s normal to have some. You’re going to be good if you measure it, create a sustainable process to pay it down, and prevent the accumulation of more debt within upcoming new features.

STILL FREAKED OUT? NO SWEAT, WE’RE COOL AS A CUCUMBER. CALL TURNKEY AND WE’LL HELP YOU KISS YOUR TECH DEBT GOODBYE.

CALL TURNKEY

Pro tips for managing technical debt.

Pro tips for managing technical debt

We’re not saying tech debt management is easy or simple. But if you have a plan (we can help!), you’ll be able to manage technical debt while still pushing production. Here are a few pro tips to live by:

  1. Have a company-wide, standardized definition of done
  2. Enforce that definition of done for all new code
  3. Measure new technical debt every quarter (at least) and estimate how much work and time it will take to pay it down
  4. Incorporate that pay down into your regular process (build it into work you’re already doing in that particular area of code base)
  5. Make sure your non-technical leadership (the ones that always want to go fast) understands what tech debt is and what creates it. That way if you have to step on the gas, everyone knows—and agrees to—what the technical debt cost will be upfront.

Some final thoughts

Tech debt might be inevitable, but it’s not an ogre hiding under the bed. In fact, when technical debt is managed correctly, it’s a sign of a growing company. (Nice work!) Just be responsible with it. Measure your tech debt and factor it into your decisions around how fast you want to develop new features.

If you have recently discovered you have technical debt, congrats. That means you have customers and you are growing. Tech debt is kind of like taxes—nobody likes paying them, but if you have to pay taxes, that must mean you have revenue. Just make a plan, so when it comes time to pay, you can handle it without breaking stride.

STILL NOT SURE IF YOU HAVE TECHNICAL DEBT? CALL TURNKEY. WE’LL HAVE A PEEK AND SET YOU UP WITH A PLAN.

CALL TURNKEY TODAY!

FAQs

What is technical debt?

There are various kinds of technical debt, but basically, it’s the delta between your (ever-rising) standards and your code as written. Everyone has it, and those who have a plan to address it are winning.

We have technical debt and I’m freaked out. I should put everyone on this problem, right?

Wrong. Don’t halt all production. Call TurnKey. We’ll help you create a plan to handle the debt you have, and avoid getting caught up in the snowball in the future.

How can I measure our technical debt?

One way is in terms of full team time. If your whole team stopped everything and just worked on reducing the debt to zero, how long would it take? If your answer is around 6-9 months, you’re in good shape. If your answer is longer than that, call TurnKey and we’ll help you keep your balance.

👍 Rating — 0 (0 votes)

Boris Glants

Co-founder, CTO at TurnKey

Subject matter expert.