Fred Brooks

Frederick Phillips Brooks, Jr. (April 19, 1931 – November 17, 2022) was a computer architect, software engineer, and computer scientist, most famous for managing the development of IBM's System/360 Computer family hardware and then OS/360, then later writing candidly about the process in his seminal book The Mythical Man-Month. Brooks received a Turing Award in 1999 and many other awards.

"Adding manpower to a late software project makes it later."

Quotes

• The term architecture is used here to describe the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation. i. Additional details concerning the architecture,
  • Gene Amdahl, Gerrit Blaauw, and Fred Brooks (1964) "Architecture of the IBM System." in: IBM Journal of Research and Development Vol 8 (2) p. 87-101.

• The programmer's primary weapon in the never-ending battle against slow system is to change the intramodular structure. Our first response should be to reorganize the modules' data structures.
  • Brooks (1975, Chapter 9) as quoted in Code Complete: A Practical Handbook of Software Construction, by Steve C. McConnell

• …well over half of the time you spend working on a project (on the order of 70 percent) is spent thinking, and no tool, no matter how advanced, can think for you. Consequently, even if a tool did everything except the thinking for you – if it wrote 100 percent of the code, wrote 100 percent of the documentation, did 100 percent of the testing, burned the CD-ROMs, put them in boxes, and mailed them to your customers – the best you could hope for would be a 30 percent improvement in productivity. In order to do better than that, you have to change the way you think.
  • As quoted [paraphrased] from Toolbox, Java World, July 1999 

• Some people have called the book the "bible of software engineering". I would agree with that in one respect: that is, everybody quotes it, some people read it, and a few people go by it.
  • As quoted in Quoted Often, Followed Rarely, [1]; About the 1975 The Mythical Man-Month.

• Job Control Language is the worst programming language ever designed anywhere by anybody for any purpose.
  • "The IBM System/360 Revolution", recorded by the Computer History Museum, 7 April 2004 .

The Mythical Man-Month: Essays on Software Engineering (1975, 1995)

Originally published in 1975; page numbers refer to the substantially expanded Anniversary Edition (2nd Edition), 1995, Addison-Wesley, ISBN 0-201-83595-9

• The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures....
  Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. […] The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
  • Page 7.

• The bearing of a child takes nine months, no matter how many women are assigned.
  • Page 17, cf. Theodore von Kármán (1957): "Everyone knows it takes a woman nine months to have a baby. But you Americans think if you get nine women pregnant, you can have a baby in a month."

• Brooks's Law: Adding manpower to a late software project makes it later.
  • Page 25 (italics in source, bold added).

• The "Second System Effect":
  An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint.
  As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time.” Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.
  This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.
  The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a "big pile."
  • Page 55.

• An ancient adage warns, "Never go to sea with two chronometers; take one or three."
  • Page 64.

• Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.
  • Pp. 102–3.

• The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.
  • Page 116 (italics in source).

• How does a project get to be a year late? … One day at a time.
  • Page 153 (italics and ellipsis in source).

• …the organization chart will initially reflect the first system design, which is almost surely not the right one […] as one learns, he changes the design […]. Management structures also need to be changed as the system changes…

No Silver Bullet (1986)

Page numbers refer to Chapter 16 of The Mythical Man-Month, Anniversary Edition, cited above.
Originally published in Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, H. K. Kugler, ed., Elsevier Science, 1986, pp. 1069–1076. Also reprinted in the IEEE magazine Computer, 20, 4 (April, 1987), pp. 43–57.

• The essence of a software entity is a construct of interlocking concepts: […] 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.
  • Page 182 (italics in source).

• The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence.
  • Page 183.

• Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. Much of the complexity he must master is arbitrary complexity […] because they were designed by different people, rather than by God.
  • Page 184.

• Even perfect program verification can only establish that a program meets its specification. […] Much of the essence of building a program is in fact the debugging of the specification.
  • Page 195.

• Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude.
  • Page 202.

• A little retrospection shows that although many fine, useful software systems have been designed by committees and built as part of multipart projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers.
  • Page 202.