mythical man-month

Download Mythical Man-Month

Post on 15-Jan-2015

45 views

Category:

Technology

0 download

Embed Size (px)

DESCRIPTION

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

TRANSCRIPT

  • 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

View more