I stumbled across a YouTube of P giving a techtalk at Google. I am always amazed that he says so much I immediately agree with. That is rare for me. It is so gratifying to find someone who seems to see the world the way I do. I am very lucky.
But being as hypercritical as I am, I have a bone to pick. P and others in the group use the term "bug". It really bugs me (pun intended) since I subscribe to Dijkstra's view that there are no bugs, only programmer errors. While this is primarily a semantic issue, I think it has profound pedagogical and professional implications and I refuse to let my students use the term. As you may know, the term stems from the early mainframe days when they contained many relays, were required to work at night because of their power draw and were in areas that had warm evenings. This required opening windows in the days before AC and moths were inevitable. Since machine failures were often the result of the pesky bugs interposing their bodies in the relays, it was necessary to "de-bug" the relays by sweeping them out of the relays prior to running the program. So a bug at that time had nothing to do with a mistake made in programming.
My objection to the term is that it distances the programmer from the mistake that was made. While I appreciate the humanness of not wanting to continually make mistakes, waving them away as something coming from the atmosphere and inevitable in the course of writing programs is not helpful to achieving the highest-quality software. What is needed is for programmers to aspire to writing the code correctly the first time through careful thought and planning. With the average module size shrinking with OOP, this is more possible now than it was in the bad-old-days with goto's and large modules. At least locally.
Once you can appreciate the pain and discomfort of being in a profession where achieving the perfection demanded of the formal machine is recognized as the inhuman task it is, you can appreciate my desire to find improved methods for the translation of a consistent, comprehensive and complete requirements document into a design and implementation that can be error free. This has been the domain of formal methods but my belief system allows that something more human is possible.
An aspect of this was driven home to me today when I needed to activate an HSA debit card. The details aren't interesting but the result was a very frustrating experience. The experience was diminished by a series of process errors that individually were easy to accept but collectively left me ready to wring someone's neck. They included a voice response system that sent me in circles, a customer service rep that was unrealistically chipper yet incompetent, a claim by said rep that she was only allowed to wait up to two minutes for me to find the information she was asking for (despite having kept me waiting for a collective 6 minutes while she needed to go somewhere else to handle parts of the transaction) and a headset that made it very difficult for me to hear her.
If this kind of customer service snafu was unusual, it wouldn't be worth the pixels to complain. But this is now more common than not when requiring any interaction beyond the common and repetitive from a service organization. The problems go beyond programmer error since they are failures of the processes at a higher level and include both the automated and human systems that comprise the service product. My aim is to get to the bottom of how organizations can rush such half-baked processes into production and find it so incomprehensible when customers become increasingly dissatisfied when they are increasingly assured that excellent customer service is what they are all about? I contend that the failures to properly design the overall process is the same failure that leads to code bugs.
Another colleague gave a presentation on an intriguing plan to create a database of "bugs" that can be queried for insight into the source of the "bug". I accept that such work is needed since we are a long way from methods that will yield error-free code. But shouldn't the emphasis be on understanding what cognitive slip caused the coder to create that error in the first place and not merely the repair after it is discovered? P's talk at Google struck me as closer to the mark since I can see how it could be adapted to the code-generation phase as well as contribute to the repair phase. Despite how passe they are, I still believe that P's talk is closer to patterns than anyone is willing to say out loud. But then this talk was from 2008 and that was soooo long ago.
I have a lot of catching up to do.
Wishing you beautiful code
d
No comments:
Post a Comment