 |
|
 |
 |
|
|
 Jim Cushing's BlogDon't be afraid to be wrongPosted by jimothy on December 08, 2003 at 03:21 AM | Comments (6)As I drove to work one particularly foggy morning, I listened to a National Public Radio report about research done on fruit flies. A scientist believes he had isolated the gene that not only affects whether the flies are better adapted to cold or hot weather, but also their mating compatibility. The cold weather flies mate with each other, while the same warm whether flies stick together. Another researcher expressed skepticism that the single gene the first identified (DS2, if my memory serves me) is responsible for both characteristics, but praised the work for its efforts to push evolutionary genetics further. I'm sure I've got many of the details wrong, but my point has nothing to do with fruit flies or genetics. It's that even if the first researcher is wrong, he still accomplished and learned something. And he did so because he was not afraid to be wrong, for if he had been, he never would have attempted the research in the first place. And you can bet he had been wrong many times before the research was reported on NPR. Alas, most of us aren't researchers. We're not really paid to learn, though it is a daily part of our jobs, and we certainly aren't paid to be wrong. When we are wrong, it can cost our companies and our customers money. If we're wrong enough times, it can cost us our jobs or our reputations, or both. So we have evolved to be positively petrified of being wrong. In software development, the problem with being afraid to be wrong is that not only does it prevent us from taking chances, it lulls us into sticking with our mistakes. We aren't suddenly made right because of our fear; we just refuse to admit we're wrong. We stick with a design even after we've proven it is untenable. We stubbornly refuse to accept one tiny change to our 125-page requirements document because it will jeopardize the schedule. Congratulations, you've delivered the project on time. Your next task is to deliver something that is actually useful. I have a hard time making my mind up about what I want to order for lunch. And by the time the waiter takes my order, I've changed my mind at least once, and at the last moment. And that's just lunch. If I cannot decide what I want or need ten minutes in the future, why do we expect our customers to know everything they want or need a system to do? In truth, they are unsure of what they want today--that's why they came to us--let alone what they'll need 12-18 months down the road when the project is finally completed. If we're not afraid to admit we're wrong, we can do something to correct our mistakes or revise our project. Better yet, we'll admit that we neither can be nor need to be right all at once, so we scale down that 125-page document and allow for uncertainty and evolution. As the project progresses, the system will take shape and we adapt the requirements to their environment. Sooner or later, the importance of agility in software development is revealed to each of us. For me, it came on the wings of a fruit fly. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
