Why Bug Fixing Costs Companies a Fortune

Imagine you have launched a product that works well. Several versions are in circulation and being used by customers. So far so good. However, bugs in the old versions are giving you a hard time. A lot of time is lost on fixing them and your development team regularly complains about this effort. The reason for this is not the bug-fixing itself, but all the ancillary activities that go along with it. Especially the switch between different versions eats up time. How can this be prevented?

Table of Contents

Bug Fixing costs companies a lot of money

A study from Stripe – The Developer Coefficient – provides an overview over the average time spent on bug-fixing. On average, software developers spend 17,3 hours per week on maintenance tasks (i.e. dealing with faulty code/bugs, debugging, refactoring, modifying). According to glassdoor, the average salary of a developer in Germany is 61.000 €. That’s ~32 € per hour. According to this calculation, companies spend on average ~554 € per week (and per employee) just on bug fixing.

According to a survey from Rollbear, a third of developers spend up to 10 hours per week with bug fixing. 16 % up to 15 hours and 6 % even up to 20 hours.

Sure, the time required varies and depends on many factors, for example the complexity of the software and the experience of the developer. But the studies are providing an overview of the issue.

The costs for the lost time are high: On average and per month, companies pay 2.216 € per developer. Just for fixing bugs.

Why does it take so long to fix errors? How can companies reduce the time and costs?

Why is bug fixing really so tedious?

Jani Hartikainen from CodeUtopia describes the individual steps that need to be gone through during a bug fix:

First we need to understand the problem. This means we need to know what’s going wrong and where, and what is supposed to happen instead.
Next, we need to reproduce the bug. A typical case could be we need to go into the app we’re working on and click around on a few things to see what happens.
Then, we need to figure out which part of the code is causing the problem. We can start this usually by using debugging tools – such as using Chrome’s debugger to step through code on the page where we’ve reproduced the problem.
Once we’ve found the piece of code that’s causing the problem, we need to identify the root cause. Depending on the complexity of the problem, the difficulty of this can vary drastically.
After we’ve identified the root cause, we can finally fix the bug.
Finally, we need to ensure the bug is actually fixed. This is usually done by trying to reproduce it again.

Fixing bugs is so costly, among other things, because the actual bug fixing is only one step of many steps. The process itself will probably not really change in the future.

However, a higher-ranking problem wasn’t mentioned…

The hidden cause and the real challenge

What happens if the bug occurs in an old version? This makes fixing it even more tedious and time-consuming. For developers, this means that the local development environment may have to be set up again. Is a dependency missing? Is the correct runtime available? Only then can they start hammering away at the keys. Once the bug is fixed, the procedure starts all over again. The system must be brought up to the correct level for the current version. According to an ActiveState survey, the largest percentage of respondents (43.68%) needed an average of 2-4 hours to set up the development environment. Setting up a development environment can even account for up to 10% of the total development time.

What does this mean? Companies should find ways to remove this bottleneck – setting up the local development environment – from the daily work routine.

Get to the root of the problem and fix bugs faster

Getting to the root of the problem requires a new approach. Talking to developers, we often get the feeling that working in the local development environment feels like a bumpy road full of potholes that keeps tripping them up. A survey by Gitlab confirms this. 61% of the developers surveyed report that they spend time troubleshooting with their local development environment at least once a month – 31% even at least once a week.

There is an alternative. Remote Development Environments (RDEs) / Cloud Dev Environments:

RDEs make all required versions and variants of the software available to developers in self-service at the click of a mouse.
No cumbersome checking of dependencies.
No time-consuming set-up of the development environment when changing versions.

Read more: Local Dev Envs vs. RDEs

What does this mean? With RDEs, developers can actually concentrate on solving problems and do not have to bother with secondary tasks. A quick review for a colleague is just as possible as switching to a previous version. A bug is therefore not much more than a simple equation that can be solved with a few steps – because the rules and principles behind it do not always have to be relearned. Companies benefit because the newly gained time of the employees can go into the further development of the software.

Whitepaper: Full list of CDE vendors (+ feature comparison table)

Get an in-depth look at how Cloud Development Environments work and compare all the vendors.

Get the whitepaper

Conclusion

Bug-fixing costs companies a lot of money: companies pay an average of 2.216 € per developer per month.
Bug-fixing is tedious because the actual fix is only one step of many steps.
There is a hidden challenge: if you have to switch to an old version, the time required increases because the local development environment has to be prepared for the version. This challenge can be solved with Cloud Development Environments. Cloud Dev Envs are remote development environments that are immediately available at the push of a button. Developers can start working directly. This reduces the time required.