Presentation on some key concepts from the book, The Mythical Man-Month

1. Mythical Man-Month
Presentation by: Steven Braverman

2. What is the Mythical Man-
Month?

3. What is the Mythical Man-
Month?
 Book written by Fred Brooks –
Published in 1975

4. What is the Mythical Man-
Month?
 Book written by Fred Brooks –
Published in 1975
 Essays about software engineering
and project management

5. What is the Mythical Man-
Month?
 Book written by Fred Brooks –
Published in 1975
 Essays about software engineering
and project management
 Still relevant today?

6. The Man-Month?

7. The Man-Month
 Man Month – A unit for measuring the
size of a job.

8. The Man-Month
 Man Month – A unit for measuring the
size of a job.
 Dangerous and deceptive myth.

9. The Man-Month
 Man Month – A unit for measuring the
size of a job.
 Dangerous and deceptive myth.
 Implies men and months are
interchangeable

10. The Man-Month
 Interchangeable if the task(s):

11. The Man-Month
 Interchangeable if the task(s):
 Can be partitioned among many
workers

12. The Man-Month
 Interchangeable if the task(s):
 Can be partitioned among many
workers
 Requires no communication between
the workers

13. Project Failures

14. Project Failures
 Calendar time – The major cause of
project mishaps.

15. Project Failures
 Calendar time – The major cause of
project mishaps.
 Methods of estimation are poorly developed

16. Project Failures
 Calendar time – The major cause of
project mishaps.
 Methods of estimation are poorly developed
 Estimation techniques confuse effort with progress

17. Project Failures
 Calendar time – The major cause of
project mishaps.
 Methods of estimation are poorly developed
 Estimation techniques confuse effort with progress
 Software managers lack courteous stubbornness due to
uncertainty in estimates

18. Project Failures
 Calendar time – The major cause of
project mishaps.
 Methods of estimation are poorly developed
 Estimation techniques confuse effort with progress
 Software managers lack courteous stubbornness due to
uncertainty in estimates
 Schedule progress is poorly monitored.

19. Project Failures
 Calendar time – The major cause of
project mishaps.
 Methods of estimation are poorly developed
 Estimation techniques confuse effort with progress
 Software managers lack courteous stubbornness due to
uncertainty in estimates
 Schedule progress is poorly monitored.
 Manpower is added when schedule slippage is
recognized

20. Systems Test

21. Systems Testing
 Testing is the most mis-scheduled part of
programming

22. Systems Testing
 Testing is the most mis-scheduled part of
programming
– Optimism allows us to expect less bugs than will actually
turn up.

23. Systems Testing
 Testing is the most mis-scheduled part of
programming
– Optimism allows us to expect less bugs than will actually
turn up.
– Failing to give enough time for testing allows for failure
to come at the end

24. Gutless Estimation
False Scheduling to match a patron's desired
date is common in software engineering
discipline but is rarely seen elsewhere in
engineering

25. Gutless Estimation
False Scheduling to match a patron's desired
date is common in software engineering
discipline but is rarely seen elsewhere in
engineering
1/3 Planning
1/6 Programming
1/4 Component test
1/4 System Test

26. Hatching a Catastrophe
 Disastrous schedule slippage is usually
caused by termites, not tornadoes.

27. Hatching a Catastrophe
 Disastrous schedule slippage is usually
caused by termites, not tornadoes.
– Communication is key

28. Hatching a Catastrophe
 Disastrous schedule slippage is usually
caused by termites, not tornadoes.
– Communication is key
– System down time, sickness, high-
priority short, unrelated jobs,
meetings, paperwork,

29. Silver Bullet

30. Silver Bullet
– There is no silver bullet on the horizon
to improve in orders of magnitude
productivity, reliability, or simplicity

31. Silver Bullet
– There is no silver bullet on the horizon
to improve in orders of magnitude
productivity, reliability, or simplicity
– The hard part of building software is
specification, design and testing the
conceptual construct, not the labor

32. Silver Bullet
– There is no silver bullet on the horizon
to improve in orders of magnitude
productivity, reliability, or simplicity
– The hard part of building software is
specification, design and testing the
conceptual construct, not the labor
• Complexity - no two parts are the same. If two things do similar
things, they are merged

