The Mythical Man-MonthThe Mythical Man-Month

By: Zac LippardBy: Zac Lippard

CS 470CS 470

What is the “Man-Month”?What is the “Man-Month”?

• This is the idea that men and months are This is the idea that men and months are interchangeable between each other.interchangeable between each other.– More men, less months; more months, less More men, less months; more months, less

men.men.

• It is a myth in computer programming It is a myth in computer programming industry.industry.

• This only works in a situation where there This only works in a situation where there is no communication between among the is no communication between among the workers.workers.

History Behind the “Man-History Behind the “Man-Month”Month”

• Many companies thrive by this Many companies thrive by this theory.theory.

• Managers worry about time Managers worry about time constraints that they naively add constraints that they naively add more people to make up for lost more people to make up for lost time.time.

OptimismOptimism

• 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 Implementation of code is thought to be more simplified after programmers be more simplified after programmers write the code. write the code.

• Optimism is the reason many Optimism is the reason many managers conform to the Man-Month managers conform to the Man-Month theory.theory.

Man-Month Theory: Man-Month Theory: Plausible in a non-Plausible in a non-communicating departmentcommunicating department

Sequential Constraints: No Sequential Constraints: No partitioningpartitioning

Complex Interrelationships: Complex Interrelationships: Communication projectsCommunication projects

Systems TestsSystems Tests

• System tests are thought to be System tests are thought to be completed fairly quick based upon completed fairly quick based upon the optimism of the programmer.the optimism of the programmer.

• There are usually more bugs in the There are usually more bugs in the code than anticipated. code than anticipated.

Brooks Schedule for Brooks Schedule for Software TasksSoftware Tasks

• 1/3 Planning1/3 Planning

• 1/6 Coding1/6 Coding

• ¼ Component test and early system ¼ Component test and early system testtest

• ¼ System test, all components in ¼ System test, all components in handhand

Brooks Schedule of Brooks Schedule of Software TasksSoftware Tasks

• Planning is the most important stage Planning is the most important stage and the most devoted part.and the most devoted part.

• Debugging takes about ½ of the Debugging takes about ½ of the schedule than the norm.schedule than the norm.

• The easiest part, the coding, is given The easiest part, the coding, is given the least amount of time.the least amount of time.

Schedule and DelaysSchedule and Delays

• Most companies do not schedule at Most companies do not schedule at least half of their time to testing, but least half of their time to testing, but end up doing so any way.end up doing so any way.

• The delays don’t come until the The delays don’t come until the debugging process and this is where debugging process and this is where failure and disaster occurs.failure and disaster occurs.

Estimating and Scheduling Estimating and Scheduling Disaster!Disaster!

• Programmers and managers estimate Programmers and managers estimate the time it takes to get a project done.the time it takes to get a project done.

• The biggest problem is that The biggest problem is that overestimation of program performance overestimation of program performance and underestimation of software bugs and underestimation of software bugs aren’t taken into consideration.aren’t taken into consideration.

• Two solutions are needed…Two solutions are needed…

How To Solve This DilemmaHow To Solve This Dilemma

• 1: A need to develop and publicize 1: A need to develop and publicize productivity figures, bug-incidence productivity figures, bug-incidence figures, estimating rules, etc.figures, estimating rules, etc.

• 2: Defend these estimates.2: Defend these estimates.

Examples of the Man-Month Examples of the Man-Month FallacyFallacy

ConclusionConclusion

• Brooks’s Law:Brooks’s Law:Adding manpower to a late software Adding manpower to a late software

project makes it later.project makes it later.

• Men cannot be interchanged with Men cannot be interchanged with time!time!