The Mythical Man Month is one of those seminal works of software engineering that praise is heaped upon and quoted at most if not all software firms. The book itself is perhaps most famous for popularizing the rule that “adding more programmers to a late project makes it even later”. This however is not the only conclusion to be gathered from this book.
The Summary
The book should perhaps be most praised for being written in a manner that the engineer in me can get behind. Short and fast chapters with not a lot of fuss of double telling a point after it has been made. Including a bullet point review of the book, it is a short 300ish pages long. Perhaps the largest complaint of the book is that the focus of the book is upon system or what is now known as embedded programming. That being said there are a great many points to be gathered from the book.
The first is that there are several different types of programs, simply a program, a programming system, a programming product and finally a programming system product. Only the last is one that is the goal of most programming teams. The first is essentially something that the programmer can use and build in the course of a few days or weeks of effort. The second and third are required intermediaries to the fourth but moving in opposite directions. A programming system is where a program becomes a part of a larger project. This requires the program to mandate all input and output to be semantically valid and correct, to be on a well-defined budget of resources (be they computer time/memory and i-o limitations) and to play well with other program.
The programming product requires a vast suite of test cases so that other programmers may rely upon it and through documentation so that others may extend it’s feature set. Each of these two intermediary steps requires in the authors words “three times the cost of the earlier one”, so that together the programming system product “costs nine times as much”.
Still inside of the first chapter, do we get the next great revelation; programming is a fun and abstract art. This leads to its own set of problems, least of which is the abstract part. Perhaps the greatest of these is the requirement of perfection demanded from computers. The list of problems quickly grows in the next few paragraphs, being at the whim of others decisions and others goals, depending upon others perfection for a programmer rarely works alone in all aspects of a project, the design is more fun that actual implementation, debugging becomes more difficult the further one goes, and finally that rarely does it seem to be ahead of the curve more often than not it feels that the project is already obsolete before completion.
I love the image that the author weaves here of Software Engineering being a tar pit and him trying to “lay some boardwalks across the tar”.
Scheduling software is a notoriously dark art. The author brings forth a simple and basic rule for dividing up the time on a software project.
- 1/3 Planning
- 1/6 Coding
- 1/4 Component and early system test
- 1/4 Systems test, all components in hand
The next bit is the most famous of the conclusions from the book in which the author discusses how adding more people to a project doesn’t make it any sooner to completion, if anything slows down the project overall. There is the matter of both training these new engineers on the inner workings of the project before they can even be brought into working on the project on anything approaching a full-time basis, the next is that as you add more people there develop more lines of communication and more time to delegate and split tasks into manageable pieces for each person to work on. Essentially far easier for two people to meet and decide on two parts of the project to tackle, far harder for three, four or five people to meet and delegate the project into x number of pieces for each to work. Especially for the task to be divided in such a way that you are both accounting for one’s abilities and trying to time the project so each finishes at roughly the same time.
The author coming from the discussion of how more people on a project leads to an overall slowdown in the project argues with more data than any other section for a “surgical team” to tackle projects, even those ridiculously large ones to be split into manageable portions for surgical teams to take on as opposed to “hog-butchering team”. Essentially for a coordinated effort by one or two programmers with all others acting in support of those one or two programmers.
The vast majority of the rest of the book espouses and stresses these points in some way or another. From espousing that a good design (note design here terms of design of the architecture not design in look and feel) can only come from a single or extremely limited number of persons. That architects of systems of a system have a tendency to over design to achieve complete interoperability and extensibility. Assigning value to both the number of bytes and time needed for a function to complete is a good way to limit over design.
There must be both formal and informal level design documentation. Intercommunication and organization are requirements for even a decent project to take flight not just among team members but across all teams. The author argues for daily meetings for all team members with weekly inter-team meetings. He also argues for some form of a project workbook to collect all changes and thoughts of the team members so that anyone reviewing or testing a section has complete access to all knowledge of that section on the spot. At the same time the author argues for all team members being required to see and read the workbook, at a later date he becomes convinced otherwise and instead stresses that the information be made available but not in essence required reading. Plan for throwing away an initial version of the project. Iterate quickly on a project, create a working version as quickly as possible and keep up it’s working state throughout the course of the project. A project does not all of sudden become late but rather over the course of one piece taking longer or one day of missed meetings.
Documentation while hated is a really important feature for a good project, not just for the customer but for programmers to know the why behind a piece of code. Re-using or purchasing that which has previously been done to save lots of time and effort than in effect re-creating the wheel. Adding functionality to software in a piece-meal fashion, rather than all at once.
It’s all in all a long list of points for such a short book and perhaps most interesting for being such an old book espouses some ideas that I would have thought not in practice until much later.
The Review
Overall wonderful to read, super fast and easy to read. Lots of examples and data points from basic research to analogues and one-off stories to provide force behind each point. The majority of the points I would take little to no time to critique except for that it focuses heavily on systems programming and hence not in an area that I find myself (and probably most modern programmers) working in. Little effort to none is made for focusing on the actual usability of a project beyond that of other programmers, whereas most Software Engineers find themselves writing code that a normal human being will interact and deal with. The book also develops a ten person strong team with just one or two people actually devoted to writing code. This seems more than a bit of overkill. I would suggest something much closer to the 37Signals plan, one manager, two programmers, one designer and one tester. Perhaps my smallest critiques is the focus on “man” hours as opposed to person hours, also the little one off here and there of using a religious idea as proof for a software engineering plan. For instance, in the bullet points on using two core programmers on a team the author makes a footnote of “Note God’s plan for marriage”. Minor annoyances I admit but they detract from an other wise well written and developed ideas.
I would recommend this book to not just Managers of software projects but also to the programmers under their leadership in the hope that they understand better the difficulty in creating an outstanding “programming system project” and quite possibly how to build a better maintainable project.
Leave a Reply