I read 『人月の神話』フレデリック・P・ブルックス，Jr.（著） (The Mythical Man-Month by Frederick P. Brooks, Jr.), so I’ll share the insights I gained from the book.

Background: The Mythical Man-Month, Brooks' Law

I wanted to deepen my understanding of the Mythical Man-Month and Brooks’ Law, so I read this book.

Below are quotes and notes from the sections that left an impression on me.

Chapter 2: The Mythical Man-Month

The fourth reason is that schedule progress is not properly monitored.

Fifth, when schedule delays are discovered, the natural (and traditional) response is to add manpower. Like adding gasoline to a fire, this response makes matters worse, much worse. More fire demands more gasoline, and thus begins a vicious cycle that ends in complete failure.

Optimism

All programmers are optimists.

Man-Month

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton, but it is not true of system programming by any stretch of the imagination.

? Man-months cannot be applied to software development.

For some years I have been successfully using the following rule of thumb for scheduling a software task:

1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand

? Guidelines for software development scheduling

Brooks' Law can be stated simply: **Adding manpower to a late software project makes it later.**

? Brooks’ Law

Chapter 3: The Surgical Team

The Problem

As part of the study, they measured the performance of the experienced programmers. Within this group alone, the ratios between best and worst performance averaged about 10:1 on productivity measurements and 5:1 on program speed and space measurements!

? There’s a 10x difference in productivity and 5x difference in development speed and quality.

Mills' Proposal

He proposes that each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.

? Tackle each segment of large work with a team.

Chapter 7: Why Did the Tower of Babel Fail?

A Management Audit of the Babel Project

So, they had everything they needed. Why did the project fail? Where did they lack? They lacked two things: communication, and its consequent, organization. They could not talk to each other; hence they could not coordinate.

? Even with everything in place, projects fail due to lack of communication.

Chapter 14: Hatching a Catastrophe

Milestone or Millstone?

How does one control a big project on a tight schedule? The first step is to have a schedule. Each of a list of events, called milestones, has a date.

? Milestones are necessary for large projects.

The only thing concerning the rule for making milestones is that milestones must be concrete, specific, measurable events, defined with knife-edge sharpness.

? The definition of milestones is key.

Concrete milestones, on the other hand, are 100-percent events.

But looking at the horizon of a decade hence, I see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.

? No silver bullet appeared even after 10 years.

Chapter 19: The Mythical Man-Month after 20 Years

Plan to Throw One Away—You Will Anyhow. The Waterfall Model Is Wrong!

The biggest mistake in the "build one to throw away" concept is that it implicitly assumes the classical sequential or waterfall model of software construction.

? The approach assuming the waterfall model is wrong.

• Feedback from later to earlier stages • Constraining such feedback to adjacent stages so as to bound the costs and schedule rework by the feedback

**How Valid Is Brooks' Law?**

There have since been careful studies evaluating the validity of Brooks’ Law (deliberately oversimplified).

(omitted)

They conclude that “adding more people to a late project always increases its cost, but does not always increase its schedule” (emphasis in original). In particular, they find adding people to be a much safer tactic early in the schedule than later.

? Adding people earlier is better.

The new people added to a late project must be both technically capable and experienced in working as team players. They should be ready to jump in and work on the project without attempting to change or improve the process itself.

? I think it’s reckless to jump in vigorously without improving processes in delayed projects.

That’s all from the Gemba, where I want to stay unrelated to Brooks’ Law.