Developer Insights – Stories & Analogies

Last week, a group of friends were going to get together for lunch.  The restaurant, chosen before I was invited, happens to be one where I saw some insect life on my last visit.  So I declined to join them.  I didn’t bother to provide my reasons nor did I suggest another place.

Now this last visit was about 10 years ago.  You might suggest that there should be a statute of limitations for these sort of things and that I am being totally unreasonable.  I would agree with you.

But then what is the formula for calculating the time?  Does it matter if it was a single critter or multiple?  Are mammals different than insects?  Does the ownership of the restaurant matter?  Does the cuisine matter?  How about the restaurant next door?  How about other establishments in the same chain? Does it matter if it occurred during your first visit to the establishment or if you had been a long time patron?  Does it make a difference if it occurred before you had ordered the food or as you were paying the bill? Would it matter if you were there alone or if you were there on a date?  How about if it occurred on a special and memorable occasion, say Mom’s 50th birthday?  And where were the health inspectors?  Did you report the sighting to the waiter? To the health department?

Given the alternatives, I am willing and able to go elsewhere.

So how does this relate to software development?

1. How would you feel about discovering a bug in the development tools that you use?  Would it be more worrisome if it was the compiler or if it was the debugger?  How about in the third party libraries that you are using?
2. Are bugs encountered during installation more worrisome than bugs encountered during an uninstallation process?
3. Does a defect in one piece of software influence your opinion of the likelihood of a defect in another piece of software with similar functionality, say a defect in one compiler is likely to appear in another compiler?  a piece of software from the same company?
4. Do you know what software uses the same underlying code?
5. Do you know what code was written by the same people?
6. Do you know what code  was written with the same processes?
7. Do your customers have different reactions to defects?
8. Do you expect software to have certain “defect density”?  If testing uncovers an abnormally large number of defects, do you congratulate the testing organization?
9. Do you report defects to other engineers? to other teams? to other organizations? to other companies?
10. Do you believe customers report all the defects that they encounter in using your software?

Back on Nov. 13, 2007 I read “How Doctors Think” by Jerome Groopman. In it, Groopman explains the thinking that can result in medical mistakes. I was struck by the similarities between his doctors and anyone who has to deal with defects in software.

Among the issues he presents are confirmation bias, availability bias, the uncertainty of the expert, the affability or obnoxiousness of the patient, the importance of gatekeepers, prototypes of conditions  or disorders, anchoring, and diagnosis momentum.

Groopman concludes the book with an epilogue that lays out a number of questions that patients can use to help their doctors avoid mistakes.  Rather than reproducing them here, I have recast them in software terms.

• Ask “What else could it be?”, combating satisfaction of search bias and leading the engineer to consider a broader range of possibilities.
• Ask “Is there anything that doesn’t fit?”, combating confirmation bias and again leading the engineer to think broadly.
• Ask “Is it possible there is more than one defect?”, because multiple simultaneous defects do exist and frequently cause confusing symptoms.
• Tell what you are most worried about, opening discussion and leading either to reassurance (if the worry is unlikely) or careful analysis (if the worry is plausible).
• Retell the story from the beginning. Details that were omitted in the initial telling may be recalled, or different wording or the different context may make clues more salient. (This is most appropriate when the defect has not been located or there is another reason to believe that a misdiagnosis is possible.)

So how does this relate to software development?

1)  If you have a series of defects that appear to be duplicates do you make sure your fix will actually fix all the defects that were reported?

2) Do you have customers that you hate to hear from?  Do you ever discredit a defect report because of who submitted it?

3) When a defect comes in from the support organization, do you try to start fresh in R&D and not accept support’s diagnosis?

How Doctors Think

BusinessWeek Review

Jerome Groopman’s Web site