33. Silver Bullet
– There is no silver bullet on the horizon
to improve in orders of magnitude
productivity, reliability, or simplicity
– The hard part of building software is
specification, design and testing the
conceptual construct, not the labor
• Complexity - no two parts are the same. If two things do similar
things, they are merged
• Changeability - Code can be easily malleable and updated
unlike cars/building

34. Silver Bullet
– There is no silver bullet on the horizon
to improve in orders of magnitude
productivity, reliability, or simplicity
– The hard part of building software is
specification, design and testing the
conceptual construct, not the labor
• Complexity - no two parts are the same. If two things do similar
things, they are merged
• Changeability - Code can be easily malleable and updated
unlike cars/building
• Invisibility - reality of software is not inherently embedded in
space - severs communication between mind

35. Silver Bullet Continued

36. Silver Bullet Continued
 The cost of software is development not
of replication

37. Silver Bullet Continued
 The cost of software is development not
of replication
 The hardest single part of building a
software system is deciding precisely
what to build

38. Silver Bullet Continued
 The cost of software is development not
of replication
 The hardest single part of building a
software system is deciding precisely
what to build
 Clients themselves do not know what
they want. requirements need to be
constantly updated and reiterated
meetings

39. Conceptual Integrity

40. Conceptual Integrity
 Conceptual integrity is the most
important consideration in system
design

41. Conceptual Integrity
 Conceptual integrity is the most
important consideration in system
design
– System should reflect one set of design ideas

42. Conceptual Integrity
 Conceptual integrity is the most
important consideration in system
design
– System should reflect one set of design ideas
– Ease of use is enhanced when time gained in
functional specification exceeds time lost in learning,
remembering, and searching manuals.

43. Conceptual Integrity
 Conceptual integrity is the most
important consideration in system
design
– System should reflect one set of design ideas
– Ease of use is enhanced when time gained in
functional specification exceeds time lost in learning,
remembering, and searching manuals.
– Ratio of function to conceptual complexity is the
ultimate test of system design.

44. Aristocracy and Democracy

45. Aristocracy and Democracy
 Group that decides the architecture
 Group that works on the implementation

46. Aristocracy and Democracy
 Group that decides the architecture
 Group that works on the implementation
– Creativity exists in both

47. Aristocracy and Democracy
 Group that decides the architecture
 Group that works on the implementation
– Creativity exists in both
– Form can be liberating

48. Aristocracy and Democracy
 When a small architecture team writes
all external specifications for a
computer programming system,
implementers raise three concerns

49. Aristocracy and Democracy
 When a small architecture team writes
all external specifications for a
computer programming system,
implementers raise three concerns
– Specifications will be too rich in function and fail to
reflect practical cost consideration

50. Aristocracy and Democracy
 When a small architecture team writes
all external specifications for a
computer programming system,
implementers raise three concerns
– Specifications will be too rich in function and fail to
reflect practical cost consideration
– Architects will take all the creative fun and shut out the
inventiveness of the implementors

51. Aristocracy and Democracy
 When a small architecture team writes
all external specifications for a
computer programming system,
implementers raise three concerns
– Specifications will be too rich in function and fail to
reflect practical cost consideration
– Architects will take all the creative fun and shut out the
inventiveness of the implementors
– Implementors will sit around waiting while architects
come up with the specifications

52. Aristocracy and Democracy
– Specifications will be too rich in function and fail to reflect
practical cost consideration
– Architects will take all the creative fun and shut out the
inventiveness of the implementors
– Implementors will sit around waiting while architects
come up with the specifications

53. Aristocracy and Democracy
– Specifications will be too rich in function and fail to reflect
practical cost consideration
– Architects will take all the creative fun and shut out the
inventiveness of the implementors
– Implementors will sit around waiting while architects
come up with the specifications

54. Aristocracy and Democracy
– Specifications will be too rich in function and fail to reflect
practical cost consideration
– Architects will take all the creative fun and shut out the
inventiveness of the implementors
– Implementors will sit around waiting while architects
come up with the specifications
 Total Creative effort:
– Architecture
– Implementation
– Realization