Excerpts from Mystical man month

Found this note from a software engineering lecture notes and thought to post it here.

Mythical Man Month
Why does software fail?

Difficult to estimate time
Optimism
Effort != progress
Schedule not monitored
Slippage induces addition of people
Brooks says programmers are optimists (everything will go right etc...). Incompleteness and inconsistencies become clear only during implementation. He concludes that experimenting, "working out" are essential disciplines.

Each task has a nonzero probability of failure or slippage. Probability that all will go well is near zero.

Cost varies with manpower and resources, but progress does not! Hence, using "man month" (person month) as a measure is misleading and dangerous. They are interchangeable only when there is no interaction whatsoever between tasks.

Draw line downwards top left to lower right months (y) vs people (x) for a perfectly partionable task.
For semi-partionable task, show convex downward curve top left to bottom right
For unpartionable task, show flat line from same months vs people graph.
For partionable tasks that require communication, must add communication to the cost of completion. Communication is:

training (technology, goals, overall strategy, plan of work)
intercommunication; if each pair must communicate, cost grows with "n(n-1)/2". Meetings of >2 people makes it even worse!
For building a system (requires lots of communication), the communication effort quickly dominates the effort. Adding more people lengthens not shortens the schedule

Testing cost underestimated always. Brooks suggests:

1/3 planning (yes this costs a lot)
1/6 coding
1/4 component test, early system test
1/4 system test, all components in hand
TJP: don't forget that writing test harnesses can be almost as much work or sometimes more as writing the actual code.

Delays during final testing are very demoralizing!

Two reasons of failures:
Gutless estimating
Urgency of boss forces programmers to agree to unrealistic schedules.

It is very hard to defend an estimate (good or bad); people use "hunches"