Transcript Document

THE MYTHICAL
MAN-MONTH
How does a project get to be a year late?
…… one day at a time?
Xianling Feng
Survey of Software Engineering (CS 5391) 2003
7/17/2015
1
The issue: -- Why do we need to read this one?
Software projects go awry for lack of calendar time.
-- Why is the disaster?
Frederick P. Boorks, Jr,
“the farther of the IBM System/360)”
the project manager of the Operating System Project
has his analysis and solutions to the issue.
“THE MYTHICAL MAN-MONTH” published on Datamation in 1974
and republished in 1995.
You’ve got read it since your manager might have read it.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
2
The issue: -- Brooks’ answers
Software projects go awry for lack of calendar time.
-- Why is the disaster?
1. Estimating Techniques are poorly developed
-- with assumption that all will go well. (optimism)
2. Estimating Techniques confuses the effort with progress
(measurement)
-- with assumption that men and months are interchangeable
3.
Lack of "courteous stubbornness" to make people want a good
product
-- because of being uncertain of the estimates
4. Schedule progress is poorly monitored.
5. When schedule slippage is recognized
--> Natural (traditional) response is to add manpower
--> dousing a fire with gasoline
Survey of Software Engineering (CS 5391) 2003
7/17/2015
3
1. Optimism
Quotes from programmers:
"This time it will surely run.”
"I just found the last bug”
In reality, the pride and optimism are not
justified. Hence, over-optimistic schedules
are produced.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
4
2. The Mythical Man-month
• Cost indeed varies as men * month. However, progress (effort
needed to finish a project) cannot be measured by men *
month.
• Brooks points out:
– the man-month as unit for measuring the size of a job is a
dangerous and deceptive myth.
– Man-month measurement implies man and month are
interchangeable. In fact, they cannot all the time.
– Man and months are interchangeable only when
a task can be partitioned among many workers
with no communication among them.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
5
2. The Mythical Man-month (Cont.)
For software engineering, it is not even approximately true:
--the sequential constraints make a task un-partitionable.
--tasks can be partitioned, but need communication (training
and intercommunication)
- Training normally cannot be partitioned -- added effort
varies linearly with number of workers.
intercommunication effort increases as n(n-1)/2
Survey of Software Engineering (CS 5391) 2003
7/17/2015
6
2. The Mythical Man-month
(direct implication)
The direct implication of
Man-Month is that if one
man takes 10 month to
do a job, 10 men can do
it in one month.
Implication of Man-month
12
10
Months
8
This may be true of
picking cottons. (where
no communication is
needed among workers)
6
4
2
0
0
2
4
6
8
10
12
Men
Survey of Software Engineering (CS 5391) 2003
7/17/2015
7
2. The Mythical Man-month
(for software project)
Adding men lengthens schedule
50
Months
40
30
20
10
0
1
2
3
4
5
6
7
8
For software project,
communication effort
is great, adding more
men lengthens
schedule due to the
added
communication
overhead.
9 10
Men
Survey of Software Engineering (CS 5391) 2003
7/17/2015
8
2. The Mythical Man-month
(Communication effort)
communication efforts = n(n-1)/2
communication efforts
communication efforts v.s. number of
subtasks
16
14
12
10
8
6
4
2
0
15
10
6
3
1
0
2
4
6
8
number of subtasks
Survey of Software Engineering (CS 5391) 2003
7/17/2015
9
2. More accurate estimation
-- System Test
Testing is usually the most mis-scheduled part because
people are often too optimistic and its sequential nature.
Brook's Rule of Thumb to estimate a software task:
1/3 planning
1/6 coding
1/4 component test
1/4 system test
(33 %)
(17 %)
(25 %)
(25 %)
Please note that half of the time is to be spent on testing.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
10
2. More accurate estimation
-- Gutless estimating
Estimation is based on the customer’s urgency
-- another cause of faulty scheduling
To solve the problem:
-- develop and publicize productivity figures,
bug-incidence figures
-- estimating rules
Survey of Software Engineering (CS 5391) 2003
7/17/2015
11
3. Adding manpower to shorten the schedule
-- Regenerative Disaster
What does one do when an essential software
project is behind schedule?
A natural answer might be:
Add manpower.
-- This may or may not help.
Let’s take an example to see why.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
12
3. Adding manpower to shorten the schedule
-- Regenerative Disaster
An Example:
Given: Task: 12 man-month; Men: 3; Months: 4; Milestones: 4
The schedule:
A
B
C
D
+----------+----------+----------+----------+
At the end of the 2nd month, it is found that only the first milestone
is reached:
A
+----------+----------+----------+----------+
What can we do about it?
Survey of Software Engineering (CS 5391) 2003
7/17/2015
13
3. Adding manpower to shorten the schedule
-- Regenerative Disaster
“Solution 1”: Assume task must be done on time.
Assume only the first part (A) was misestimated.
3 milestones left (B, C, D)
--> need 3 milestones * 3 man-month/milestone
= 9 man-month
(9 man-month / 2 month) = 4.5 men --> add 2 men !
Survey of Software Engineering (CS 5391) 2003
7/17/2015
14
3. Adding manpower to shorten the schedule
-- Regenerative Disaster
“Solution 2”: Assume task must be done on time.
Assume the whole estimate was uniformly misestimated.
Each part needs (3 men * 2 month) = 6 man month/milestone
3 milestones left (B, C, D)
--> need 3 milestones * 6 man-month/milestone
= 18 man-month
( 18 man-month / 2 month ) = 9 men --> add 6 men
Survey of Software Engineering (CS 5391) 2003
7/17/2015
15
3. Adding manpower to shorten the schedule
-- Regenerative Disaster
“Solution 3”: Scrap the old the schedule, make a
new one.
“Solution 4”: Trim the task (if sticking to the original
schedule is too costly).
Survey of Software Engineering (CS 5391) 2003
7/17/2015
16
3. Adding manpower to shorten the schedule
-- Regenerative Disaster
“Solution 1” – revisited at the end of 3rd month:
1 experienced man trains 2 inexperienced --> 3 man-months used
Repartition the task from 3 parts to 5 parts --> totally 9 + 3 = 12 man-months
At the end of 3rd month, 9 - 3*1 + repartition ( work lost, more system testing)
> 7 man-months task remains
7 man-months task to be finished by 5 experienced men --> not possible 
project delayed!
To be on schedule, 4 men instead of 2 need to be added -- which more than
doubles original team size.
Things looks so very bleak (the March 1 milestone is still not reached), the
temptation to add more men is so strong to repeat this cycle -- add more would
delay the project further by the same token.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
17
3. Adding manpower to shorten the schedule
– Brooks’ Law
“Solution 2” revisited
By the same token, it will lead to the same
"regenerative disaster“ as in “solution 1”.
This yields the Brooks’ Law:
"Adding manpower to a late software
project makes it later".
Survey of Software Engineering (CS 5391) 2003
7/17/2015
18
4. Programmer's Productivity Data
1. Portman's data (Charles Portman, manager of ICL's
Software Div. at Manchester)
Programming teams miss schedules by 1/2.
Work log shows that only 1/2 of the working time is spent
on programming and debugging.
Causes:
Machine downtime, short unrelated jobs, meetings,
paperwork, company business, sickness, personal time,
etc accounted the rest.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
19
4. Programmer's Productivity Data
2. Aron's Data (Joel Aron, Manger of Systems
Technology at IBM in Gaithersburg)
Very few interactions: 10,000 assembly
instrutctions/man-year
Some interactions: 5,000 Many interactions 1,500
System testing, support are not counted here.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
20
4. Programmer's Productivity Data
3. Harr's data (John Harr, manager of
programming at Bell Telephone Laboratory)
Control Program: 600 words/man-yr
Translator:
2,200 words/man-yr
Survey of Software Engineering (CS 5391) 2003
7/17/2015
21
4. Programmer's Productivity Data
4. OS/360 Data (IBM OS/360 experience)
Control program: 600 - 800 debugged instructions/man-year
Language translator: 2,000 - 3,000 debugged
instructions/man-year
This includes: planning, coding component test,
system test, support.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
22
4. Programmer's Productivity Data
Summary
Summary of the data
All data show that productivity (number of program
instructions) is related to the complexity and difficulty of the
task.
To estimate the complexity, use the following ratios:
Normal batch application :
Compiler :
Operating System :
1
3
9
Survey of Software Engineering (CS 5391) 2003
7/17/2015
23
5. Hatching a catastrophe
-- Causes for the delay,
“one day at a time”
Project delays are largely due to the daily slippage that is
hard to recognize and prevent:
Sickness of a key man -- meeting canceled
Machines all down -- lightning struck the power transformer
Disc not testing
Snow,
Jury duty
Family problems,
Emergency meentigs with customers
Executive audits
:
(the list goes on and on …)
Survey of Software Engineering (CS 5391) 2003
7/17/2015
24
6. Control a project on tight schedule
First, have a schedule -- pick up knife-edged, sharp milestones so
that people cannot lie about it.
Everybody in the team should understand:
Sharp milestones are a service to a team.
Fuzzy milestones are harder burdens
-- for it deceives one about lost time until it is irremediable.
Chronic schedule slippage is a morale-killer.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
25
6. Control a project on tight schedule
"The other piece is late"
-- Where is my piece in the project task network?
“A schedule slips a day; so what?”
It may or may not affect the completion date. How to know it? Look at
the PERT chart which shows the dependency of subtasks along the
time axis. It tells if a subtask is on the critical path that affects the
completion date.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
26
6. Control a project on tight schedule
-- What is a PERT chart?
A PERT chart is a project management tool used to
schedule, organize, and coordinate tasks within a project.
PERT stands for Program Evaluation Review Technique, a
methodology developed by the U.S. Navy in the 1950s to
manage the Polaris submarine missile program. A similar
methodology, the Critical Path Method (CPM), which was
developed for project management in the private sector at
about the same time, has become synonymous with PERT,
so that the technique is known by any variation on the
names: PERT, CPM, or PERT/CPM.
-- Excerpt from
http://searchsystemsmanagement.techtarget.com/sDefinitio
n/0,,sid20_gci331391,00.html
Survey of Software Engineering (CS 5391) 2003
7/17/2015
27
6. Control a project on tight schedule
-- What is a PERT chart?
Example of a PERT Chart from
http://searchsystemsmanagement.techtarget.com/sDefinition/0,,sid20_gci331391,00.html
Survey of Software Engineering (CS 5391) 2003
7/17/2015
28
6. Control a project on tight schedule
-- Under the rug
The manager may not want his/her boss know
what’s going on
Delay happens on first-line, first-line manager does
not want to report it to his/her boss for fear that the
boss will act on it and so to diminish his/her authority.
The boss needs to know it to get a clear picture of the
whole team. What to do by the boss?
1. Reduce the role conflict with the first-line manager so to
encourage the sharing of the status.
2. Yank the rug off
Survey of Software Engineering (CS 5391) 2003
7/17/2015
29
6. Control a project on tight schedule
-- Reduce the role conflict
1. The boss should not act on problems his
manager can solve.
2. The boss should not act on the problems
that is being reported , give a chance
for the manager to propose a solution.
-- The goal is to encourage sharing of
the status.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
30
6. Control a project on tight schedule
-- Yank the rug off
Form a Plans and Controls team using
PERT chart to periodically update the
status and reveal the delayed subtask
and so the first line manager's task is
reduced to the essentials -- making
decisions to act to catch up
the schedule.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
31
Epilogue – Brooks’ suggestions
The management of the software development
(very complex craft) demands:
1. our best use of new languages and systems;
2. best adaptation of proven engineering management
methods (PERT chart, experience data);
3. liberal doses of common sense;
4. God given humility to recognize our fallibility and limitations
Survey of Software Engineering (CS 5391) 2003
7/17/2015
32
Summary
• Causes for the project delay:
Optimism, faulty notion of man-month, lack of
experience data, underestimate of system testing in
project scheduling.
• Solutions:
Be realistic, count communication overhead when
partitioning a job, use experience data, leave suffice
time for testing, resolve the role conflicts, use the
proven schedule control methods (e.g. PERT Chart,
CPM)
• Now you should know what’s in your manager’s
mind. If not, read this article again.
Survey of Software Engineering (CS 5391) 2003
7/17/2015
33