Of all the monsters that fill the nightmares of our folklore, none terrifies more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magicaly lay them to rest.

The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet- something to make software costs drop as rapidly as computer hardware costs do.

-Frederick P. Brooks, Jr.

The silver bullet is a cultural change rather than a technological change. It is a paradigm shift-a software industrial revolution based on reusable and interchangeable parts that will alter the software universe as surely as the industrial revolution changed manufacturing.

-Brad J. Cox

Brooks develops the premise that software difficulty is divisible into two classes. The first class of difficulty is essential-"the difficulties inherent in the nature of the software." The second class is accidental-"those difficulties that .today attend its production but are not inherent." Brooks goes on to say, "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.... If this is true, building software will always be hard. There is inherently no silver bullet."

In reply to that paper, Brad Cox wrote "There is a Silver Bullet," in which he used the electronics industry as a metaphor to show how object-oriented methods can overcome the essential complexity of software systems through vast improvements in modularity and reusability. Cox's premise is that object-oriented technology gives us the equivalent of the interchangeable parts that sparked the industrial revolution. Objects allow the emphasis to move from a process-centered view (where the system's production is the focus) to a product-oriented view (where the application is the focus).

Cox envisions an industry founded on the production of standard interchangeable software parts for use by the system builders assembling the applications of the future. Cox uses the example of plumbing: "When building a house, would you consider buying a plumbing system built entirely from unique customized parts? Yet this is what the software community, with its infatuation with process and the pursuit of perfection from first principles, expects programmers to do whenever they build software."

These papers are important, well-written worlds that deserve to be read by anyone interested in insight into the problems facing us in the construction of large software systems. Since this column is devoted to the concept of building-block construction of systems, it should be no surprise that I share many of Cox's views, including his optimism about the potential of modular construction of software applications. It may be a surprise, however, that I also share many of the views expressed by Brooks and find little conflict in their ideas. It's the tone of the papers that conveys their inherent strife. Are we doomed to long development cycles for our products, or will objects be the silver bullet to put our nightmares to rest?

The production of any software system can be separated into a number of phases (the exact number and names of the phases are another subject for discussion). These phases should not be viewed as disjointed activities to be pursued in series, but rather as a number of concurrent activities with sequential commencement. My designation for the phases are: planning, analysis, design, prototyping, implementation, integration, maintenance, and evolution, as shown in Figure l

The figure shows a circle of tasks instead of the traditional hierarchical waterfall model to illustrate concurrency and interaction. I have placed planning at the 12 o'clock position since it is normally the first process to be activated. In like manner, the usual sequence of task activation proceeds clockwise with prototyping as a central activity. There are no arrows showing either progression or relation since all the tasks can be active at once with any activity producing feedback for any other activity (if I showed all the possible interconnections, 64 arrows, the figure would look like a spider's web). Let's examine the tasks effected by the object-oriented technologies discussed by Cox. ox uses the metaphor of the industrial revolution throughout his article to point out the improved productivity brought about by the use of interchangeable parts in manufacturing. During the industrial revolution, changes in worker productivity were unmistakable. A single worker could produce orders of magnitude more goods by assembling interchangeable parts than they could by making each part needed for each item produced.

The example of guns was used in the article. Surely, modern workers at Sturm-Ruger can produce many more guns in a day than smithies working out of their homes in colonial Massachusetts could. Using this example is a powerful indicator that we can expect a large return on investment for the use of interchangeable parts in the software we produce.

But wait! Is production really a relevant problem? Production of a consumer software application, comparable to the assembly of a gun from parts, involves printing manuals, copying disks, and shrink-wrapping the package. All these manufacturing activities use available interchangeable parts and are not part of what we traditionally consider software development. No software crisis is involved in the production of a consumer product. The software crisis is due to the development of new applications.

Using the example of gun manufacturers, the arms industry is continually developing new models to stay competitive. The development process first involves planning-to determine strategic issues that differentiate the manufacturer's product from other currently available products.

