The Mythical Man-Month: Essays on Software Engineering
For those who doesn’t know The Mythical Man-Month, it is a must read classic that all software engineers should read at least once. That way I was convinced to start reading it. Besides, I’ve seen so many recommendations over the internet and so many references to it in the literature that I was ashamed I hadn’t read it yet, until now.
It was written by Frederick P. Brooks, Jr. in the 1975 after he had worked as a project manager for the IBM System/360 computer and later for OS/360 development in the 60′s, both huge pieces of engineering for the time. Brooks tries to collect all the best practices and rules of thumb in software development and project management of complex projects that he learned during those experiences.
The anniversary edition (2nd edition), the one I’ve read, includes a few new chapters besides the original essay. Those are the No Silver Bullet (which itself would need another post) and a few others that review the propositions of the book some time later.
In this post I’m going to highlight a few things I liked about the book as a reminder to my future self. The bellow bullet points are fragments from the book (in italics) followed by my comments about them.
- The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable. This is the argument that gives title to the book. Many tasks during the development of a program cannot be partitioned due to its inherent sequential constraints and even when tasks could be carried in parallel there is always an overhead in communication between workers.
- Brooks’s Law: Adding manpower to a late software project makes it later. This is a consequence of all the communication that is generated and all the time needed to train the new people.
- All programmers are optimists. Thank god it wasn’t just me.
- Conceptual integrity is the most important consideration in system design. To achieve it, the design should proceed from one mind or a small group of minds.
- The second is the most dangerous system a person ever designs; the general tendency is to over-design it. As normally an architect has not the confidence to implement all the ideas that come up to him during its first design. During his second design, an architect will try to implement all the stored ideas from his first design.
- Plan to throw one away, you will anyway. It is very important to prepare the design for changes because valid changes in objectives may certainly arise during development.
- How does a project get to be a year late? … One day at a time. Brooks gives some great advices about preventing a schedule slippage.
There are many other interesting topics in the book like the importance of communication and organization of groups or how to scale small groups to design and implement large systems.
Overall it is a very good book even if you aren’t really interested in software management.
Tags: software engineering
You can comment below, or link to this permanent URL from your own site.
