while (2)

Don't Wait For Bad Things To Happen

Luca Sommacal -

This thing has happened to me so many times that I start to think bad luck is real. The situation is the following: a product is on the market since several years and everything works fine. At some point, a customer reports a strange behavior. You start to look at the problem and find an horrible bug that is there since the beginning. In the time you think about a solution, implement and test it, at least two other customers report the same issue.

How is it possible? How is possible that for years everything worked fine and in one week three different persons find the same bug? The only answer I have is...

The Murphy's Law

There are several versions for it but I believe that it can be summarized in this way:

If anything can go wrong, it'll go in the worst possible way.

This may seem pessimistic but knowing that every bug can be potentially catastrophic, can help us to be more focused and more critical about our code. What I've seen frequently is cutting corners to meet deadlines (yes, Your Worship, I'm guilty too) with the promise of doing the right thing in the future. But usually that future will come when it's too late and a customer has already found the problem.

The only way I know to prevent this kind of issues is to plan periodical revisions of the code that can lead to refactoring sessions. Another idea may be to have a checklist of things to verify before put your program in production. For C programs it may be something like this:

  • no strcpy() allowed - use strncpy()
  • no sprintf() allowed - use snprintf()
  • check for NULL pointers
  • check for memory leaks
  • ...

So now you are ready to revise all the code of your team to improve it, right? No!

If It Ain't Broke, Don't Fix It!

This is an old adage that is difficult to deny. So, what's the right balance? I've seen performance optimizations made by removing vital checks. I've seen commit messages claiming "removed useless code" made by developers that didn't understand why that code was there.

Well, to me, it all depends on your experience and your knowledge of the code you are gonna change. You are allowed... nay you must improve the code, but you must also know what you are doing. And this is the most important thing!

By the way, if you are in doubt, ask someone more experienced than you.

Image by Live Life Happy taken from Flickr licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Generic license.