Extreme Programming As Justa Way To Stay Busy

If a bug is defined as something that "bugs" the user then it may not be possible to write a test for it.

Imagine this situation: The customer is demonstrating the new software to the team as we like for them to do. Something happens. The customer says, "I hate it when that happens." Developers naturally ask what it should do instead and get a reply like, "I don't know. I don't really understand this myself. But I don't like what it just did."

When this happens an agile developer smells opportunity. Although there is nothing yet to be put into words, nothing to be assigned, nothing to test for, there is something that a human can understand. Anyone with 50 points of "emotional IQ" understands what "I hate when that happens" means. It means something isn't as good as it could be and when we figure out what it could be we are going to know something valuable.

I think of paying attention to this sort of thing as "priming my sense for discovery". Someone else might call it keeping track of things we need to do. I like to do it in my head. Someone else might like to write things down. If they called their writing a "bug database" I could see how they might have gotten to that term. But I would start to get nervous. I'd be nervous because I'd think this might be a way to think less about the "bug" than thinking more about it which seems to be the appropriate activity.

But then I think of ExtremeProgrammingAsJustaWayToStayBusy while you are waiting to have brilliant ideas. I think it is the brilliant ideas that move a project forward. When a "bug" is a brilliant idea waiting to happen then we should keep it and ponder it until the flash happens. But if a "bug" is just a mistake and we know what to do about it then let's just do it like Ron says and get on to the good stuff feeling free.

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006