Lee Copeland's fictional story about getting children to clean their rooms struck a chord with many of our readers, who compared it to getting developers to test their code. Here are Lee's responses to your feedback, along with a few insights about the dynamics behind developers examining their work.
My column entitled "A Fable" was originally published on StickyMinds.com 13 October 2000 and recently republished as part of the first anniversary celebration of the Web site. The fable-a story about getting children to clean their rooms-was actually conceived at EuroStar 1999 during a panel discussion in which a new tester asked, "Why don't developers do a better job of testing their own code?" I was a member of that panel. When the question was asked, the other members of the panel gave the standard (ho-hum) answers. While I was struggling with something useful to say, the story popped into my head. It was not meant to be an accurate representation of the world. It was meant to be entertaining and thought provoking. And thought provoking it has been. When published on StickyMinds, more than twenty of our readers took their time to comment on the article. I would like to thank them and respond to some of their comments.
Andrew wrote, "There's a flaw in the metaphor," while Subin called it "a good analogy." I don't see the article as either metaphor or analogy-it's a fable. Webster defines "metaphor" as "a figure of speech that makes an implied comparison between things which are not literally alike." An analogy is "a resemblance in essentials between things otherwise different." I made no claim of either comparison or resemblance. The story is a fable, "a short tale intended to convey a moral truth." Laurie commented, "I don't think it offered any realistic tactics." It was not meant to. In fact, it ends asking a question rather than proposing answers. (I learned that trick from Socrates, who had lots of questions but claimed to have no answers.) It is interesting how many readers compared it to software testing, though perhaps not surprising, since this is a site dedicated in part to testing. Assuming, just for argument's sake, that the fable has some relationship to software testing, let's consider some other comments:
Andrew wrote, "You cannot, in practice, achieve quality by cleaning up afterwards; you have to do everything you can to prevent creating a mess in the first place." He is absolutely correct. That's why the testing of analysis and design artifacts is so important. Even so, that will not obviate the need for unit and system testing; some defects will always slip through.
Vicky wrote, "I have it on good authority that cleaning your room will inhibit your freedom to make a really impressive mess!" My daughter is the perfect counter-example to Vicky's claim. I can require a spotless room from her, but the next day, if I'm not looking, it's back to its messy state.
Laurie stated, "I agree wholeheartedly with the comment that testers are not room cleaners, but rather room inspectors." And I agree wholeheartedly with Laurie. A major role of testers is to find defects, not fix them. We should not allow ourselves to be sidetracked from that role.
Jim asked how to deal with incorrigible parents but then added, "the real task is in breaking a cycle wherein the grandparents didn't put a high value on a clean room, and thus neither did their children-today's parents." Grandparents? Why stop there? Let's push the guilt all the way back to the original sinners (Charles Babbage and Lady Lovelace).
On the other hand, another member wrote, "This type of article does little more than help bolster the reputation of QA professionals as arrogant…believing engineers to be incompetent."
Finally, Bret wrote, "My room is me and i am it. My room is where i like to be and it looks like all my dreams." Bret, thanks for sharing.
But all this takes me back to that question the new tester at the EuroStar conference posed, "Why don't developers do a better job of testing their own code?" I believe there are three significant reasons.
First, many organizations do not perform even an elementary risk analysis to understand what "clean enough" means. One of James Bach's great contributions to our field is the concept of "good enough testing"; the weighing of the costs to our company of additional testing against the costs that would accrue from delivering defective software. About the fable, Larry asks, "What's the value proposition to the kids to perform the activity?" In most cases, we don't know. And if we don't know, how can any of us determine what is good enough and when to stop?
Second, we don't pay enough attention to defining, training, implementing, and supporting effective testing processes. About the fable, Jim notes, "…if parents…are willing to invest in this end, then the battle is more than half won. … Some lip service is given to the concept of a clean room, but this often results in paltry room-to-cleaner ratios such as 10:1." Clearly, if we don't know what is good enough, then we cannot know at what level to staff and support testing.
Third, we don't generally reward testing by developers. About the fable, Jim suggests that, "At some point, a level of (professional) maturity should awaken these 'children' to the importance of cleaning their own rooms." I disagree. Rather, I think that David hit the nail on the head when he wrote, "The children are not rewarded for cleaning their rooms." I would add, nor are they punished for not cleaning. Many of your comments place the blame on the "children." I would place it squarely on their management. If our reward/punishment mechanisms are "upside-down," if we reward the wrong thing, if we punish the wrong thing, we will get the wrong thing. Most human beings understand the reward/punishment mechanisms at work in their organizations and conform their behavior to them. When we see behavior that is curious, strange, or just plain wrong, we should first examine what is being rewarded and what is being punished.
Thanks to all of you who commented. I appreciate your contribution to our understanding.
