Fors Clavigera

Perhaps bugs are a necessary evil of the economics of software development; perhaps market forces will continue to drive feature change and improvement at a pace that overwhelms maturation. More mature areas of technology, while still offering opportunities for improvement, generally have learned to avoid the biggest pitfalls. And that, I think, is a useful way to think about bugs: as an opportunity for learning. A bug is feedback about your process. If you don't pay attention to that feedback, you've wasted an opportunity to learn; you can't afford to do that very much. In this analysis, "bug" means precisely a development process fault which leads to the implementation of unintended or undesired behavior. It is possible for developers to abdicate all responsibility for requirements analysis to some external agency, which would reduce the previous phrase to "unintended and undesired behavior"; however, our best current understanding is that we serve our customers better by integrating the intention with the implementation. The code is not separate from the specification, and we can best learn about the customer's needs by delivering code to them and listening to their reaction. In fact, much of what we do in software development is to learn. We learn new languages and libraries, we learn new customer's requirements, we learn new buzzwords. Also, in debugging and maintenance, we learn what mistakes we've made. We learn to avoid those bugs in the future. There are two benefits of catching bugs as early as possible: one is that it's a lot cheaper to fix a bug earlier rather than later. The other is that, by catching a bug earlier, we tighten the feedback loop and make the learning more effective. Much of modern software development, from developer-driven unit testing to IDE's with syntax and error highlighting, has the beneficial effect of providing earlier and better feedback to the developer, to help their learning. I don't know how to automate higher levels of feedback. A compiler can, with a statically-typed language, catch syntactic and "semantic" errors. We are, I think, feeling our way towards processes and cultural mechanisms that enhance feedback at the higher semantic levels. An engaged user community, able and willing to provide feedback on partial releases, can give feedback on misunderstood and evolving requirements (which is truly semantic). There may be a missing level in the middle. Most of the bugs I've committed over the last decade, and certainly the hard ones, have been due to design failures -- an unclear partition of the system that made it hard to implement some particular piece. The bugs showed up in the hard module, but that module was hard due to design problems. Refactoring helps with this, when used to re-shape the code according to an evolving understanding of the structure of the program. So does shared ownership of the code, so that problems that show up in one section of code are not isolated as one person's problem. Global improvement may have to be at the cost of added complexity of some local sections of code; shared responsibility makes it easier to make the right decisions in those cases. This is a cultural, not a technical, question. I don't think that automated tools or heavy formal defect-tracking processes have proved their worth in this arena; un-read and pro-forma meetings have little effect on behavior. We need a culture of continuing improvement, of dissatisfaction with "good enough". Formal methods can help foster this culture, and can be useful as a way of recording conversations so they need not be re-created from scratch; they can also disguise the real benefit and masquerade as improvements when they are really mechanisms. The best answer that I have is that talking about bugs helps. Let's not fix our bugs in silence and shame. Let's shoot the breeze about them; let's tell war stories; let's value our bugs as feedback and as chances to think and talk about what our program design should have been and can in the future be.