Ciara Byrne interviews Fred Brooks (The Mythical Man-Month) on why good programming projects go bad:
How did you first become interested in computers?
I grew up in a small farm market town in Eastern North Carolina — Greenville, North Carolina. I was reading, I think it was Time, in the public library and the cover had a drawing of the Harvard Mark I. I had been interested in manual methods of business data processing since I’d been about eight or nine (I started with a card file on my map collection), edge-notched cards, those kind of tools. So when I read about this I was fascinated, and I decided that’s what I wanted to do.
The Mythical Man-Month was based on your experience of managing the OS/360 project at IBM. How did you end up heading up that project?
I went to Harvard in Computer Science. (It was called Applied Mathematics in those days.) I did my dissertation under Howard Aiken, who had built the Harvard Mark I back in 1944. Then I joined IBM working on the Stretch supercomputer for four years. After being in charge of architecture for a new product line which did not fly, I was chosen to manage the System 360 computer family hardware. That was 1961. In 1964 it became evident that the hardware was on track and was being released into the factories on time. We were getting good cost estimates and all that, but the software was in big trouble. So my boss and I decided that I should go run the operating system project and see what I could do about bailing it out.
How big a project was the OS/360 for IBM?
I don’t know the total cost, but I’ve heard numbers anywhere from 300 to 500 million 1960s dollars. Those dollars would be today about 10 times more valuable, somewhere in the neighborhood of $3-5 billion. At the peak the project had a thousand people, but the average was much lower than that — we built up. There were laboratories all over the world — Britain, Germany, France, Sweden, California, and New York State.
You have said that “Everybody quotes it (The Mythical Man-Month), some people read it, and a few people go by it.” Why is that?
It’s all about disciplined decisions that are hard from a manager’s point of view. Just look at the software mess over the rollout of the health law. They made almost every mistake in the book. The book has more than 500,000 copies in print and is used in most software engineering curricula, so many people have learnt from those mistakes of the past. But it’s evident that if one picks people who are not software engineers to run major software engineering projects, you wouldn’t expect them to have studied the subject. Therefore they make the same mistakes again. The biggest mistake with the health law rollout was that there was no one in charge. That’s the biggest of all mistakes. That project seems to have had neither architect nor project manager. How bad can you get?
Why is it so important to have both a project manager and an architect on a software project?
I think it’s important even with a small team to distinguish the functions of the project manager from the function of the architect. When I was teaching software engineering, which I did 22 times here (The Department of Computer Science at the University of North Carolina, which Brooks founded), I always made even teams of four people choose a separate project manager from the architect, who was responsible for the technical content. The project manager is responsible for schedule, resources, and such. I notice the same division of function occurs in the film industry. A film has a producer who is in charge, but the person whose name is last on the credits is the director. The producer is responsible for making it happen, and the director works for the producer, but the director is responsible for the artistic content. I think that the same separation of function which evolved in that industry applies as well in ours.
The project manager first has to be tough, second place has to be flexible. A motto I consider important is “Never uncertain; always open.” I saw that in Latin (Numquam incertus; semper apertus) on the ceiling of a German fraternity in Heidelberg. It’s important to always have a direction and be going there. You can’t steer a ship that’s not underway. But it’s also important to be open to changes in circumstance and direction and not just to be completely bullheaded. A project manager also has to be a people person. Project management is a people function and most of the problems are people problems.
Almost 40 years after the publication of The Mythical Man-Month, why is it still so difficult to estimate how long it will take to make a large piece of software?
The problem is that we are working with ever-new technology on ever-new development. Product development always contains many uncertainties. In building a house we are working with known technologies and pretty well-known specifications. Building a whole new thing like building the first nuclear submarine or building the first space shuttle, you don’t know what you’re going to run into. Any piece of software is a whole new thing, unless you are just copying somebody else’s.
The last paragraph makes sense to me as a practitioner, at first glance, but when you think about it a lot of late projects now are paint-by-numbers CRUD DB applications that contain nothing new — and good hardware engineers get new projects done more or less on schedule regularly, as in the OS/360 project he mentions.
So I’m not sure it’s that simple. I think the aggregate psychological quirks of software guys may be a factor. Speaking of which, I should have been out of bed half an hour ago.