Not all bugs are equal

Some things matter more than others. If the software is flying an aeroplane full of people, then it makes sense that you should want to invest a lot more money into formal methods of identifying and fixing bugs and testing to destruction. It’s worth the time and effort. Compare that to a misspelt label on a button. Everything else sits in between these two extremes.

Bugs vs Features

A feature is just a difference between the product you have and the product you want.

A bug is just a difference between the product you have and the product you want.

Modern software is complicated, and software isn’t static. Everything is constantly changing. Your application doesn’t live on its own. Even if nothing changes in your web application, devices and web browsers change (and can have bugs in) which cause a problem in your application.

Software development costs time, and therefore money. Each bug and feature have to be evaluated to determine if it’s worth the time and expense to fix. If only new features are developed then over time bugs will proliferate. If just bugs were fixed, then new features will never get built. The real question is determining the level of quality that is acceptable. Fix the things that need fixing, and don’t worry about those that are not worth the investment.

Bugs are development

In an ideal world, there would be no bugs because there would be unlimited time and money to deal with them.

Good developers will have incorporated practices into their development processes which seek to produce fewer bugs. These include editor tooling, test-driven development, and code analysis.

Good developers don’t want bugs, it reflects poorly on them; they will do as much as they are able to within the project constraints to minimise them—but there is a cost in the time needed to follow sound practices, so there is a “hidden” cost to this quality. Clients and developers need to have an open discussion about the level of quality that is acceptable within the bounds.

As a client, if you feel that the rate of bugs is too high (are you even measuring this?), then you should discuss this with your developer to understand the reasons behind it. Then a plan can be put in place to progressively decrease it. If the developers cannot improve then perhaps it’s time to find alternatives.

If you feel that the bug rate in your own Ruby on Rails web application is too high, and you need some help to reduce it, we specialise in the support and maintenance of Ruby on Rails applications. We can work with your existing team to improve the codebase and reduce the bugs or help to improve development practices to prevent the occurrence of bugs in the first place. For an informal chat about your current challenges, contact us today.