The Mythical Man-Month

1. The Mythical Man-Month

3. Frederick P. Brooks, Jr. Kenan Professor of Computer ScienceDepartment of Computer Science University of North CarolinaChapel Hill, N.C. 27599-3175brooks@cs.unc.eduPhone: (919) 962-1931Fax: (919) 962-1799

4. A few facts about him: • Degree: • Ph.D from Harvard University (1956) • Award and medals: • ACM Turing award winner (1999) • John von Neumann Medal, IEEE (1993) • Too many to list here … • Industry experience: • IBM Corporation: • System/360: Manager of whole project, 1961-64

5. A few facts about the book: • Classic book on software project management • Published in 1975 and republished in 1995 • Tar pit • The mythical man-month • No silver bullet (added in 1995)

6. Some invaluable insights from the book • The Mythical Man-Month: Question: If you are a project manager and your project running behind schedule, what do you think about assigning more programmers to the project? Answer: Assigning more programmers to a project running behind schedule, could actually make it even later.

7. Progress Tracking: Question: How does a large software project get to be one year late? Answer: One day at a time! Continued attention to meeting small individual milestones is required at each level of management.

8. Conceptual Integrity: In order to make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation.

9. The Pilot System: When designing a new kind of system, a team will design a throw-away system (whether it likes it or not).

10. Communication: In order to avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible.

11. Software is invisible. • Many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. • This experience will yield insights, which will change a user's needs or the perception of the user's needs. • The system will therefore need to be changed in order to fulfill the changed requirements of the user.

12. The Tar Pit

13. Large system programming has been a tar pit • Many great and powerful beasts have thrashed violently in it • No one thing cause the difficulty. It is the accumulation of simultaneous and interacting factors. To resolve the problem, one must try to understand the nature of programming.

14. Joys of Programming • Making things in his/her own design • Making things that are useful to other people • Fashioning complex object and watch them work together • Learning • Working in such a tractable medium but moves things.

15. Programming is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

16. Woes of Programming • One must perform perfectly • Our work depends on others • Designing grand concepts is fun, finding bugs is just work • Debugging has a linear convergence or worse. • Must work on actual schedules and resources.

17. What is programming? • A tar bit in which many efforts have floundered • A creative activity with joys and woes For many, the joys far outweigh the woes, and try to lay some boardwalks across the tar.

18. No Silver BulletEssence and accident in Software Engineering

19. The nightmares of project manager. Software project Change from innocent/straightforward to missed schedules, blown budgets, and flawed products Silver bullet – NO!!! 

20. There is no single development in either technology or management technique, which by itself promise even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

21. Why NOT? Nature of software problem Properties of silver bullet

22. Nature of Software problem Essence The difficulties inherent in the nature of the software. Accident The difficulties that today attend its production but are not inherent

23. The hard part of building a software to be the specification, design, and testing of this conceptual construct, not the labour of representing it and testing the fidelity of the representation.

24. Essence Complexity No two parts alike. Very large number of states Nonlinear increase with size Conformity Arbitrary complexity – created by human factors

25. Changeability Functions are subject to change Can be changed easily Built to change Invisibility and unvisualizable Software is conceptual. No geometric representation of a software structure Difficulties in communicating minds

26. Progress made to solve accidental difficulties High-level languages Better hardware Programming environments Object-oriented programming

27. Skepticism is not pessimism. Although no startling breakthroughs A disciplined, consistent effort should yield an order-of-magnitude improvement

28. Promising attacks on the conceptual essence Buy versus build Requirements refinement and rapid prototyping (a vision for agile methodology??) Last but not least: good designers There is no royal road, but there is a road.

29. There is no royal road, but there is a road.

30. The Mythical Man-Month

31. Things that make projects fall behind schedule • Estimating techniques are poorly developed • assume things will go well • Schedule progress is poorly monitored • Confuse effort with progress • assume man and month are interchangeable • Managers lack the courage of the chef • When falling behind schedule, the nature thing to do is …

32. Optimism • All programmers are optimists. • Believe in happy endings & fairy godmothers • Only care about end results • are young “This time it will surely run” or “ I just found the last bug”

33. Creativity activity can be divided into: • The idea • The Implementation “The incompleteness and inconsistencies of idea become clear only during implementation”

34. The man-month • as a unit for measuring the size of a job is a dangerous and deceptive myth. • It implies that men and months are interchangeable.

35. Cost does vary as the product of the number of men and the number of months. Progress does not.

36. 时间 人数 Men-Months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.

37. 时间 人数 When a task can’t be partitioned because of sequential constrains, the application of more effort has no effect on the schedule.

38. 时间 人数 When a task can be partitioned but which require communication among the subtasks, the effort of communication (training and intercommunication) must be added to the amount of work to be done.

39. 时间 Complex interrelationships 人数 When a task can be partitioned but which require communication among the subtasks and within subtasks, the effort of communication may fully counteract the division of the original task.

40. Software construction is an exercise in complex interrelationship Communication effort is great Communication dominates the decrease in individual task time brought about by partitioning. Adding more men lengthens, not shortens, the schedule.

41. Adding more men lengthens, not shortens, the schedule.

42. Failure to allow enough time for system test is peculiarly disastrous: • Bad news come at the end • Cost is high

43. What does one do when software project is behind schedule? • Add more man power. • Reschedule. • Trim the task.

44. Key points to know • Essences of software • How does a large project get to be one year late? • Things that make projects fall behind schedule • Don’t confuse effort with progress • Cost varies with effort, not progress • What to do when project falls behind schedule?