Is there such a thing as a good bug?
I was dreaming last night that Shai and I were cleaning an old apartment, when a hockey puck sized bug crawled onto Shai's hand. In real life there would have been screaming. In the dream she lifted it up so we could both look at it.
I am not an entomologist, but I'd be surprised if this was a real bug. It looked like a giant beetle with a coat of lady bug paint. Shai said there was nothing to worry about, "We want this kind of bug. It eats mice." It certainly looked big enough to handle the job. An insect that doesn't bother you and eats other vermin isn't the worst thing in the world. Attracting good insects is a strategy for pest control in organic farming. An insect is only a pest if it hurts your crop.
Is there such a vermin eating bug in software development? Maybe. First, lets decide to agree, for the rest of this blog entry, that 'bug' means flaw in your software, rather than a visible symptom. Is there a difference? You bet. If you rely on undefined behavior, that happens to be true right now, by the bug = flaw definition you have a bug. By the bug = symptom definition you do not. (BTW- Don't kid yourself, if you rely on undefined behavior you do have a bug.)
Right now, bug = flaw is any insect in reach, and bug = symptom is paying attention only to the bugs you see killing your plants. So far, these definitions are not helping
to create a category of good bugs. You obviously don't want to ship software with symptoms, and you don't want to ship software with unseen flaws waiting to crawl out from under the counter. Where might one's person's bug, be another person's useful insect?
The answer is in testing, and I can give two examples, thanks to having read Michael Feathers' Working Effectively with Legacy Code. One example is a flaw in style. Using protected data members in C++ is considered bad style because it breaks encapsulation. The root of the argument is the same as for why public data members are bad. I think of it this way: How do you write an abstraction function, or an invariant for your class if you cede control over the data? Your class either needs to be a container that does not encapsulate or it should make it's data private. Another example is an implementation flaw. When you create a singleton you want to ensure there is only one such object. If it is possible to create another instance then there is a flaw.
So multiple singleton objects and protected data members are examples of my mouse eating, lady bug painted, giant beetle. These can be considered software insects not because your customer cares about protected vs private or multiple singletons. These are software insects because someone tending your code (maybe even you) could step on them and create a big gooey mess.
How might these software insects be useful? It is useful to use each of these 'flaws' as a seam to test your code. A seam is a place where you can highjack functionality without changing the callsite you want to test. Substituting a derived class during testing is a very useful technique. In legacy code it can be a good practice to move private data to protected simply to allow the derived testing class the control it needs to do it's job. You then need to use engineering discipline rather than the compiler to ensure that you maintain your invariants. This is a techinique where you are trading compiler checked goodness for a possibly greater goodness ... deep targeted testing.
Often a singleton is used when you are enforcing a direct mapping to something physical (such an external input device). Imagine you are writing a software program to guess a person's birthdate by their weight on a scale. Do you want to test it by automating the placement of actual weight on a scale? Or by making a fake version of your singleton scale class and instantiating it?
There are alternative designs that avoid the need for a scary yet helpful software insect to provide testability. However, if you live in a code base that was not designed for testing, think about how these software insects could be your friend, as you travel toward those better designs.