Why Good Programming Projects Go Bad

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.

Comments

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.

Leave a Reply

Search

Search for:

Recent Comments

Don M.: Armor commanders in the 1970s reprimanded infantry commanders if they used reverse slope defenses: They thought with a moment’s thought they could convert from defender to attacker, and intended to dominate the enemy’s forward slope. Of course if you could attack, or had adequate fire to dominate the enemy’s forward slope, you wouldn’t be defending.

Toddy Cat: “Jones recommends six-year terms for the House and more autonomous agencies like the Fed.” Congratulations, Mr. Jones, you are a leading contender for the 2015 Mencius Moldbug award, for doing an outstanding job of identifying a real problem, and then coming up with an utterly inadequate or unworkable solution!

Victor: With an incumbency rate greater than 90%, I think House members already have six year terms, if not more.

Dan Kurt: Democracies self destruct. Fiddling with the machinery is just moving the deck chairs on the Titanic after it hit the berg.

Letters in a Box: The problem is that over time, the system becomes more and more gamed as it is more and more understood. There should be an injection of randomness somehow in order to make it somewhat unpredictable. There should be constitutionally mandated lotteries inserted into the system somewhere, somehow, at some random times. I’m not enough of a wonk to know where, or how, but I can picture maybe a random 6 year term for some office holders, or having jury members (that have not been...

Lu An Li: The moment I read this article I think of Calvin Perry III and his interrogation. Young man accused of a mass murder in Ft. Wayne IN. Calvin finally hung himself before being charged for the murders. Confessed freely and openly and it was all recorded on video and audio. Seen this video and heard the audio and it was remarkable how easily the man gave it all up. The experts on interrogations all agree that the interrogation was text book perfect and ought to be used as a training tool for...

Tim: Interesting, but what about the moral fortitude of the “accused.” Personally I wouldn’t admit to anything as an innocent person. Make a credible threat against my family and I would take the fall since protecting them has a higher value than protecting myself.

J.D. Saunders: Psych studies in all this were conducted 40–50 years ago, roughly during the period between Milgram’s seminal “Obedience to authority” study and the Stanford Prison Experiment. Cult indoctrination methods and standard interrogation methods were thoroughly researched. Little has changed in the interim.