Odd Bugs, all the where – all the time

As developers we all know that we can cover our code as much as we can, but the odd behaviours will be there waiting to our code is in production to bother the users of our products.

Recently my team and I have been fighting with really extrain bugs, all because we decided to migrate one of our application servers to a new one with newer versions of OS and of course, newer versions of all the 3rd components we use as well. We use lame to encode the audio files users upload into our system, and this process worked fine in the old server and in the new server with the same execution line we were getting very poor quality files. We debugged the entire code and it was exactly doing the same on both servers, we had to review the release notes of the different versions of lame we were using and, with no luck, we couldn’t find what was causing the error. After a long process of collective thinking, tests etc, we could notice that our code was printing a very large number (6 digits) to set the bps param. In the oldest version of lame it makes the quality good while in the newer version it makes it poor. Finally we got an idea of where the issue was going to be.

We went back to our code and all the parameters were right and all the lines were in place, but one of the guys could notice a slight difference in one line… the difference between =~ and = ~   was causing the error.

I wanted to share this example because all of us have to waste time on that type of issues when we are responsible of a product with real users. How to prevent this, use as much tests as you can in your code, but that won’t bullet proof your code either.



2 thoughts on “Odd Bugs, all the where – all the time

    • Great question, that was the first I thought when we realized what the error was, there’s some steps to follow, to set you in context for this particular case, we are programming in a non strict language and that is why the error was really difficult to get, so my first suggestion is to use a language where the IDE is capable to caught this errors before saving/compiling. For our case, this was a var type validation before the system line was executed, the right thing to do is to stract that logic to a private method and create the equivalent Test so that, the error can get caught by the test harness when is run.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s