The mythical man month is a collection of essays about software engineering. Some articles cover topics that have barely changed over the years. When reading the book you are thankful that a couple of things drastically improved over time.

Thus it has become a book that has been cited thousands of times. I mainly read the book to see what all the hype was about. I would recommend the book to developers that have 3-5 years of experience in the industry.

Key Points

1. The Tar Pit

Programming is a very difficult task, it is a lot of fun. A combination of the joy of making things, being useful for other people, solving a complex puzzle and you have to use your imagination.

The major challenge of programming is that the program must work perfectly and formulated very precise. Other challenges around programming is communication - how other people set objectives and priorities - most of the time you do not control your work or the goal of your work.

2. The mythical man month

Good cooking needs time, some tasks cannot be hurried.

The “man - month” is a dangerous myth, as it suggests that men and months are interchangeable. However developers have all different skill levels, and also months are not equal (cant move Xmas to another month).

The more people work on the task, the more communication is needed → this in turn will lead to a late project become even more delayed by adding more people to the project.

A general rule of thumb for time needed for a task:

• 16% Coding
• 33% Design
• 25% Component Testing
• 25% System Testing

Because our estimations are so bad, we rarely defend the estimation against management or customer pressure, which in turn creates more pressure.

3. The Surgical Team

You can observe that there is such a thing as a 10x developer - a developer that is 10x more productive than a bad developer.

A strategy would be to form a team around these 10x developers.

It should consist of:

• the surgeon (the chief programmer)
• the co-pilot (basically programmer with similar experience, acts as a backup, evaluator, and proposes alternative design strategies)
• Administrator (the boss) - a manager that takes care of all the budgets, personal matters etc.
• The editor (a documentation writer) - a person responsible for writing internal and external documentation
• 2 secretaries (for handling correspondence, bureaucratic work)
• The program clerk (keeps track of the versions and documentation of the project, does all the smaller tasks that are usually forgotten)
• The tool smith (a person that evaluates the tool chain) - proposes new tools updates existing tools
• The tester (basically QA)
• The language lawyer (a programming language specialist), a code reviewer, teaches new programming syntaxes

4-9

I would skip these chapters, they cover system design, communication, documentation, estimation - they have not aged well and I suppose are better described in other books.

Chapter 9 covers mostly non-functional requirements, and limitations on how much memory a program uses, that is interesting and can be optimized, but most of the time these days its not the major concern of most programmers. However it is important to think about non-functional design requirements.

10. The Documentary Hypothesis

Critical Documentation for the project is needed, however different for each type of customer may need a different type of documentation

You need to maintain this documentation and you can use it as a communication channel to the project stakeholders.

11. Plan to Throw one Away

Some problems in programming cannot be solved with the first design, and inevitably you will have to redesign the software and start from scratch.

One thing to think about is to plan that the software will change, thus your design is flexible enough for future changes.

However usually there is a reluctance to actually adjust and change the design, because the larger the project the harder it becomes to introduce changes.

Note: This is quite an interesting notion, and the reason Test Driven Development has gotten so much traction lately, with an extensive test suite you actually can be more flexible with your changes, as you have the confidence that everything still works after a bigger change

Maintenance of Software will be probably 1-1.5x higher than the original cost of developing the software. The more users the system has the more bugs will be found and thus more bugs have to be fixed (Note: this is a reason why testing and software craftmanship are very important)

Overall this chapter highlights the importance of many current day disciplines in software development.

12. Sharp Tools

Project managers should set aside time for developing your own tools, and ensure that the developers have the correct machines to test their software.

There is a high focus on rapid debugging cycles. The book talks about 2hour cycles - luckily computers have evolved and these cycles in most projects are shorter than that.

Conclusion

The mythical man month provides an interesting insight into software development of the past.

Parts of the book are totally timeless, and are going to be quoted for a very long time. Other parts just have not aged very well. Overall it is a very interesting read.