Just as in politics, conventional wisdom influences the expectations and plans of the people who set data processing policy and direct software system purchases and development efforts. Conventional wisdom has it that revolutions are in process wherein certain techniques and tools will radically affect the software development process, the way we do business, and the associated costs. People who have never sat at a keyboard or picked up a coding sheet run on about the slope of the hardware cost curve vs. that for software. A silver bullet is implied that will make software development costs plummet as hardware costs already have.
Frederick P. Brooks, Jr., who, in The mythical man-month , warned of the perils of adding staff to recover schedule time on troubled software projects, has again addressed conventional wisdom. In this nine-page essay, Brooks discusses “technical developments that are most often advanced as potential silver bullets.” Those mentioned are the following:
Brooks does not dismiss the selected technologies as worthless. He does question the realism of the expectations being generated. He believes their benefits are being oversold.
Ada and other high-level languages
Software development environments and tools
Brooks makes several insightful observations about the software system development process, the environment in which the process takes place, and the differences between software development and hardware development. He says of the prospects for software development to match the sixfold increase in the performance/price ratio that has occurred in the hardware industry over 30 years, “there is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.”
Brooks admits that past breakthroughs in software technology development, including high-level languages, time-sharing, and unified programming environments, have been responsible for multiple order-of-magnitude improvements in productivity, but these addressed the class of difficulty that Brooks terms accidental. Brooks believes “the hard part of building software to be the specification, design, and testing of this conceptual construct [the ‘essence’], not the labor of representing it and testing the fidelity of the representation” [where ‘accidental’ difficulties are encountered and removed].
New technologies and techniques that address the accidental difficulties can probably deliver only incremental productivity gains. Brooks sees no candidates in the list of potential silver bullets that truly address the essential difficulties. But are there any promising attacks on the conceptual essence? He suggests four surprisingly down-to-earth attacks on the essence:
Brooks’s paper is an excellent and important one. In it he challenges popular expectations arising from uncritical analysis and hype. Every corporate executive and MIS/DP policy maker should read it before purchasing software methodologies and tools and before setting career paths for software development staff.
Buy vs. build--Not constructing software at all but instead using one of n copies of software “effectively multiplies the productivity of its developers by n.”
Requirements refinement and rapid prototyping--The assumption that “one can specify a satisfactory system in advance, get bids for its construction, have it built and install it ... is fundamentally wrong ... many software acquisition problems ... cannot be fixed without revision--revision that provides for iterative development and specification of prototypes and products.”
Incremental development--Brooks recommends the top-down “growing” of software. First make the system run with little or no functionality, then let “each added function or new provision for more complex data or circumstances [grow] organically out of what is already there.”
Great designers--“Great designs come from great designers. Software construction is a creative process.” Brooks proposes that software organizations must recognize and try to cultivate great designers as leaders who are as important as great managers. He includes a short list of ways to grow great designers.