Thoughts on "The Mythical Man-Month" by Frederick P. Brooks, Jr.
I recently completed reading the classic software engineering book "The Mythical Man-Month: Essays on Software Engineering" by Frederick P. Brooks, Jr.
I read the 20th anniversary edition (published in 1995) which contains the original sixteen essays published in the first edition of the book in 1975, plus a couple of newer essays and a chapter reflecting on the original essays.
It wasn't a bad read, but I can't say I got a tremendous amount of insight from it. I think this is probably more reassuring than anything in a sense that most of the lessons in this book came from experiences before 1975 and if they are now common, expected challenges it shows the industry has learned from its early challenges.
It's hard for a book on software to remain relevant decades after its first publication. I think this 40+ year old software engineering book remains relevant because it addresses the experiences and challenges of full system development life cycle of large software projects - a topic still very relevant today.
The first chapter of the book addresses the idea that creating a piece of software that accomplishes a task is not the same as creating a product. I probably learned this best in my experience of having a small software business where I made audio software for the commercial market in the early-to-mid 2000s.
The author puts a factor of nine on the cost of creating "a product" versus "a program". I'm not sure it's that high in all cases, and I'm not sure there is a constant multiplier that can be applied to all projects, but I agree the difference in required effort is substantial.
The second chapter describes the "mythical man-month". This is the idea that it's a fallacy to believe that the number of software developers working on a project, and the estimated effort in months of that project, are interchangeable.
The author states "men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them". The "no communication" qualifier in that quote is key.
I'm a firm believer that effective communication in any software project involving any number of people is essential. The greater the number of people involved in a project, the greater effort of communication, coordination and training required.
A number of the following chapters cover techniques for managing development of large systems. Some of these are probably worthwhile to consider and others might not be as applicable today as when the book was originally written.
What I did find very impressive in this book was the emphasis on the importance of tests, as well as it mentioning the effectiveness of continuous integration and iterative development well before these topics came to be fully appreciated in the industry. For example:
- "A program should be shipped with a few test cases, some for valid input data, some for borderline input data, and some for clearly invalid input data". (pg 248)
- "The system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below". (pg 201)
- In Chapter 19, written in 1995, the book quotes James McCarthy from Microsoft on his "build every night" approach: "The build cycle becomes the heartbeat of the project. Every day one or more of the programmer-tester teams check in modules with new functions. After every build, we have a running system. If the build breaks, we stop the whole process until the trouble is found and fixed. At all times everybody on the team knows the status". (pg 270)