Notes on "Mythical Man Month" by Fred Brooks

Personal Notes

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks's law, and is presented along with the second-system effect and advocacy of prototyping.

Software management by the Time prism

• Software is hard to estimate because people are optimitic in their estimate.
• We should consider the worst case scenario
• Half of the time (at least) is spent on testing
• There is a non trivial cost when adding manpower to a software. You take times from productive people.

Protect the "Conceptual integrity" of the software

• The overall architecture of a software should comes from few mind
• You should document your architecture choices
• You should constrain your system
• Local optimum shouldn't challenge the whole integrity of the software.

Communication problem

• As the team grows the number of communication canal grow too.

• One way to mitigate this problem is to split teams, and interface them by managers.

Teams

• Senior technical & managerial man (the surgon)
• Diverse people (stacking people with similar skills won't work)
• Relatively small around or less than 10 people
• You should separate the role of Architect and Product Manager if your team is equal or above 4 members

Gouvernance

• Since software projects are knowledge and experience based they tend to be directed by "Aristocracy"

Second system effect

• The architect on his first design will not anticipate issues but respond to them.
• On his second design, due to his first experience the architect might overthink the second system

Documentation

• In their essence documents should answer to "What, When, How much, Where, Who"
• The Architectural choices should be documented and versionned
• Documents are a way to formalize the intention
• Code should be self-documentated, meaningful names and comments
• Having "persona" is important

Entropy

• As the time pass the entropy of a project grows.
• It grows to the point where moving one step forward makes you move two step backward.
• You should resist the urge to add feature compulsively.

High level language & compiler

• Using a high level language upgrade the productivity, reducing the number of lines wrotes.
• Compiler catch bugs and optimitize.
• I think, in some extend the same logic could be applied to GPT trend, it's a new tool that will reduce friction between the "WHAT" and the "HOW" to do something

Tests

• Test has soon has possible
• Test each pieces independently, but you must also test the whole system and revalidate each time you add a new piece to the system
• You should test from functionnal (Unit test) to integration (End to End)
• Tests are documentation that don't lie, it either works or doesn't
• You should test : Mainline, valid expections, invalid exceptions

Schedule

• You should have a schedule made of concrete milestones (Event such as "debugged version passes all test cases")
• The milestones should be unambigious and sharp-edged
• Chronic schedule slippage is a morale-killer
• Projects gets late one day at a time
• A PERT is usefull to visualize schedule dependencies
• A day to day status is important to detect slippage

Key take-aways

• Beware time estimation, in your estimate think about the testing that it implies
• Having an Architect that enforce the "conceptual integrity" is essential
• Communication & Documentation are keys
• Not "Write", not "Build", we "Grow" software

Next read :

• Peopleware