from Fortune Magazine, QUOTED OFTEN, FOLLOWED RARELY, December 12, 2005

Thirty years after he published the “bible of software engineering,” Fred Brooks talks about managing teams of people and why projects so often go wrong.

By Daniel Roth

In 1975, Frederick Brooks published The Mythical Man-Month. It had no right to succeed. The book detailed Brooks’ experience managing IBM’s bet-the-company System/360 computers and OS/360 software, and featured odd illustrations, an awkward title, and loads of jargon. Yet Brooks’ deconstruction of what went right and wrong became a must-read among tech and nontech execs; dog-eared copies are still passed around. The best known passages expose flaws in the then common use of “man months”--the tool (okay, gender-biased tool) for estimating project cost and length. A 12-man-month project might have three people assigned to it for four months; if delays set in, managers simply added more people. Brooks proved that doing so increased bureaucracy and training, leading to Brooks’ law: Adding people to a late software project makes it later. He also laid out new strategies for organizing teams and managing creative types. In November, Brooks, now 74 and since 1964 a computer science professor at the University of North Carolina at Chapel Hill, explained in his Southern drawl why people still turn to his book for guidance.

Edited excerpts:

It’s been 30 years since you wrote your book. Is it still relevant?

People still buy copies to give to their boss. The book is really more about management than about technology. The technology has changed immensely, so some of the old chapters are totally out of sync. On the other hand, people haven’t changed much. That’s why Homer and Shakespeare and the Bible are still relevant, because they’re all dealing with human nature. I think that’s part of the explanation for this book: The problems of managing people in teams have not changed, though the medium in which people are designing and the tools they are using have. 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.

It’s also been influential outside software. Tell me about that.

Surprisingly enough, a partner in a big law firm said, “Oh, this describes our practice.” I’ve had physicians say the same. It’s really about people and people in teams: the communication problems, the scheduling problems, the estimating problems.

Does Brooks’ law apply in those industries?

Brooks’ law depends heavily on the amount of information that has to be communicated. So the argument is that if you add people to a project that you already know is late, which means you’re at least in the middle of the project, you have to repartition the work. That’s a job in itself: Just deciding who is going to do what means that instead of having the thing divided into the units you had it divided into, you have to divide it into more units. Sometimes that can be done by subdividing the existing units, but sometimes you have to move boundaries. That’s a lot of work. The next thing is, you have to train the new people. Who can train them? Only the old people. So they quit working and go to training. And the new people are green and have to get up to speed. So there’s a period where they’re unproductive, and there’s a period when they are less productive. And there’s a period when they inject errors into the process. Then there are just more people to communicate to.

So if a project is already late and throwing more people on it is just going to make it worse, how do you solve the problem? One is to officially slip the schedule. And officially doing it has many benefits over unofficially letting it slip. Peter Fagg, a really wise System/360 engineering manager, gave very sound advice: “Take no small slips.” That is, if you’re going to take a slip, get everybody onboard, get organized, and take a six-month slip, even though you may at the moment feel as if you’re only four months late. The other obvious solution is to lighten the ship: Decide there are some things we’re not going to do. A third thing is to phase the work: Say, “All right, we’re going to do a version that has just the essentials for the most important or most numerous users.” Meanwhile schedule and develop the things that should go in version 2 and ship them later.

Sounds like a recipe for Microsoft’s Vista, its long-delayed and now pared-down new operating system. Does it surprise you that the same mistakes are being made 30 years later?

No. People still build bridges that fall in. That art has two centuries of engineering practice behind it, if not three. The software engineering discipline is just plain younger than the electrical engineering discipline. So software is less mature than hardware, and by a whole generation of people. Also, the median age of the practitioners is probably younger.

What advice would you give to one of those young managers?

The best single advice is a motto I read on the ceiling of a German drinking fraternity in Heidelberg--this cave had been there, I guess, since the 16th century. It said, Numquam incertus; semper apertus: “Never uncertain, always open.” Sometimes the first part is put as saying, “You can’t steer a ship that’s not underway.” At any given time, you ought to have pretty clear goals, and know where you’re going, and be going there. On the other hand, you always should be open to saying, “Is that what we really ought to be doing? Here’s another idea.” But sitting still in the water waiting to decide which way to go is the wrong thing to do.

The other was when I was a new IBM employee and heard Vin Learson, a VP at the time, later CEO. He said, “The problem is not to make the right decision; it’s to make the decision right.” I thought that was the most anti-intellectual thing I had about ever heard. I was fresh out of graduate school, and of course to me, the problem is to make the right decision. I came to understand that he was talking from an executive-level point of view. As decisions bubble up they are first 80/20 decisions, then 70/30, then 60/40, and then they are 49/51 decisions. At that level the arguments on each side are pretty strong; going either way can be made to work, but it’s very important to pick one and then go whole hog. A counter-example is IBM’s PL/I language. They adopted it, they backed it, and then there was a spell when they decided maybe it wasn’t going to be the language. And then they decided maybe it was going to be. As a consequence, most customers didn’t stick with it. The wishy-washiness killed it, I think. That’s the numquam incertus: Whatever you’re doing, you’d better go do it.

Does the rise of open-source projects like Linux challenge some of your more formal organizing principles?

The advantage of [open source] is early, large-scale testing, with lots of people motivated to find the bugs, and a culture in which people communicate fixes to each other. A second big advantage is that multiple versions of any particular component gets built, and the marketplace votes on them. In many cases one wins out. In many cases, one doesn’t, and different versions circulate. That’s confusing, and you get compatibility issues. This model clearly works best when the builders are the clients.

So the question I ask is, Would you want to build an air-traffic-control system that way? The answer is no. That task requires a tighter degree of integration. Whereas when the community is building tools for itself, it’s advantageous to have different people, with different ideas of what they want to build, build it, and then let the market vote. Also, as an economic model, the hard problem is how to compensate people. The reward here is prestige. There’s no mechanism for ensuring that the creative get fed.