Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Timeless Classics of Software Engineering

Re: Timeless Classics of Software Engineering

From: Eric Hamilton <>
Date: Fri, 27 Aug 2004 19:45:40 GMT
Message-ID: <EbMXc.8961$>

Thanks for a stimulating topic.

I heartily agree that Mythical Man Month is essential reading for anyone who wants to understand large scale software projects.

The other essential on my book case is Lakos' "Large Scale C++ Software Design". It's applicable to any language and has enough rationale that's grounded in real development practices and the problems of large scale projects that I think it's relevant to the original topic.

A few years ago, I happened to reread Brooks and wrote up a collection his insights that resonated with me. I've attached it below in hopes of whetting the appetite of anyone who hasn't already read it and as a reminder for those who haven't reread it recently. I encourage everyone to (re)read the full book.


Notes from re-reading "The Mythical Man-Month" by Fredrick P. Brooks, Jr.

I went looking for a quotation about the value of "system design" and ended up reading most of the book because it has many insights into the challenges of producing large-scale software projects.

Some highlights:

In the preface Brooks says that while OS/360 had some "excellencies in design and execution", it had some noticable flaws that stem from the design process.

His central argument is:

Why are industrial teams apparently less productive than garage duos?

Interesting exposition of the "joys of the craft" of programming:

Also "woes of the craft"

An analysis of sources of programmer optimism:

Man-month: fallacy of lack of communication or serialization

Naive preference for "small sharp team of first-class people" ignores the problem of how to build a *large* software system.

Harlan Mills proposed "surgical team" approach. [Not applicable everywhere.]

Conceptual integrity:

Careful division of labor between architecture and implementation allows conceptual integrity in large projects.

Argues that designing implementations is equally creative work as architecture. Cost-performance ratio depends most heavily on implementer; ease of use most heavily on architect.

External provision of architecture enhances creativity of implementors. They focus on what they uniquely do. Unconstrained most thought and debate goes into archtectural decisions with not enough effort on implementation.

Experience shows that integral systems go together faster and take less time to test.

Need coordination and feedback between architect and builder to bound architectural enthusiasm.

Second system effect:

Communication & decision making


"Plan to throw one away; you will, anyhow."

"The most pernicious and subtle bus are system bugs arising from mismatched assumptions made by the authors of various components. ... Conceptual integrity of the product not only makes it easier to use, it also makes it easier to build and less subject to bugs." Received on Fri Aug 27 2004 - 14:45:40 CDT

Original text of this message