1. The Mythical Man-Month By: Zac Lippard CS 470

2. What is the “Man-Month”? This is the idea that men and months are interchangeable between each other. This is the idea that men and months are interchangeable between each other. –More men, less months; more months, less men. It is a myth in computer programming industry. It is a myth in computer programming industry. This only works in a situation where there is no communication between among the workers. This only works in a situation where there is no communication between among the workers.

3. History Behind the “Man-Month” Many companies thrive by this theory. Many companies thrive by this theory. Managers worry about time constraints that they naively add more people to make up for lost time. Managers worry about time constraints that they naively add more people to make up for lost time.

4. Optimism Brooks calls programmers optimists. Brooks calls programmers optimists. Programmers look at the bright side. Programmers look at the bright side. Implementation of code is thought to be more simplified after programmers write the code. Implementation of code is thought to be more simplified after programmers write the code. Optimism is the reason many managers conform to the Man-Month theory. Optimism is the reason many managers conform to the Man-Month theory.

5. Man-Month Theory: Plausible in a non-communicating department

6. Sequential Constraints: No partitioning

7. Complex Interrelationships: Communication projects

8. Systems Tests System tests are thought to be completed fairly quick based upon the optimism of the programmer. System tests are thought to be completed fairly quick based upon the optimism of the programmer. There are usually more bugs in the code than anticipated. There are usually more bugs in the code than anticipated.

9. Brooks Schedule for Software Tasks 1/3 Planning 1/3 Planning 1/6 Coding 1/6 Coding ¼ Component test and early system test ¼ Component test and early system test ¼ System test, all components in hand ¼ System test, all components in hand

10. Brooks Schedule of Software Tasks Planning is the most important stage and the most devoted part. Planning is the most important stage and the most devoted part. Debugging takes about ½ of the schedule than the norm. Debugging takes about ½ of the schedule than the norm. The easiest part, the coding, is given the least amount of time. The easiest part, the coding, is given the least amount of time.

11. Schedule and Delays Most companies do not schedule at least half of their time to testing, but end up doing so any way. Most companies do not schedule at least half of their time to testing, but end up doing so any way. The delays don’t come until the debugging process and this is where failure and disaster occurs. The delays don’t come until the debugging process and this is where failure and disaster occurs.

12. Estimating and Scheduling Disaster! Programmers and managers estimate the time it takes to get a project done. Programmers and managers estimate the time it takes to get a project done. The biggest problem is that overestimation of program performance and underestimation of software bugs aren’t taken into consideration. The biggest problem is that overestimation of program performance and underestimation of software bugs aren’t taken into consideration. Two solutions are needed… Two solutions are needed…

13. How To Solve This Dilemma 1: A need to develop and publicize productivity figures, bug-incidence figures, estimating rules, etc. 1: A need to develop and publicize productivity figures, bug-incidence figures, estimating rules, etc. 2: Defend these estimates. 2: Defend these estimates.

14. Examples of the Man-Month Fallacy

15. Conclusion Brooks’s Law: Brooks’s Law: Adding manpower to a late software project makes it later. Men cannot be interchanged with time! Men cannot be interchanged with time!