Fred Brooks Quotes

Adding manpower to a late software project makes it later

Nine people can't make a baby in a month.

The hardest single part of building a software system is deciding precisely what to build.

The hardest single part of building a software system is deciding precisely what to build the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they have almost never thought of the problem in the detail that must be specified.

You can learn more from failure than success. In failure you're forced to find out what part did not work. But in success you can believe everything you did was great, when in fact some parts may not have worked at all. Failure forces you to face reality.

A scientist builds in order to learn; an engineer learns in order to build.

How does a project get to be a year behind schedule? One day at a time.

Present to inform, not to impress. If you inform, you will impress.

The bearing of a child takes nine months, no matter how many women are assigned.

The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.

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.

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

Software work is the most complex that humanity has ever undertaken.

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.

Even the best planning is not so omniscient as to get it right the first time.

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.

Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. 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.

System debugging, like astronomy, has always been done chiefly at night.

Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.

I am more convinced than ever. Conceptual integrity is central to product quality.

Design work doesn't just satisfy requirements, it elicits them.

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 steps forward and one step back.

Dissertations are not finished; they are abandoned.

I have never seen an experienced programmer who routinely made detailed flow charts before beginning to write programs.

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.