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.

Debugging ain't rocket science, they say...

Well, apparently, sometimes it is. On other times, it just feels like that.

Many software developers are - for the most of their time - tasked with debugging their software; just in order to make it absolutely impossible for the program to make mistakes that could (in the worst case, for example in case of the above linked lunar module example) cost lives... or - lead "the people in charge" to wrong conclusions.

Why am I blogging about this? Well, perhaps it's easier to tell what it is that I "do" for living... I am a software developer; if I had any family, after work I'd go home and my children might ask me "daddy, what you do today?"... to which I couldn't do anything but simply answer that "I performed my duties as a software developer" - and leave it at that. Anyway, for the past 10+ years, I've worked on a project that supposedly is used to follow who works on a company and does exactly what. Furthermore, the system is designed to keep track of what the said workforce actually can do - and what it is supposed to do.

Even though it is not designed for this, I do know - without a shadow of a doubt - that the system I've designed is sometimes used to "create the unemployed". Granted, the software is not designed with that goal; instead, it is meant to measure what each and every worker within a company should be capable of - and what they indeed are capable of. Unfortunately, these days it very often means that the workers that aren't capable of what is expected from them... are "let go". They are the ones who should be able to do a given thing, but - for one reason or another - arent't capable of doing it.

So... why would I be interested in this? Well, to put it in simple terms - because I think it's necessary. I personally would feel like shit if I learned that someone - even one person - were to be "gotten the boot" because of a program I made told his/her supervisor that s/he ain't fit for the job.

How does this influence my work? For one thing, I want to make it absolutely certain that whatever I code meets the criteria set for it - at least. Also, I want to be able to understand what is actually expected of the code. This helps me point it out for the people who are in charge of determining what it is that is being designed when something it is supposed to do is illegal, or - to a lesser effect - not something it should be able to tell about people. Even though everyone says they want to know everything... honestly - they don't. They want to know what they need to know - and that is usually very far from "everything".

Anyway - to get back to the subject... sometimes debugging software honestly does seem like rocket science. When you work with a given software for a number of years, it tends to "bloat". New features are (often) added, old features are (more often than not) redesigned to work differently. Sometimes, due to all these new things and possibly some old things not working like they've originally been designed... or some old things not working as originally designed because of the new things - well... things just tend to break up. Something that was designed for one thing gets used for entirely different thing. Something that was never supposed to be used at all is brought in as an indispensable new feature. When all these redesigns occur, it is possible that something that (at the time it was designed) was very much something users couldn't live without - becomes the source of multiple problems. A piece of code - that originally did a very distinct work - now does many things... and some of those things manage to mess things other pieces of code are supposed to handle...

Those are the days that make software developers very sad. Unfortunately - all they do is code based on what is needed. When they see their "child" becoming corrupted... what can they do - but weep... and hope for a better tomorrow. And do their bloody best to keep the thing they originally lovingly brought into being from becoming a monster. Well... I think that is something every parent might face at one point or another.