>
Choosing Chaos
By Jeff Gainer
(Author's note: This essay originally appeared in the 25 July 2001 issue of the Cutter IT Journal E-Mail Advisor.)
"But, Monsieur Jeff," Francois implored. "Surely French wine will not present a problem for you."
I had already explained to Francois that red wine, in any amount, irritated my arthritis. "It is the American and Australian wine," Francois insisted. A true Frenchman, Francois was horrified that I would actually have dinner without wine. So he insisted. I relented. I had half a glass of red wine. French wine.
The following morning, I woke with a stiff, painful back, as I had expected. As I had learned from experience.
Insanity, so they say, is doing the same thing over and over again, each time expecting a different result. Why do some Hollywood film stars marry and divorce repeatedly? Moreover, why do some software development organizations repeat the same disastrous - but obvious - mistakes over and over?
Case in point: I have witnessed development schedules mapped out with obviously disastrous possibilities. I recall being in a meeting with all the various stakeholders reviewing a development schedule. The schedule was announced thusly: "Okay, so we'll have four months to develop everything and two months to test it."
I had already been briefed on the project's past problems. "Great," I responded, "Provided that my team doesn't find any bugs." There were murmurs of enlightenment and alarm through the room. "Doesn't anyone remember that in the last two builds we had five or six test and regression test cycles because there were so many bugs?"
There were about thirty people in the room, but apparently no one remembered. I pressed on: "And doesn't anybody remember that each time, the development team delivered behind schedule, cutting into the testing schedule?" A few people seemed to remember this.
Now, I don't expect an immature organization like this to learn from experience to the level of, say, preventing defects. But they even didn't seem capable of learning even the simplest of lessons. And this organization's state is not unique. I have seen this situation many times before, and doubtlessly will continue to see it. How development organizations get in this situation has been extensively studied and debated; how they get out of it had been studied and debated even more. But why they stay in this situation, and even resist change, I simply couldn't understand. Only after observing several situations like this was I able to reach any conclusions:
Chaos is exciting. A highly charged environment is exciting, stimulating; it can bring out the best in creative people. Although this misuse of chaos results in wasted effort and rework, the organization was reluctant to change what were successful work practices (albeit inefficient ones). Unfortunately, if the pain of wasted effort, rework, poor quality, and schedule slip are not painful enough, the organization sees only their success and recognizes no need for change. If a development shop is chaotic, it is chaotic by choice.
For me, this explains why some immature software shops continue their chaotic ways and even resist efforts to change - but I'm still not sure why Mickey Rooney has been married nine times.
"Men occasionally stumble on the truth," Winston Churchill reportedly said, "But most of them pick themselves up and hurry off as if nothing had happened."
--Jeff Gainer
______________
(c)2001 Cutter Information Corp. All rights reserved. This article has been reprinted with the permission of the publisher, Cutter Information Corp., a provider of information resources for IT professionals worldwide.
This article originally appeared in the Cutter IT E-Mail Advisor, a supplement to Cutter IT Journal. www.cutter.com/itjournal