The Mythical Man-Month by Frederick P. Brooks Jr. captured the hopeful nature of ambitious computer programmers and documented the many ways their efforts can crash and burn. Published in 1974, nine years after the completion of the IBM 360 project, it's still required reading in many university computer science courses. It's on the posted recommended reading list, for example, of open-source programming guru Eric Raymond, author of The Cathedral And The Bazaar.

Brooks, 73, directed IBM's $5 billion hardware and software project to create the first general-purpose computer, the System/360, progenitor to all IBM mainframes. The 360 was launched in 1964. Last week, at the 40th anniversary celebration of that event at the Computer History Museum in Mountain View, Calif., Brooks told InformationWeek how he came to lead the project and whether he believes programmers have learned anything since then.

His wife, Nancy Brooks, said he spent nine years after the project describing the lessons learned in The Mythical Man-Month. "He worked on it everywhere we went. He worked on it at the beach."

The result was a highly readable and summarized expression of the experience. In Chapter 2, he cites how expressions of optimism, hope, and outright falsehoods creep into estimates of progress in a major, complex software project. In one section, "Gutless Estimating," Brooks writes: "An omelet, 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. The cook has another choice; he can turn up the heat. The result is often an omelet nothing can save--burned in one part, raw in another."

"Before Frederick Brooks, we addressed developers as if it was a single guy in an attic. He taught us how to do software development as a team," says Donald Knuth, retired Stanford University professor and author of the 1968 book The Art Of Computer Programming.

InformationWeek: How did you come to lead the IBM 360 project?

Brooks: Ask [IBM Data Systems Division VP] Bob Evans [no relation to InformationWeek editorial director Bob Evans]. He and I had been fighting for six months before the executive committee over which way the company should be going. First I won, then he won. I was advocating the immediate development of a product family of [different] small machines. Evans was arguing for all new technology, a product line that was comprehensive across all divisions of the company. He was right. I was wrong. He won and he should have won.

InformationWeek: If you two were antagonists, how did you get leadership of his project?

Brooks: I don't know. I was stunned.

InformationWeek: Did you ever take on a similar project with as many demands?

Brooks: It was a once-in-a-lifetime experience. I left IBM after the project and moved to Chapel Hill to start the computer science department there. [Brooks founded the department at the University of North Carolina, one of the first such departments in the nation. He was its chair for 20 years. Nancy Brooks is a native of Chapel Hill, and Brooks was born in nearby Durham.]

InformationWeek: Have we learned anything about software development in 40 years?

Brooks: We've learned that the waterfall model of development [in which software development flows from start to finish along the predicted path, falling into place at the end of the project] needs to be abandoned, and it hasn't been yet.

We need to adopt the spiral model [in which one defines and writes the highest-priority features of a project first, then goes back to users to get assessments and feedback; it's intended to lower the risk of a project turning out unsatisfactorily].

We've moved to high-level languages, above assembly languages. One of the first was Fortran. Object-oriented programming was the same thing, moving to a higher conceptual structure.

I'm also encouraged by aspect programming. [That's where one aspect of an app, say a security module, is developed once and made available for other apps. That's not the way it's done in most cases today. Security gets embedded into each application. It's different in each place and it's tied to the application code, making it hard to change security.]