Joe's Jottings
Jottings Number 36, by Joe Podolsky:
From: uunet!HP-PaloAlto-om4.om.hp.com!JOE_PODOLSKY
Date: Mon, 24 Jul 95 16:44:21 -0700
Subject: Heroes Versus Process
Mel Kelm is retiring at the end of this fiscal year after over 30 years with HP. Mel, as many of you know, is the editor of the Information Systems Newsletter, and, more important, is the archetype of a gentleman and a scholar. I have the privilege of writing an article about him in the last issue of the Newsletter that he will edit, and I took the opportunity to have a long, reflective chat with him. I'm sorry we didn't videotape it so that everyone could benefit from his insights. He made one comment, however, that reinforced a couple of articles I've read recently. Mel was observing that, while there had been incredible changes in hardware and software capabilities, one area of information systems was as much of a problem now as it was in 1965, in spite of many valiant efforts to solve it. That problem is the process of managing project life cycle. Now, as then, we still have significant problems with schedule and cost overruns, while underdelivering features and performance. We've tried everything from a traditional "Systems Life Cycle" to more modern spiral and incremental processes. Now some people are looking to reuse and objects for salvation. It's like the search for the Holy Grail or for Brooks' mythical silver bullet. It's hard for me to admit this, but maybe we've been looking for this stability and predictability in the wrong place. Maybe we've been blinded by the dazzle of wishful thinking instead of dealing with the, admittedly disconcerting, historical record. Maybe (gulp!) we should look for heroes and stars, not for processes. Maybe software is more like movies and literature than like manufacturing or service businesses. Maybe we should motivate great software with Oscars and Emmies, rather than with data and metrics. The fact that significant process initiatives such as the Software Engineering Institute's Capability Maturity Model and Japan's focused effort on software development are not creating significant breakthroughs adds weight to the craft side of the craft versus process debate. Then I read two articles in the IEEE Software journal. One, in the March 1995 issue is entitled, "Enough About Process: What We Need Are Heroes." It's by James Bach of Software Testing Laboratories, and he bluntly says that the secret to great software is "the care and feeding of the minds that actually write the software. Process is useful, but it is not central to successful software projects." Bach has his own, somewhat self-serving, definition of heroes. He says that "heroism means going beyond the borders of the known world and returning with new knowledge or wealth." I'd probably call that "exploring" rather than heroics. Bach says that "a hero (is) someone who takes initiative to solve ambiguous problems." And most software is ambiguous. He says that heroism has a bad name in software because we focus on the extreme cases, what Bach calls "pathological heroism." He thinks that the pure "process-control" approach is equally problematic. In the May 1995 issue of IEEE Software, David Sims writes about the Software World USA conference held in Chicago last February (the next one, by the way, will be in San Jose in October). James Bach was one of the speakers, but Sims mentions other "experts" who also take the people over process view. For example, Jim McCarthy of Microsoft defines "writing software as the act of encapsulating a development team's intellectual property into bits on a disk." Robert Osborne, of the Process Renewal Group, says that "Our number one problem is not technology - it's people." Chair of the conference, Edward Yourdon raised political considerations: - Is (a proposed) new technology part of a hidden agenda that is more about status or someone's resume' than about process? - How naive or savvy is the decisionmaker? Bach is quoted as saying at this conference, "All processes can do is to lead the horse to water. When it comes to drinking, you're on your own." In the March article, Bach lists several items that should be in a "Hero's Helpers Toolkit." Here are a few: - Diagnose and rectify ... inconsistency between thoughts, words, and deeds. - Continuously analyze, assign, and clarify project roles. - Collaborate with heroes, rather than dominating them or ignoring them. - Before asking, "what is the process? ask "who is the process?" What is your experience with process versus heroes? Are they mutually exclusive? If we must depend on heroes, what processes do we need to support them? If we depend on heroes, what must we do to prepare for the inevitable day when they leave the project? How can we identify heroes? How should we motivate and reward them? What happens to "ex-heroes" who may have lost their technical or personal edge? Best regards, Joe