Using QA to Seek and Destroy Technical Debt

Technical Debt

A friend of mine, a skilled electrical engineer, spent 5 years working at a steel mill. Among the terrifying stories about dangling over furnaces in death-defying feats of engineering prowess, he told me another that stuck with me. 

This steel mill produced high volumes, around the clock, with barely a moment’s downtime. But whenever an electrical fault brought it to a lurching halt, it cost the business hundreds of thousands of dollars per minute. The pressure was always on to fix things fast.

When he got his first call out, he opened up a cabinet, tech diagram in hand, only to find an unrecognisable jumble of wires, patched connections and mind-bending mess. It looked more like a plate of dropped spaghetti than anything in his diagram.

Naturally, it took him longer to fix than it should have. Each engineer was simply getting the job done as fast as they could, using whatever quick & dirty fix they could. Each one leaving a tougher job for the next person.

The mill’s ‘technical debt’ snowballed. 

technical debt cartoon

Same goes when you take this approach to app development. Every time you release a quick & dirty fix, you’re making a withdrawal against the future of your business. Accumulating ‘interest’ in the form of extra work, time, energy, and possibly even downtime. 

Left unchecked by your QA resources, tech debt builds up until you have the dev equivalent to rewiring a whole steel mill

Is technical debt always a bad thing? 

Not necessarily. Some tech debt is unintentional, some is deliberate. Are all loans bad? Most people take out at least one loan in their lifetime. A mortgage for example. We do this while fully understanding that we make a forfeit in the form of interest, but that the property itself is likely to appreciate more value than interest paid long-term. And we get to make use of the property in the meantime. If you wait until you’ve saved enough to buy a house outright, you’ll be waiting an age and accrue all the costs of renting in the meantime.

Mortgages are, for most people, a useful tool to jump ahead in the game. The same can be true with tech debt.

For example, startups rely on speed to market, even if that means sacrificing a little on quality and accruing ‘interest’ in the form of future work and costs. Later on, adding features will be harder and take longer, but a minimum viable product might be the only way to grab market share before a larger business with more resources pips you to the post.

For more mature businesses, quality takes precedence over speed. The risk of an unchecked bug is an army of disgruntled customers abandoning your app, leaving bad bad reviews and an overwhelmed support team. 

What causes unintentional technical debt?

Most technical debt is unintentional. Nobody sets out to create software that’s difficult to maintain and build upon. 

“Causes or roots of tech debt should be understood within the team to find out what techniques or approaches produce an inexcusable result. That will be the bad technical debt to fight against. Everything else – we can call it good/soft/tolerable technical debt – can be eliminated out of the equation.” 

— Dmitriy Barbashov, the Chief Technology Officer at QArea  

Common causes of technical debt:

  • Deadline pressures

  • Being unaware of tech debt and its consequences

  • Failing to see or manage knock-on effects

  • Communication missteps

  • Internal skills gaps
  • Lack of suitable testing

It’s not always possible to eliminate every root cause. 

But you can reduce tech debt build-up by uncovering bugs and delays, understanding how they got there and making a ‘repayment plan’ before it becomes insurmountable.

How to rid yourself of technical debt

Even household names like Twitter have had a brush with technical debt at some point. An early stage decision to build their front end on Ruby on Rails made it hard to add new features and optimise for SEO.

As they grew, they realised they needed to begin an arduous switch to a Java server, lowering their search latency and therefore paying off their technical debt.

An extreme example perhaps. But this is where you can find yourself if you’re not keeping on top of your technical repayments as you evolve.

There are two main roads to debt-free code. 

1. Refactoring (your tech debt repayment plan)

Refactoring is the most common approach. It could be a one-off project but more often, an ongoing project because technical debt has a domino effect, rippling through your codebase as you seek and destroy the bugs.

You’ll need a process to:

  • Identify issues
  • Prioritise
  • Fix
  • Document 

Avoid clogging your release cycle by mapping the problems to be solved over several releases. Meanwhile, hold off on new releases so you don’t inadvertently add more problems as you go. Plan for this to take weeks or months if you’ve been accruing debt for years.

2. The clean slate method

Like bankruptcy, it’s a radical approach, but despite the alarming parallel, it could be the better option. If you can start over from scratch, it could save you months of refactoring. Depending on how far into the red you are, it could be cheaper and faster than correcting one piece at a time. If the cost of new features is spiralling and missed deadlines are damaging your business, this extreme option is worth considering.

QA’s role in technical debt management

Most developers know that shortcuts rarely pay off. But when the leadership team prioritises speed over quality too readily, engineering hands are tied. With the right processes, people and support, technical debt can be kept in check. That’s where QA and testing come in.

At GAT, we help engineering leads tackle their technical debt. We can do this by running an initial report on all the bugs in your backlog, or via an ongoing reproducibility basis.

Once you have a clear picture, we’ll work with your team to define and execute a strategy to attack that debt in a smooth, stress-free way. We can even run exploratory tests to check whether bugs still exist so you can identify what’s safe to build upon vs and what needs fixing first.

If you’d like to learn more about avoiding, fixing and managing your technical debt, speak to one of our experts today for a free consultation.

Was this article useful?

Great! We'd love to send you more articles like this

Subscribe

white-dots-small@2x

Join 24,389 people who already get the latest QA advice - unsubscribe any time!