The Mythical Man-Month #2 The Mythical Man-Month

1. The Mythical Man-Month
#2 The Mythical Man-Month

2. Index
1. Intro 3-10
2. Optimism 11-16
3. The Man-Month 17-24
4. Systems Test 25-31
5. Gutless Estimating 32-35
6. Regenerative Schedule Disaster 36-46
2

3. Intro
3

4. 4
Good cooking takes time.
If you are made to wait,
it is to serve you better,
and to please you.
MENU OF RESTAURANT ANTOINE.
NEW ORLEANS

5. Intro
5
More software projects have gone awry
for lack of calendar time
than for all other causes combined.

6. Intro
Our techniques of estimating are
poorly developed.
6

7. Intro
Our estimating techniques hiding
the assumption that men and months are
interchangeable.
7

8. Intro
Software managers
often lack the courteous stubbornness
of Antoine's chef.
8

9. Intro
Schedule progress is poorly monitored.
9

10. Intro
The natural (and traditional) response is
to add manpower.
10

11. Optimism
11

12. All programmers are
optimists.
12

13. Optimism
13
Creative activity into three stages:
1. the idea
2. the implementation
3. the interaction

14. Optimism
In many creative activities
the medium of execution is intractable.
14

15. Optimism
But, Computer programming creates
with an exceedingly tractable medium.
15

16. Our optimism is
unjustified.
16

17. The Man-Month
17

18. The man-month is
a deceptive myth.
18

19. 19
Man
Month
Fig. 2.1
Time versus number of
workers
—perfectly partitionable task

20. 20
Man
Month
Fig. 2.2
Time versus number of
workers
—unpartitionable task

21. 21
Man
Month
Fig. 2.3
Time versus number of
workers
—partitionable task
requiring communication

22. The Man-Month
The added burden of communication is
made up of two parts,
training and intercommunication.
22

23. 23
Man
Month
Fig. 2.4
Time versus number of
workers
—task with
complex interrelationships

24. Adding more men
then lengthens.
24

25. Systems Test
25

26. Testing is usually
the most mis-scheduled
part of programming.
26

27. System Test
27
I have been successfully
using the following rule:
● l/3 planning
● l/6 coding
● l/4 component test and early system test
● l/4 system test, all components in hand.

28. System Test
The fraction devoted to planning is
larger than normal.
28

29. System Test
The half of the schedule devoted to
debugging of completed code is
much larger than normal.
29

30. System Test
The part that is easy to estimate,
i.e., coding, is
given only one-sixth of the schedule.
30

31. Very important to
allow enough
system test time.
31

32. Gutless Estimating
32

33. But it cannot govern
the actual completion.
33

34. Gutless Estimating
34
It is very difficult to make jobrisking
defense of an estimate that is certified
chiefly by the hunches of the managers.

35. Gutless Estimating
35
We need to develop and publicize
productivity figures,
bug-incidence figures,
estimating rules,
and so on.

36. Managers will need to
defend their estimates.
36

37. Regenerative
Schedule Disaster
37

38. 38
A task is estimated at
12 man-months and assigned to
three men for four months.
Figure 2.5

39. 39
What are the alternatives
facing the manager?
Figure 2.6

40. 40
1st:
Assume that only the first part of
the task was misestimated.
-> Add 2 men to the 3 assigned.
Figure 2.6

41. 41
Figure 2.7
2nd:
Assume that the whole estimate
was uniformly low.
-> Add 6 men to the 3 assigned.

42. Regenerative Schedule Disaster
3rd:
Reschedule.
(But rescheduling will not have to be
done again.)
42

43. Regenerative Schedule Disaster
4th:
Trim the task.
(This is the only feasible action.)
43

44. Regenerative Schedule Disaster
In the first two cases,
insisting that the unaltered task be
completed in four months is disastrous.
44

45. 45
Figure 2.8
Substantially more than 7
man-months of effort remain,
and 5 trained people and one
month are available.

46. Regenerative Schedule Disaster
The temptation is very strong to repeat
the cycle, adding yet more manpower.
Therein lies madness.
46

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

48. More software
projects have gone
awry.
48