Computer Magazine, April 1987
by Frederick P. Brooks, Jr.
University of North Carolina at Chapel Hill
Full article available @ http://virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html
Last Updated: 17th March 2002 Sunday 15:49, Ankara
Notes that I took while reading this article:
"I believe the hard part of building software to be specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems."
"Let us consider the inherent properties of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility."
"The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. For three centuries, mathematics and physical sciences made great strides by cınstructing simplifed models of complex phenomena, deriving properties from the models, and verifying those properties by experiment. This paradigm worked because the complexities ignored in the models were not essential properties of the phenomena. It does not work when complexities are the essence."
"From the complexity comes the difficulty of enumerating, much less understanding, all the possible states of the program, and from that comes the unreliability...From complexity of structure comes the difficulty of extending programs to new functions without creating side effects."
"The reality of software is not inherently embedded in space. Hence, it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, and computers have connectivity schematics. As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, and name-space relationships. These graphs are usually not even planar, much less hierarchical."
"The hard thing about builidng software is deceiding what one wants to say, not saying it."
"The most powerful contribution by expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers. This is not a small contribution. The gap between the best software engineering practice and the average practice is very wide--perhaps wider than in any other engineering discipline."
"...the flowchart is a very poor abstraction of software structure...In the pitiful, multipage, connection-boxed form to which the flowchart has today been elaborated, it has proved to be useless as a design."
"The hardest single part of building software is deciding precisely what to build...No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
"...the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem up to the detail necessary for the specification...it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition."
"Prototypes typically perform the mainline tasks of the application, but make no attempt to handle exceptional tasks, respond correctly to invalid inputs, or abort cleanly."