Frederick P. Brooks, jr.
Of course the technological base on which one builds is always advancing. As soon as one freezes a design, it becomes obsolete in terms of its concepts. But implementation of real products demands phasing and quantizing. The obsolence of an implementation must be measured against other existing implementations, not against unrealized concepts. The challenge and the mission are to find real solutions to real problems on actual schedules with available resources. (Brooks 1995, 9)
…our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. (Brooks 1995, 14)
Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering. (Brooks 1995, 14)
All programmers are optimists. (Brooks 1995, 14)
The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging. (Brooks 1995, 17)
An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices - wait or eat it raw. Software customers have had the same choices. (Brooks 1995, 21)
Adding manpower to a late software project makes it later. (Brooks 1995, 25)
This then is the problem with the small, sharp team concept: it is too slow for really big systems. (Brooks 1995, 31)
Mills proposes that each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than hog-butchering team. That is, instead of each member cutting away the problem, one does the cutting and the others give him every suport that will enhance his effectiveness and productivity. (Brooks 1995, 32)
I will contend that conceptual integrity is the most important consideration in system design. (Brooks 1995, 42)
Because ease of use is the purpose, this ratio of function to conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design. (Brooks 1995, 43)
Simplicity is not enough. (Brooks 1995, 44)
The architect of a system, like the architect of a building, is the user’s agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user, as opposed to the interests of the salesman, the fabricator, etc. (Brooks 1995, 45)
…architect suggests, not dictates… (Brooks 1995, 54)
In the last analysis the customer is the independent auditor. In the merciless light of real use, ever flaw will show. (Brooks 1995, 69)
The purpose of organization is to reduce the amount of communication and coordination necessary… The means by which communication is obviated are division of labor and specialization of function. The tree-like structure of organizations reflect the diminishing need for detailed communication when division and specialization of labor are applied. (Brooks 1995, 78-79)
Organizations must be designed around the people available; not people fitted into pure-theory organizations. (Brooks 1995, 80)
…the man with strong management talent and strong technical talent is rarely found. (Brooks 1995, 80)
The linear extrapolation of such sprint figures is meaningless. (Brooks 1995, 88)
Progamming productivity may be increased as much as five times when a suitable high-level language is used. (Brooks 1995, 94)
Like any cost, size itself is not bad, but unnecessary size is. (Brooks 1995, 98)
This breakdown in orientation and communication is a major hazard for large projects. All during implementation, the system architects must maintain continual vigilance to ensure continued system integrity. (Brooks 1995, 100)
Representation is the essence of programming. (Brooks 1995, 103)
…writing the decisions down is essential. (Brooks 1995, 111)
The management question, therefore, is not whether to build a pilot system and throw is away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering the throwaway to customers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down. Hence plan to throw one away; you will, anyhow. (Brooks 1995, 116)
Nevertheless, some changes in objectives are inevitable, and it is better to be prepared for them than to assume that they won’t come. Not only are changes in objective inevitable, changes in development strategy and technique are also inevitable. The throw-one-away concept is itself just an acceptance of the fact that as one learns, he changes the design. (Brooks 1995, 117)
Quantization of change is an essential technique. Every product should have numbered versions… (Brooks 1995, 118)
Structuring an organization for change is much harder than designing a system for change. Each man must be assigned to jobs that broaden him, so that the whole force is technically flexible. On a large project the manager needs to keep two or three top programmers as a technical cavalry that can gallop to the rescue wherever the batter is thickest. (Brooks 1995, 118)
The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two step forward and one step back. (Brooks 1995, 122)
Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance as an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence. (Brooks 1995, 123)
System debugging has always been a graveyard-shift occupation, like astronomy. (Brooks 1995, 131)
Two notions are important here. The first is control, the idea of program copies belonging to managers who alone can authorize their change. The second is that of formal separation and progression from the playpen, to integration, to release. (Brooks 1995, 133)
The chief reasons for using a high-level language are productivity and debugging speed. (Brooks 1995, 135)
… the use of clean, debugged components saves much more time in system testing than that spent on scaffolding and thorough component test. (Brooks 1995, 148)
One must assume that there will be lots of bugs, and plan an orderly procedure for snaking them out. Note that one must have thorough test cases, testing the partial systems after seach new piece is added. (Brooks 1995, 150)
Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. (Brooks 1995, 154)
The boss must first distinguish between action information and status information. He must discipline himself not to act on problems his manages can solve, and never to act on problems when he is explicitly reviewing status. (Brooks 1995, 157)
Most documentation fails in giving too little overview. The trees are described, the bark and leaves are commented, but there is no map of the forrest. (Brooks 1995, 165)
A basic principle of data processing teaches the folly of trying to maintain independent files in synchronism. (Brooks 1995, 169)
Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. (Brooks 1995, 180)
I suggest:
- Exploiting the mass market to avoid constructing what can be bought.
- Using rapid prototyping as part of a planned iteration in establishing software requirements.
- Growing software organically, adding more and more functionality to systems as they are run, used, and tested.
- Identifying and developing the great conceptual designers of the rising generation.
… a scaling-up of a software entity is not merely a repetition of the same elements in larger size; it is necessarily an increase in the number of different elements. In most cases, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly. (Brooks 1995, 183)
The reality of software in not inherently embedded in space. Hence it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics. (Brooks 1995, 185)
Surely the most powerful stroke for software productivity, reliability, and simplicity hs been the progressive use of high-level languages for programming. Most observers credit that development with at least a factor of five in productivity, and with concomitant gains in reliability, simplicity, and comprehensibility. (Brooks 1995, 186)
The principal effect is to shorten system response time. (Brooks 1995, 187)
Many students of the art hold out more hope for object-oriented programming that for any of the other technical fads of the day. I am among them. (Brooks 1995, 189)
The essential prerequisite for building an expert system is to have an expert. (Brooks 1995, 193)
…software is very difficult to visualize. Whether we diagram control flow, variable scope nesting, variable cross-references, data flow, hierarchical data structures, or whatever, we feel only one dimension of the intricately interlocked software elephant. (Brooks 1995, 195)
I believe the single most powerful software productivity strategy for many organizations today is to equip the computer-naive intellectual workers on the firing line with personal computers and good generalized writing, drawing, file, and spreadsheet programs, and turn the loose. (Brooks 1995, 199)
The hardest part of building a software system is deciding precisely what to build. (Brooks 1995, 199)
For the truth is, the clients do not know what they want. (Brooks 1995, 199)
… it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying (Brooks 1995, 200)
One always has, at every stage in the process, a working system. (Brooks 1995, 201)
Growing software in higher-level chunks, built by someone else or reused from one’s own past, avoids facing whole layers of complexity. (Brooks 1995, 212)
I am, after all, a programmer by background, and optimism is an occupational disease of our craft. (Brooks 1995, 213)
The best way to attack the essence of building software is not to build it at all. Package software is only one of the ways of doing this. Program reuse is another. (Brooks 1995, 222)
One needs both a formal definition of a design, for precision, and a prose definition for comprehensibility. (Brooks 1995, 234)
Some valid changes in objectives (and in development strategies) are inevitable, and it is better to be prepared for them than to assume they will not come. (Brooks 1995, 241)
The tool that saves the most labor in a programming project is probably a text-editing system. (Brooks 1995, 244)
Any product that is sufficiently big or urgent to require the effort of many minds thus encounters a peculiar difficulty: the result must be conceptually coherent to the single mind of the user and at the same time designed by many minds. (Brooks 1995, 256)
The architect is like the director and the manager like the producer of a motion picture. (Brooks 1995, 256)
It is far better to be explicit and wrong than to be vague. (Brooks 1995, 259)
The basic fallacy of the waterfall model is that is assumes a project goes through the process once, that the architecture is excellent and easy to use, the implementation design is sound, and the realization is fixable as testing proceeds. (Brooks 1995, 266)
… experience and ideas from each downstream part of the construction process must leap upstream, somtimes more than one stage, and affect the upstream activity. (Brooks 1995, 266)
… a central question facing the software manager is how to design structure and process so as to enhance, rather than inhibit, creativity and initiative. (Brooks 1995, 277)
The start-up culture has the capability of rewarding star performers in proportion to their contributions; in the classical software industry the sociology of corporations and their salary-management plans have always made this difficult. (Brooks 1995, 284)
… software engineering, like chemical engineering, is concerned with the non-linear problems of scaling up into industrial-scale processes, and like industrial engineering, it is permanently confounded by the complexities of human behavior. (Brooks 1995, 288)
The tar pit of software engineering will continue to be sticky for a long time to come. (Brooks 1995, 288)
Too many interests, too many exciting opportunities for learning, research, and thought. What a marvelous predicament. Not only is the end not in sight, the pace is not slackening. We have many future joys. (Brooks 1995, 292)