As an example, current interest in the field of handguns revolves around new safety mechanisms (such as decockers), new materials of construction (such as plastic and titanium), and new calibers (such as 10mm and .40 caliber). Once strategic planning is completed, the manufacturers analyze the market for user preferences such as capacity, sight types, barrel length, and weight. From this information, the manufacturers begin a design phase involving extensive engineering (it's embarrassing to field a weapon that doesn't work when needed or works when you don't intend it to).

Finally, they produce prototypes for testing. In all these pre-manufacturing endeavors, "standard interchangeable parts" are of little use. As an example, even though a 9mm and 10mm handgun may have the same dimensions and look, it is likely the internal parts of the 10mm weapon will be of a different construction with different heat treatment and tolerances.

Granted that the use of many off-the-shelf parts such as screws, bolts, and even larger parts like frames, can speed up the design process. However, a need for custom parts in the gun industry will always exist. Manufacturers can't blindly use a "barrel" class with inherited characteristics such as bore, twist, and length, since they still need to ensure it is engineered to meet the pressures of a new load or the perceived needs of the consumers. This custom, intellectual emphasis in the early phases of the

firearm's life is analogous to the essential activity that Brooks sees as the software lifecycle portion that will not be impacted by foreseeable occurrences in software engineering.

Interchangeable software parts in the form of class libraries, as envisioned by Cox, will speed up the processes of implementation, prototyping, maintenance, and, to a lesser extent, design. The other lifecycle phases will see less change due to the use of objects, even if significant advantages occur in the use of object-oriented analysis and design. Significant changes may mean an improvement by a factor of two, but that's not the software industrial revolution we need to solve the present crisis in software development.

As Brooks points out, the time taken to complete a task is composed of the sum of the time taken by the task's individual events. Some of the events are inherently sequential, while others may be concurrent. We can eliminate the presently replaceable events by using reusable software components, and we still have a significant amount of time occupied by activities unaffected by reusability. Have we shown that Brooks is right? Let's further explore the gun manufacturing example. What's the possibility that Texas Instruments is going to jump into the handgun market

with a popular new offering? Not very likely. Texas Instruments has no corporate infrastructure to facilitate the planning, analysis, and design of handguns. Even though it is well versed in the area of manufacturing, it would have a great deal of trouble producing a new model handgun. In like manner, Sturm-Ruger would have a difficult time planning, analyzing, and designing a new electronic calculator.

These corporations have developed standard methods for the high-level intellectual activities involved in the process of developing their unique products. In many ways, they have defined internal standards for these activities that serve as templates for future development efforts. The essential intellectual activities Brooks sees as the choke-points for improvement in productivity are already informally modularized and standardized within organizations. Presently, however, these intellectual activities are not automated.

Indeed, Roger Penrose [3] believes these thought processes will never be automated. Penrose presents interesting arguments leading to the conclusion that machine-based intelligence will never exist. He argues that intelligence is constrained to the domain of living organisms due to physical limitations on electronic systems. The question then becomes: Is intelligence necessary to develop these high-level decisions, or can the process be formalized in a template that greatly leverages the intelligence of the people involved in the decision-making process?

One of the central issues in computer-aided software engineering is the reuse of all levels of the development process. Already, we can build code for reuse in the implementation phase and, to a lesser extent, reuse some designs. The present struggle is to capture templates for reuse in strategic planning and analysis-the very areas in which Brooks despairs of ever achieving significant improvement. These are the same intellectual processes that Penrose claims that machines will never be able to accomplish.

I'm more optimistic about our ability to describe and codify these processes formally. I don't believe either Penrose's premise that thought is possible only in brains or the premise that independent thought is necessary to reuse the procedures involved in the capture of strategic planning and analysis. If progress can be made in the formal capture and automation * these decision processes, the use of reusable components at all levels stands to be our magic weapon for the utter destruction of the demons that haunt our deadlines.

Both Cox and Brooks can be right about the problems and solutions in the war on software horrors. An extension of the components envisioned by Cox to include high-level planning, analysis, and design will speed the processes seen by Brooks as the problem areas least likely to be solved by technological fixes. Penrose also may be correct without affecting the results-if the components needed to formalize the high-level events are procedural rather than heuristic. Someday, we may have our silver bullets to slay the slavering, blood-thirsty software beast; but for the present, we must still tremble on the nights when "the moon is full and bright." -

References

2. Cox, Brad J. "There is a Silver Bullet," Byte, Oct. 1990, pp. 209-21 8.

3. Penrose, Roger. The Emperor's New Mind. New York, N.Y.: Oxford University Press, 1989.

Tom Ochs is the author of the SolveIT numerical analysis package and has applied numerical methods to scientific disciplines ranging from solvent extraction to plasma physics. He is president of Structured Scientific Software in Albany, Ore. Ochs can be contacted on the CLMFORUM on CompuServe. His ID is 705 1 1, 652.

Virtual School	Middle of Nowhere	Brad Cox