Better Software - November 2008 - (Page 13) Technically Speaking Follow the Process by Lee Copeland Politicians often wrap themselves in their countries’ flags, instantly attacking the patriotism of anyone who disagrees with them rather than dealing with difficult issues in a substantive way. We have our own “flags” in the software development world. Years ago, when I worked in a large mainframe data center, the collective wisdom was “You’ll never get fired for buying IBM.” No matter what disasters occurred, no matter how inept your technical skills, no matter how poor your management decisions, you were safe—because you bought from the right vendor. Later, when I led a software development group, we had another “flag”— our software development methodology. While my copy has turned to dust after thirty years, you can find an equivalent methodology, the US Housing and Urban Development’s (HUD) 354-page tome, at www.hud.gov/offices/cio/sdm/devlife/ sdm6_05.pdf. As is common in these methodologies, it is full of exhortations but contains little actual “how to” guidance. For example, in the chapter titled Design System, the HUD methodology commands, “the functional and data requirements … are further refined to lowlevel specifications,” “specifications are then organized in a way suitable for implementation,” and “the project development team uses the functional and data requirements … for partitioning the system into subsystems.” All good ideas, but there is no guidance whatsoever on how to actually accomplish these complex tasks. (I’ve always been amazed that people write this stuff down in such detail. Which part are they going to forget if it’s not in the methodology—requirements, design, coding, installation?) With thousands of others, we stood together and sang the process song: “Follow the process, follow the process, follow the process, don’t go astray. Follow the process, follow the process, follow the process, it knows the way.” And, no matter what disasters occurred, no matter how inept your technical skills, no matter how poor your management decisions, you were safe—because you followed the process. Then came the mother of all software development methodologies—the Capability Maturity Model at 450 pages, only to be followed by the über-mother, the Capability Maturity Model Integrated at 700 pages. And, with thousands of others, we stood together and sang the process song: “Follow the process, follow the process, follow the process, don’t go astray. Follow the process, follow the process, follow the process, it knows the way.” And again, no matter what disasters occurred, no matter how inept your technical skills, no matter how poor your management decisions, you were safe—because you followed the process. Now, a new set of methodologies has emerged under the umbrella called “agile.” Born of a rejection of the heavyweight methodologies, we have Extreme Programming, Scrum, Crystal Clear, DSDM, adaptive software development, feature-driven development, behaviordriven development, the Agile Unified Process, and a host of others. While very different from the heavyweight methodologies, these agile practices are also methodologies—“a set of practices, procedures, and rules used by those who work in a discipline or engage in an activity.” And, as such, these methodologies give little “how to” guidance. For example, in Extreme Programming Explained, Kent Beck states, regarding testers, “You are responsible for helping the customer choose and write functional tests”—a great idea, but that statement www.StickyMinds.com A methodology is a roadmap, and roadmaps can be misleading. doesn’t tell us how to actually choose and write these tests. And, with thousands of others, today we stand together and sing the process song: “Follow the process, follow the process, follow the process, don’t go astray. Follow the process, follow the process, follow the process, it knows the way.” And again, no matter what disasters occur, no matter how inept your technical skills, no matter how poor your management decisions, you will be safe—because you followed the process. I have no quarrel with any of these methodologies. I’m sure in an appropriate context, each is excellent for guiding the creation of better software. It’s all the dang singing that I can’t stand. A methodology is a roadmap, and roadmaps can be misleading. First, the methodology may be flawed in that it is simply wrong about some things and omits others. Second, none of these methodologies tells us how to do the tasks—how to elicit requirements, design, code, and test (the really difficult and interesting stuff). Third, all of these methodologies teach us to resist change. The methodology is the only true path— there is no other. “Follow the process” leaves no room for “tap into your wisdom” or “listen to your intuition” or “use your experience.” It also omits the idea of “take personal responsibility” for success, substituting blind process obedience. Your head, heart, and hands are the keys to your success in building better software—not the methodology. {end} NOVEMBER 2008 BETTER SOFTWARE 13 http://www.hud.gov/offices/cio/sdm/devlife/sdm6_05.pdf http://www.hud.gov/offices/cio/sdm/devlife/sdm6_05.pdf http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.