Some insights from The Mythical Man Month starting from Chapter 11

I recently read The Mythical Man Month, a classic book about software development.

I thought this quote was tres amusant:

“The Bible of Software Engineering”, because, “everybody quotes it, some people read it, and a few people go by it.”

In my reading of the book, around chapter 11, “Plan to Throw One Away”, I got the idea to annotate and underline sentences and paragraphs that rang true with my experience or that I thought were insights that I and everyone should take into account.

Now that I’ve finished it, I thought I’d jot those points, that I felt the need to underscore, here. Flicking back through the earlier chapters there are lots of other points I ought to underscore, but that’s for another time.

I often see or participate in debates about software development that are better summed up by many clear insights from MMM, so it’s good for me to jot them down; having a common vocabulary and literature avoids a bunch of redundant discussion. For example, I saw some rather odd posts to Reddit’s programming section with laboured gardening and writing analogies.

I’m not sure what the legality of typing up so much of a book is. There is a lot more context to each of the points below, so you really need the book anyway to fully grok everything covered. Many points in the book may or may not have been underscored depending on the availability of a pen at the time, and I miss out the first ten chapters. Others downright do not make sense without the context which I don’t feel comfortable in further quoting verbatim.

At any rate, most of the quotes below have been quoted verbatim elsewhere.

Plan to Throw One Away

Pilot Plants and Scaling Up

The Only Constancy is Change Itself

Plan the System for Change

Plan the Organization for Change

Two Steps Forward and One Step Back

One Step Forward and One Step Back

Sharp Tools

High-level Language and Interactive Programming

The other face

Self-Documenting Programs

No Silver Bullet

Does It Have to Be Hard?—Essential difficulties

Complexity

Below; functional programming springs to mind:

I think the below is a very interesting point; having a visual mind does not seem to help you in programming.

Which follows nicely into the next point I underscored a page later:

Graphical programming

Program verification

Environments and tools

One point that reminded me of a recent post by Joe Armstrong to the Erlang mailing list:

(And I don’t think ‘intellisense’ really covers it.)

Promising Attacks on the Conceptual Essense

I found this to be a very interesting perspective considering the era in which it was written:

Incremental development — grow, not build, software

Great designers

There is a lot more crammed in this book, some several more chapters. But I’ll stop here.