Peter Marklund's Home

Fred Brooks is a Computer Science professor who managed 5000 man-year IT projects at IBM in the sixties. His words carry a lot of weight and he certainly has something profound to say about software engineering. The central theme of the book is that of conceptual integrity. It's about the need to have a single architect, a master mind, who oversees all development and makes sure all the parts fit together. "A clean, elegant programming product must present to each of its users a coherent mental model of the application". The ideal scenario for conceptual integrity naturally is having a single programmer. The problem is that some systems are so big that in order to finish them before they are obsolete you need a large number of developers. Much of the book is spent discussing this difficult problem. How do you organize huge developer teams?

Something I found myself wondering as I was reading the book is how large scale open source projects are able to organize themselves and how they differ from commercial projects. The Wikipedia article on Brooks law (i.e. adding people to a late project makes it later) suggests that open source projects scale through "Efficient parallelization of work, reducing the communication overhead" and through having a large number of testers.

One of the ideas in the book that resonated the most with me is that of the incremental build model. You start out by building an end-to-end skeleton system, i.e. system with a small subset of the complete functionality. This sounds very much like the Tracer Bullet approach advocated by the Pragmatic Programmers. The benefit is early user feedback and exploration of the users needs.

According to Brooks, "...the quality of the people on a project, and their organization and management, are much more important factors in success than are the tools they use or the technical approaches they take.". Brooks refers to the Peopleware book when making this point, i.e. it's about the physical and social work environment, about aligning and motivating developers etc. However, it also ties in with the idea of conceptual integrity, i.e. you need to solve the communications problem and make sure that the left hand knows what the right hand is doing.

Brooks offers a great analysis on the problems of software maintenance and fixing bugs:

"The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back.

Why aren't defects fixed more cleanly? First, even a subtle defect shows itself as a local failure of some kind. In fact it often has system-wide ramifications, usually nonobvious. Any attempt to fix it with minimum effort will repair the local and obvious, but unless the structure is pure or the documentation very fine, the far-reaching effects of the repair will be overlooked. Second the repairer is usually not the man who wrote the code, and often he is a junior programmer or trainee."

Brooks ends his essay with these dark words:

"System program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence."

The most famous essay in the book is No Silver Bullet — Essence and Accidents of Software Engineering. According to Brooks, programming at its essence will always be a complex, time consuming, and error prone thought process, and therefore, despite advances in technology, we will never see the kind of explosive productivity growth in software that we have seen in hardware.

This is just a small teaser of what the book has to offer. If you are at all interested in the methodology and management of software development I highly recommend checking it out.