Do you know what a "regression bug" is?

All the readers that are not programmers, can safely get their eyes crossed. Most would not know differences between "regression bug", "logic bug", "blunder in implementation", "this will not work, but let's try it anyway" or any other type of "bug" (which, btw is an umbrella term to enclose pretty much everything that can go wrong in a software) from each other. For the end user, there is no difference; the software does not work as it is supposed to, and it needs to be fixed. Preferably yesterday.

For software developers, designers et al., there is a difference. Regression bugs are the most common type of bugs when new functionality is being added to existing code. And usually, fixing it is not really hard - though finding the reason might take a while.

In laymans terms, a regression bug is "something that worked as expected before, but no longer doesn't". Most of the times this happens, it is unintentional. Then again, if the feature was that previously was working, but no longer is, it being removed from a new version is not a bug - in that case, it is a "design decision". Sometimes it is necessary to remove features from software. Most of the times, this is done with long and careful consideration. Clients do not want to chabge the way they are used to doing things, so if you deliberately remove a feature, you better have a damn good excuse. The most common reason for doing it is "maintaining that feature in the future would slow down all development". Better yet, if the feature is something that nobody uses (anymore possibly), well... it can go.

But yeah, there often are unintended regressions in functionality that are bugs. Because they happen often, is why they have a specific name in software developers' vocabulary.

These days, pretty much all of the professional software is composed of tiny pieces of code that are meant to do one thing and one thing only - but do it consistently, so that the same small piece of code can be called from a multitude of places - to do that one thing with any input we decide to throw at it. This is a good thing - because if we find an even better way to do that one thing, we only need to change it once... and every part of the code that uses that piece of code will be working... "better" by definition.

In theory, there is no difference between practice and theory. In practice, there is.

What works for most situations - even though the base problem might be the same - doesn't necessarily work for all of the situations. And these few situations where things don't work are the ones that cause regression bugs.

Imagine an axle that is able to hold a number of wheels of various widths (just for the fun of it). You've made the axle 100cm long. Before you had four 20cm wide wheels on the axle. No problem. Then you add a fifth one. Still no problem ... all the wheels are still on the axle. One day you add another feature to your program (a new wheel) that is supposed to use the same axle as the previous five wheels, and you get a regression bug. One of the wheels drops off from the other end of the axle and no longer does what it is supposed to do.

In real life, it is easy to see that one of the wheels has dropped off. In software development, finding this out might be a lot more complicated. Perhaps that is not an important wheel ... maybe it is only used rarely anyway. All of the other parts (that are not dependent on that one now missing wheel) might work perfectly. But when you try to do something that really needs that wheel ... most likely you will end up in trouble.

Finding out why the end user is getting in trouble might be... umm... troublesome. Finding out how to fix things might be even more so. When you finally find the source of the problem - too narrow axle with too many 20cm tires, you need to decide what to do...

• Do you widen the axle to hold the 6th wheel? What if a wider axle doesn't fit where it is supposed to be?
• Do you make all the tires 16.5cm wide to make six of them fit on the 100cm axle? What if the tires really needs to be 20cm wide in order to work? Can you make the tire have larger diameter to have the same internal volume in 16.5cm as it has in 20cm width?
• Do you make another axle to hold the extra tire (and possibly something else you would like to add there later on? What problems will that bring?

Like said, regression bugs are amongst the most common ones encountered in software development. Test teams arethe main way to keep them from appearing. But this is slow... Because not only the latest changes need to be tested - but also everything else... just to see that there are no regression bugs. And if there are, the testing begins again from the start - because when the problems were fixed, this might have created new ones. This is the main reason why software testing of new versions might actually take longer than the actual implementation of new features.