The Mythical Man-Month (Brooks, 1995)

The classic book on the human elements of software engineering. Software tools and development environments may have changed in the 21 years since the first edition of this book, but the peculiarly nonlinear economies of scale in collaborative work and the nature of individuals and groups has not changed an epsilon. If you write code or depend upon those who do, get this book as soon as possible -- from Amazon.com Books, your library, or anyone else. You (and/or your colleagues) will be forever grateful. Very Highest Recommendation.

Book Description

Since the first publication of The Mythical Man-Month in 1975, no software engineer's bookshelf has been complete without it. Many software engineers and computer scientists have claimed to be "on their second or third copy" of the book. Now, Addison-Wesley is proud to present the 20th anniversary edition-and first revised edition ever-of Fred Brooks's now legendary collection of essays on the management of computer programming projects. The 20th Anniversary edition is an updated, enhanced re-release of the Brooks classic. Included are all of the existing essays that were originally presented, with the addition of three new essays assessing the current status of software project management. Brooks's well-known 1986 article, No Silver Bullet, is also included. This 20th Anniversary edition is a major event in computer publishing.

[My own personal opinion is that this book should be required reading for anyone involved in the field of software design. You will eventually learn all of the lessons taught - either through reading this book or through your own mistakes as a programmer - JLJ.]

p.44 Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.

p.102-103 Much more often, strategic breakthrough will come from redoing the representation of the data or tables. This is where the heart of a program lies. Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious... Representation is the essence of programming.

p.116 In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. the discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done. [2] Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.

p.256-257 I argue in chapters 4 through 7 that the most important action is the commissioning of some one mind to be the product's architect, who is responsible for the conceptual integrity of all aspects of the product perceivable by the user. The architect forms and owns the public mental model of the product that will be used to explain its use to the user. This includes the detailed specification of all its function and the means for invoking and controlling it... This role is a full time job... To make the architect's crucial task even conceivable, it is necessary to separate the architecture, the definition of the product as perceivable by the user, from its implementation. Architecture versus implementation defines a clean boundary between parts of the design task, and there is plenty of work on each side of it... Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity.

Enter supporting content here