I write software. It is sometimes imperfect. I become aware of imperfections by issues that are opened (or reopened) in a Bug Tracking system.
There's a sense in which a software issue is like a crime and a sense in which it is like a disease. My two favorite television shows, Law and Order: Criminal Intent and House show the detective and doctor solving problems much like a software engineer diagnoses and fixes bugs. (Yes, it is better if bugs are "designed out" ahead of time, but that's another post.)
Bug Tracker issues should be "phenomenological" focusing upon the outward indications of incorrect behaviour of the system in question. However, similar phenomena can arise from diverse failure mechanisms.
For instance, one can have pock marks on one's skin from Chicken Pox or from Measels. Though the doctor would like it if both maladies received distinct bug tracker numbers, he can't count on that. As the fictional Dr. Gregory House would say, "Patients lie." He is unfair. Patients reflect phenomena and it is his job to see past phenomena to underlying failure mechanisms.
The challenge of a bug tracking system is to accurately track observed phenomena and root failure mechanisms. Bug Tracker does a good job of the former, when I'm smarter, I'll suggest something to address the latter. Perhaps the software engineer should look to the medical or the forensic communities for patterns to apply to this problem.
1 comment:
I think Jim McCarthy already drew the medical parallel in "Dynamics of Software Development". I'm not sure, but I think DeMarco and Lister did the same in "Peopleware". It's a decent analogy in some ways, as analogies go.
But there's a down side to the analogy as well. Meaning no disrespect to the medical field, it's clear that some doctors are good diagnosticians, and others are more pedestrian: they know the common bugs that are making the rounds, expect to see those, and so they DO see those, even when there's a different problem. They try the common, obvious stuff first, and only dig for more unusual answers when the obvious falls short.
And of course, that's the way it is with software diagnostics as well. Few people can sniff out the root cause unerringly, time after time. Worse, some software folks make snap judgments, and then stick to them even when there's no justification. And since users don't report symptoms very accurately at all, the job gets even more complicated. Software people get arrogant and callous, and come to assume that the users are lying to them. It's an ugly situation, all the way around. (It happens in medicine, too. A couple of years ago, I scratched my leg too roughly, and somehow ended up with a nasty case of cellulitis that threatened to take me left leg. One doctor at the med center took about half a look, declared that it couldn't have been a scratch and I must be hiding something, and walked away.)
Diagnosis isn't an easy skill to teach in software (and, I assume, in medicine). You can teach some tools. (Why, why, WHY do some programmers avoid the debugger unless you force them to use it? Many's the time at that old torture mill where I would ask people what they saw in the debugger, and they never even looked. Ten minutes in the debugger, and I would find most problems in their code.) You can teach rules of thumb (i.e., always assume the problem's in your code). You can teach techniques, like unit tests. But it's hard to teach instinct and intuition, and I think those are key attributes. As you say, it's detective work.
Post a Comment