1 / 33

THE MYTHICAL MAN-MONTH

THE MYTHICAL MAN-MONTH. How does a project get to be a year late? …… one day at a time?. Xianling Feng. 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,

benjamin
Télécharger la présentation

THE MYTHICAL MAN-MONTH

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. You’ve got read it since your manager might have read it. Survey of Software Engineering (CS 5391) 2003

  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 --> Natural (traditional) response is to add manpower --> dousing a fire with gasoline Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

  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 Survey of Software Engineering (CS 5391) 2003

  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) Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

  9. 2. The Mythical Man-month (Communication effort) communication efforts = n(n-1)/2 Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

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

  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. Let’s take an example to see why. Survey of Software Engineering (CS 5391) 2003

  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? Survey of Software Engineering (CS 5391) 2003

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

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

  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). Survey of Software Engineering (CS 5391) 2003

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

  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". Survey of Software Engineering (CS 5391) 2003

  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.Causes:Machine downtime, short unrelated jobs, meetings, paperwork, company business, sickness, personal time, etc accounted the rest. Survey of Software Engineering (CS 5391) 2003

  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-yearSome interactions: 5,000 Many interactions 1,500System testing, support are not counted here. Survey of Software Engineering (CS 5391) 2003

  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 Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

  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 ratios:Normal batch application : 1Compiler : 3Operating System : 9 Survey of Software Engineering (CS 5391) 2003

  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 prevent:Sickness 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 …) Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

  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://searchsystemsmanagement.techtarget.com/sDefinition/0,,sid20_gci331391,00.html Survey of Software Engineering (CS 5391) 2003

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

  29. 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? • Reduce the role conflict with the first-line manager so to encourage the sharing of the status. • Yank the rug off Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

  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. Survey of Software Engineering (CS 5391) 2003

  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 Survey of Software Engineering (CS 5391) 2003

  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 what’s in your manager’s mind. If not, read this article again. Survey of Software Engineering (CS 5391) 2003

More Related