rob was here.

In my career, I've been spending a lot of time lately fixing bugs (or helping other developers fix them) in programming and configuration code of a product that our company sells. These bugs range from poor or over-complex solutions, to blind mistakes in imlementation, to non-robustness, to failed attempts at other bugfixes, to mistakes in code control merging, etcetera, etcetera, etcetera. Surprisingly, I don't think anybody, even the best developers, are really innocent of participation in preparing this poison soup. There are a lot of reasons for this, I think. It has a lot to do with the volume of code, a large body of dozens of architects, developers, programmers, installers, and rapidly changing demands for both features and stability. I am also very aware that this is not something unique to any particular company. Because bugs are such a wide and all-encompassing topic, it's hard to make ANY sort of generalization because someone is bound to call you on it. I'm going to make some anyways.

To the point. Here are some realistic things about software bugs which I have noticed over the course of my rather short stint as a professional software developer. Feel free to contrast against them.

Unless you have one customer (or none), you have bugs, not a single bug. In the real world software gets released to many, many people. A single bug is replicated the number of times it's released. A bug is many bugs, and exists until every instance of it is eliminated. This sounds obvious on the surface, but when you try to control the tracking the simutaneous instances of bugs in the field it becomes rather challenging. In fact, it can easily become enormously complicated. Especially if your customers use varied reversions and altered configurations, or are scattered across various branches, or have customized solutions. Don't get me started about upgrades.

Most people associate the cost of the bugfix with the hours it takes a developer to fix it, or how much of a painful impact it has on the end customer. Unfortunately, this is often how bugs are prioritized. What's much overlooked, I believe, is the replicated cost of people on front-line staff that investigate, re-investigate, and re-re-investigate the same issue (and might not realize it). Due to the rampant possibility of effecting the many, weighing down your support staff may often far outweigh the more traditional views of cost.

Controversy warning! If a bug lives in an area of functionality that nobody uses, does it make a sound? This is probably a controversial statement, especially if fire-breathing security advocates read this blog. Every now and then somebody discovers a "what-if" bug, that may or may not be reproducable, or in a piece of code that perhaps isn't really used. In actual production environments is almost* guaranteed not to occur.

Unless you have endless resources, nothing to do, or the supposed bug is severe enough to threaten some facet of corporate survival, then I really don't see a case for fixing these.

Bugs are really interesting in that they hold a certain value. Bugs in your product are wounds delivered to your softspots, from the enemy. Not only do they point out your obvious mistakes which are often code problems in your display or business logic layer that most any developer can fix, they will often hint towards architectural or model changes which would strengthen the overall system. They are often deeper suggestions that are just whispers, but you can hear them if you put your ear really, really close to the monitor.*