According to this article, there are two types of people in this world.

1. Those who understand that software will never be perfect and every good (and bad) software company ships products with known bugs
2. People who don’t

It goes on to recount how those of us from the the first group often forget what it was like when we were once part of group 2, and we often don’t understand when people react with horror and dismay that we would release a product before we fixed every know bug.

I have to say I agree.

Working as a developer for an e-commerce company I’ve come to realize bugs are a part of life. Its probably different for developers working on a single product where bugs are found, and the fixes are released, but in this area, while a lot of the process is the same, there are differences.

The vast majority of our work is bespoke. We make e-commerce sites for people. People want different things. Thats just the way of things.

When a client want the system to be able to handle multiple images for products, we put it in as a new feature of our default store. No problems. All future customers will have that option. Then again, what if they want something more bespoke to them? Maybe they want the checkout process to do something different to what it does at the moment?

These are the types of changes that cause the longer term problems for you see if there is a bug in the default store (and yes - there are bugs in the default store, come on, you’re not from group 2 are you?) it becomes part of this bespoke store.

Fixing the individual bugs may not be the problem, moving the fix across all sites is.

Firstly we need to find out if the site is affected by the bug. This depends totally on the site. If their bespoke development affected the area we’re going to be playing around with then we’re either home free or in trouble.

Case 1. We’re home free. This happens when the bug occurs in such a place the either the site specific coding has caught the problem and replaced it, or it was already fixed for this site (and not integrated back into the default store) during the development process. This is what we always hope for.

Case 2. We’re in trouble. Unfortunately this is far more often the case than case 1. The client has asked for some strange functionality and this has changed the specifics of what happens for this site. Now not only do we have to fix the bug, we also have to re-engineer the fix for this site so as not to break it anymore.

So thats the problem. Its never a simple case of fixing a bug then releasing it into the world. For every bug we have to go through possibly hundreds of sites manually. Not what we want by any means. Which brings me back to the original article.

choosing your (bug) battles

To reduce the amount of bug fixes and free up time from just fixing bugs all day to do some actual work we need to ask the following four questions about every bug:

1. When this bug happens, what is the impact? SEVERITY
2. How often does this bug happen? FREQUENCY
3. How much effort is required to fix this bug? COST
4. What is the risk of fixing this bug? RISK

The first two questions are questions for the customer (or someone assuming their view) and the last two are for the developers.

From the article, the author suggests plotting the first two on a graph of severity, with the vertical axis the severity, the horizontal the frequency. So a bug that happens every day and causes the user actual physical pain would be in the upper right corner, while a bug that is only noticeable to a developer’s trained eye and only when running a whole suite of obscure browsers to test with would be on the bottom left.

Allow me to illustrate with a lovely graph.

This is what is meant about choosing your (bug) battles. In this instance the blue dot (the very bad frequent bug) would be fixed, while the red (the rare tiny bug) would not be fixed.

If we decide to proceed with fixing a bug the last two questions come into play. Cost and Risk. Cost can be best measured in time, ie. how long would it take one developer to do the work? Risk is a sort of catch all. Its the wild card here.

What if the bug is in a part of your code that you know is full of loop holes and, for want of a better word, hacks. These loops and hacks aren’t necessarily bad. They’ve been put in over time to fix real problems, and they work. They fix the problems. If you go along and start playing around with it - even rewriting it from scratch you enter a very dangerous area. As developers we must learn to leave well alone at times due to one simple truth:

Every code change introduces the possibility of new bugs.

That very fact should weigh on your mind every time you go crawling around old code. I know it does on mine. So if the part of code your bug is in is a dark and dangerous place, take that into consideration before ‘fixing’ it. Every change you make brings up the possibility of more problems, more bugs to fix, and so the cycle repeats.

Considering these 4 questions on each and every bug you come across may seem extreme but luckily the experienced developer can usually run through these decisions in only a few seconds without ever consciously thinking about it. Of course there are occasions where it will take a grouping to solve it and decide the course of action, but then again, thats just what its for isn’t it.

So thats it for now, at least till I go through and correct some of the spelling.