Comments on Mythical Man-Month: Chapter 2

Chapter 2. The Mythical Man-Month

2.1 More programming projects have gone awry for lack of calendar time than for all other causes combined.

I agree. The cause is lack of connect between desire and implementation. Because of other reasons (non-repeatability inherent as a design consideration, mentioned in chapter 1). Also, it is easier to think of a thing than it is to create a thing. This is not particular to software. But maybe it is worse for software. Drawing a diagram of a building is hard thoughtful design work, but everybody can compare that directly to lifting a beam with a crane to implement the drawn line, and how much harder the latter is compared to the former. But thinking about some one else's thoughts seems makes the others thoughts seem so easy.

2.2 Good cooking takes time; some tasks cannot be hurried without spoiling the result.

This isn't special to programming. Neither really is the first one but for that I could think of programming specific reasons.

2.3 All programmers are optimists: ''All will go well.”

Again, this isn't special to programming, or even engineering, but any kind of planning.

2.4 Because the programmer builds with pure thought-stuff, we expect few difficulties in implementation.

2.5 But our ideas themselves are faulty, so we have bugs.

faulty = inconsistent, incomplete at the best of times, but usually just underspecified, vague, and inchoate

2.6 Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.

On an assembly line, labor/time -is- a commodity, adding more people -does- make things better. Again, define what it is being added to. Adding more people to a project certainly may make things go faster, when those pieces are small, identifiable, seperate parts.

2.7 Partitioning a task among multiple people occasions extra communication effort-training and intercommunication.

No doubt. Communication costs increase with size. Software is hardly ever assembly line. Every product is new. One way to think about it is that software -is- design, you're designing an assembly line to automatically take care of many multiples of objects. Yes, you can assign more people to more sandbags, to add items to widgets. But the things that a programmer is working on...every item is a new, different thing that can't be treated in exactly the same way as the previous one.

2.8 My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing.

This is just SWAG (or more charitably, what he happens to do). Even if timing experiments are done, too much is not measurable in a controlled fashion. Each of these events is 'as long as a piece of string' (i.e. however as long as it will take). Is this normative or descriptive? As percentages then meaningless.

2.9 As a discipline, we lack estimating data.

Yes. Because things are not repeatable.

2.10 Because we are uncertain about our scheduling estimates, we often lack the courage to defend them stubbornly against management and customer pressure.

I'd also add that the occupational hazard of the engineering discipline is concern for details and technical aptitude, and so a lack of practice in human psychological concerns. That's general, but also the specific acceptance of authority's wishes too easily because wishes aren't facts and so cannot be argued.

2.11 Brooks's Law: Adding manpower to a late software project makes it later.

Famous, supported by data. Depends on definitions (what -kinds- of projects).

2.12 Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication.

Yes, those are the major subparts of Brooks' law (when it applies)