THE MYTHICAL MAN-MONTH

1
THE MYTHICAL MAN-MONTH
How does a project get to be a year late? one
day at a time?

• Xianling Feng

2
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.
• Youve got read it since your manager might have
  read it.

3
The issue -- Brooks answersSoftware projects
go awry for lack of calendar time. -- Why is
the disaster?

• Estimating Techniques are poorly developed--
  with assumption that all will go well. (optimism)
• Estimating Techniques confuses the effort with
  progress (measurement)-- with assumption that
  men and months are interchangeable
• Lack of "courteous stubbornness" to make people
  want a good product
• -- because of being uncertain of the
  estimates
• Schedule progress is poorly monitored.
• When schedule slippage is recognized
• --gt Natural (traditional) response is to add
  manpower
• --gt dousing a fire with gasoline

4
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.

5
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 workerswith
  no communication among them.

6
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

7
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. This may be true of
picking cottons. (where no communication is
needed among workers)
8
2. The Mythical Man-month (for software
project)

• For software project, communication effort is
  great, adding more men lengthens schedule due to
  the added communication overhead.

9
2. The Mythical Man-month (Communication effort)
communication efforts n(n-1)/2
10
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 (33 )1/6 coding (17
  )1/4 component test (25 )1/4 system test
  (25 )
• Please note that half of the time is to be spent
  on testing.

11
2. More accurate estimation -- Gutless
estimating

• Estimation is based on the customers urgency
• -- another cause of faulty scheduling
• To solve the problem-- develop and publicize
  productivity figures, bug-incidence
  figures-- estimating rules

12
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.
• Lets take an example to see why.

13
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?

14
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)
• --gt need 3 milestones 3 man-month/milestone
• 9 man-month
• (9 man-month / 2 month) 4.5 men --gt add 2 men
  !

15
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)
• --gt need 3 milestones 6 man-month/milestone
  18 man-month
• ( 18 man-month / 2 month ) 9 men --gt add 6 men

16
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).

17
3. Adding manpower to shorten the schedule --
Regenerative Disaster

• Solution 1 revisited at the end of 3rd
  month
• 1 experienced man trains 2 inexperienced --gt 3
  man-months used
• Repartition the task from 3 parts to 5 parts --gt
  totally 9 3 12 man-months
• At the end of 3rd month, 9 - 31 repartition (
  work lost, more system testing)gt 7 man-months
  task remains
• 7 man-months task to be finished by 5 experienced
  men --gt 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.

18
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".
19
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.CausesMachine
  downtime, short unrelated jobs, meetings,
  paperwork, company business, sickness, personal
  time, etc accounted the rest.

20
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-ye
arSome interactions 5,000 Many interactions
1,500System testing, support are not counted
here.
21
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
22
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.
23
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 ratiosNormal batch application
1Compiler
3Operating System 9
24
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
  preventSickness of a key man -- meeting
  canceledMachines all down -- lightning struck
  the power transformerDisc not testingSnow,Jury
  dutyFamily problems,Emergency meentigs with
  customersExecutive audits(the list goes on
  and on )

25
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.
26
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.

27
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//searchsystemsmanagemen
  t.techtarget.com/sDefinition/0,,sid20_gci331391,00
  .html

28
6. Control a project on tight schedule --
What is a PERT chart?
Example of a PERT Chart from http//searchsystemsm
anagement.techtarget.com/sDefinition/0,,sid20_gci3
31391,00.html
29
6. Control a project on tight schedule --
Under the rug The manager may not want
his/her boss know whats 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?
• Reduce the role conflict with the first-line
  manager so to encourage the sharing of the
  status.
• Yank the rug off

30
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.

31
6. Control a project on tight schedule --
Yank the rug off

• Form a Plans and Controls team using PERT
  chart to periodically update thestatus and
  reveal the delayed subtask and so the first line
  manager's task is reduced to the essentials --
  making decisions to act to catch upthe schedule.

32
Epilogue Brooks suggestions

• The management of the software development
• (very complex craft) demands
• our best use of new languages and systems
• best adaptation of proven engineering management
  methods (PERT chart, experience data)
• liberal doses of common sense
• God given humility to recognize our fallibility
  and limitations

33
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 whats in your managers
  mind. If not, read this article again.