Frederick P. Brooks
Addison-Wesley, 1975.
Frederick P. Brooks
Addison-Wesley, 1975.
ISBN 0201835959 (20th anniversary edition!)
ISBN 0201006502 (original edition)
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
There really are awfully few books written a generation ago that can claim to be relevant to system development today (Checkland's Soft Systems Methodology among them), but this classic by Fred Brooks is still alive and kicking. I suppose there are millions of engineers around the world who would know instantly which book was being referred to if someone mentioned a tar-pit or a surgical team, and who still shudder at the thought of making a $200M mistake. In case you don't, here is an introductory snippet.
"No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits… The fiercer the struggle, the more entangling the tar, and no beast is so strong or so skillful but that he ultimately sinks.Large-system programming has over the past decade been such a tar pit… Most have emerged with running systems-few have met goals, schedules, and budgets."
Another thing that is very scarce in the published literature is an honest account of a project that went wrong. Its product, IBM's OS/360 operating system, did work - eventually - so it cannot be rated a failure, but the project's budget and schedule were spectacularly exceeded.
Brooks' theme is large and simple: developing complex systems is not like developing small ones. The problems of co-ordination, of decision-making, of controlling interfaces, of keeping the overheads of meetings and training and paperwork under control, drive the way that projects must be organized.
The man-month naturally gets a chapter to itself (Chapter 2). It begins:
"More software projects have gone awry for lack of calendar time than for all other causes combined."
Brooks continues:
"All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings…"
and he proceeds to document the false assumptions we make about schedules.
"In many creative activities the medium of execution is intractable. Lumber splits; paints smear; electrical circuits ring… Computer programming, however, creates with an exceedingly tractable medium. The programmer builds from pure thought-stuff… Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified."
Few writers on computing, let alone on management, can achieve such economy of expression. But the chapter brings more wonderful moments. A graph shows time versus number of workers for a perfectly partitionable task: the months fall away in a smooth asymptotic curve as the men increase. But:
"When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule (see figure). The bearing of a child takes nine months, no matter how many women are assigned."
It's rather like what the plain man said on reading Shakespeare: the book is full of quotations, so influential has Brooks been. The chapter continues ruthlessly to demolish the man-month myth. What happens if your project is late and you hire more staff to catch up? You have to repartition the work and train the new people. This slows everybody down.
"Oversimplifying outrageously, we state Brooks's Law: Adding manpower to a late software project makes it later."
Other chapters look at organizing large projects, planning, documenting, tools, and realism. But perhaps requirements people will be most interested in the chapter 'The Whole and the Parts' which considers how to 'design the bugs out'. It may come as a shock that back in the 1970's people were already saying that you should bug-proof your system's definition, assumptions and architecture, and:
"Long before any code exists, the specification must be handed to an outside testing group to be scrutinized for completeness and clarity."
In other words, validation & verification should begin with the requirements. Sometimes saying that still feels like crying in the wilderness today.
Brooks writes engagingly on these themes, and so beautifully described are his examples, and so honestly admitted are his own and his team's failings, that despite the passing of the years, much of what he has to say still sounds fresh today. We may not agree with his suggestions for documenting code, but we can't disagree with his experience and humour.
The book is wonderfully illustrated with photographs and paintings on the themes of each chapter. The Tacoma Narrows bridge collapses painfully into the water below; Giant Sloths get caught in the tar-pit; Babe Ruth calls his baseball shot. But the image I will leave with you is the delicious menu of the Restaurant Antoine (Fondé en 1840). The caption says simply:
Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.
Amen to that.
© Ian Alexander 2001
You may also like:
