Are You Still Wasting Time And Money Solving Bugs?

SWC Bug Prevention Pipeline

World-wide developers are still spending much time on analyzing and fixing software bugs.

In this article we dive into some of the shocking statistics and solutions on how to get your team more productive, preventing bugs and greatly improving iteration times.

  • Research shows 20-50% more time is spent on solving bugs than creating new features.
  • 75% of a developer’s time is spent on debugging (1500 hours a year!) How much time are your developers working on fixing bugs? How much time are they spending on preventing bugs?
  • As per a 2017 study, 42% of companies indicate they are still testing mostly or fully manually, while most developers agree that automated testing saves a lot of time because of the compounded effect of it’s time gains.
  • 52% of developers spend less than 1 hour on testing per day. Especially when still relying on manual testing at least partly, this means bugs are found by testers, QA or even end-users and the later the line bugs are found, the higher the total cost to fix it.

Are Bugs Inevitable? Can They Be Prevented?

According to a Study by Coralogix developers make 100-150 errors for every 1000 lines of code they write. As a developer for 20-years I can only agree that this is probably true. The question is then not if we can avoid making mistakes, because we all make mistakes – and developers probably more than many other professions due to the complex nature of web-development.

But if we cannot prevent errors from being created, does that mean we cannot prevent bugs? No, in our definition it’s only a bug if it exists after the developer is finished and delivers his or her task.

So the question becomes: how can we help developers from finding and solving errors early, to prevent them from delivering buggy software?

Why Continuous Integration Is Not Good Enough

You have probably heard of Continuous Integration (CI). This is the practice of using tools and automation to verify code automatically, most commonly with automated tests, but this can be expanded to use code style checkers or other tools to help developers spot problems early.

In our opinion CI is great, but:

  • It comes too late in the pipeline to rely fully on it. In our opinion you ideally want to catch bugs during development, when you are still actively working on it, otherwise you’ll have to switch back to it later.
  • It’s often very slow, causing a lot of delays or switching of tasks, which leads to a lot of lost productivity.
  • It’s great at spotting issues, but not great at automatically fixing them. Spotting issues is great, but would be even better to do locally when you are still working on them. Have you ever pointed out some trivial style error during CI or in a PR review? It’s annoying as hell, but during development it’s OK, as it takes 2 seconds to fix.

Developers love to spend big chunks of time just focusing on delivering a new feature. They generally dislike interruptions because their work requires a lot of brainpower and concentration. It’s a major issue then to keep interrupting the developers with failed CI reports, making them switch tasks and solve issues on work they thought they completed already.

If you can find bugs before the code even enters CI, the developer is very much still working on the task and able to fix the issues directly. There’s no switching cost. It’s also much more acceptable to point out style errors and incorrect coding standards locally – or even fix them automatically – then to hopelessly annoy a developer with some trivial style error during CI.

How To Prevent Bugs Effectively

Here at Solid Web Code we prefer to prevent bugs. We use a wide range of techniques that are fairly common in our industry, but taken together and having a great focus on optimizing the iteration speed, we’ve had some astonishing results.

When we talk about preventing bugs, we really mean it. The applications we work on have about 95% less bugs after we have enforced our standards then before.

We are talking about monitoring that proves our point by remaining empty throughout the day. We monitor every bug and hate the practice of “silencing” errors to avoid problems in production, but even so we manage to fix 95% before it gets to production, and even if 5% comes through, it’s generally fixed within minutes of going live.

This way alerts actually mean something and will get a quick and very serious response from our developers.

And yes, we can help you and your team achieve the same results. It can be done on any application and just requires focus and the techniques we talk about in this blog post. You can also let us help you.

Bug Prevention Pipeline: Where Are The Biggest Gains

Below is an approximation of in what stage of our pipeline we catch most issues.

Ideal bug-catching pipeline

One fact is certain: the later in the pipeline you catch a bug, the higher the total time and money it will cost to fix the bug.

We all know bugs that make it to production are the most expensive. An end-user having problems, may need recompense, they will need some support, some way to raise the issue and then development needs to go through the whole pipeline again.

On the other end of the spectrum, finding a bug while still locally developing the feature is the cheapest for obvious reasons. So why not make sure we find most bugs there?

How you ask? Simple. Make sure all automated tests run in a few seconds and developers will gladly execute them over and over again.

“Impossible!” is the most heard objection. Developers using automated testing are often used to the full suite executing in many minutes. In our humble opinion this alone is the biggest roadblock to effective bug prevention at the root.

E-Book: Bug-Prevention Pipeline: Reduce Stress And Make Development Fun & Fast Again

Are you interested to help your developers catch 95% of the issues early and help them speed up significantly and reduce their stress over constant switching?

Download our e-book “Bug-Prevention Pipeline: Reduce Stress And Make Development Fun & Fast Again” below to learn the strategies, technologies and systems we use to create Super-Fast Bug-Prevention Pipelines.