1. The Mythical Man-Month the MYTH behind the REAL
Prashant Kashyap

2. Man-Month?
man
month

3. Man-Month?
man X
month = man-month

4. Common wisdom 1 worker takes 6 days to clean 40 rooms at JNTU
A scenario
1 worker takes 6 days to clean 40 rooms at JNTU
2 workers take ? days to clean 40 rooms
3 workers take ? days to clean 40 rooms
This means
1x6 = 2x3 = 3x2 = 6 worker-days
are required to clean 40 rooms.

5. Obvious derivations
We may think that if workers are of same quality (which is often true) then it is possible to
Divide the work among many workers and get the work done faster
Correctly estimate the size of the job based on worker-days.
It implies that worker and days
are interchangeable

6. Software Projects
More software projects have gone awry for lack of calendar time than for all other causes combined. WHY?
Poorly developed estimating techniques and untrue assumption.
Estimating techniques fallaciously confuse effort with progress, hiding the assumption that “man and months are interchangeable.”
Software managers lack the stubbornness required to make people wait for good product.
Schedule progress is poorly monitored. The natural (traditional) response is to add manpower when schedule slippage is recognized. This makes things worse.

7. Software Projects Other Aspects of the Problem
False assumption: Optimism
Fallacious thought: Man-Month

8. False Assumption: Optimism
“All will go well.” i.e.. Each task will take only as long as it “ought” to take.
Too many optimistic programmers believe it.
WHY…

9. False Assumption: Optimism
3 stages creative activity
Idea
Constructed outside time and and space but complete in the mind
Implementation
Realized in time and space by medium
Interaction
Completed when someone interacts with the realized idea, thereby interacting with the maker’s mind.
Eg. Writing a story:
(1) The author thinks of a plot
(2) writes on paper with ink;
(3) readers read the story and interact with the author’s creativity.

10. False Assumption: Optimism
During the Implementation Phase of
a non-software project
The incompleteness and inconsistencies of ideas become clear during implementation.
Physical limitations of the medium constrain the ideas that may be expressed and create unexpected difficulties in the implementation.
In many creative activities the medium is intractable.

11. False Assumption: Optimism
During the Implementation Phase of
Software project .
The medium is tractable.
Programmer builds from concept and flexible representations.
Thus, Optimism is unjustified.

12. Fallacious Thought: Man-Month
In Estimating and Scheduling .
Cost increases with the increase in man-months
Cost = number of men x number of months x salary
Progress may not depend on it
Progress = number of men x number of months (in some cases)
Progress != number of men x number of months (for software projects)
Hence, the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth.
more about the mythical man-month…

13. Fallacious Thought: Man-Month
Different Tasks and their nature
CASE 1 – Partition able task
Task = (number of men) x (number of months)
Man and months are interchangeable only when a task can be partitioned among many workers with no communications among them.
Example: cleaning rooms, reaping wheat.

14. Fallacious Thought: Man-Month
Different Tasks and their nature
CASE 2 – Un-Partition able task
Task = fixed number of months
When a task cannot be partitioned because of sequential constraints, more effort has no effect on the schedule. .
Example: bearing a baby
The bearing of a child takes nine months, no matter how many women are assigned.

15. Fallacious Thought: Man-Month
Different Tasks and their nature
CASE 3 – Partition able task requiring communication
Task = (number of men) x (number of months) + (communication effort)
Tasks that can be partitioned but which require communication among
the subtasks, the effort of communication must be added to the amount
of work to be done.

16. Fallacious Thought: Man-Month
Software projects are sequential in nature.
They generally consist of several steps that must be completed one after another
These steps cannot be worked on at the same time. (un-partition able)
There is a minimum time that a project should take and it can not be reduced further by employing more people to work on that. Software projects have different stages and these stages usually depend on each other and hence, it is not possible to have more people finishing it in a short time.

17. Fallacious Thought: Man-Month
Throwing more people at a software project has no real effect upon the date of project completion. In fact, the overheads,
training
preserving “conceptual integrity”
communication paths
may delay the project further.
“Adding manpower to a late project makes it later.”
Why?
The work and disruption or repartitioning jobs
The time consumed training new people
The added intercommunication between people
There is a [n(n-1) / 2] increase in effort
Adding manpower to a late project makes it later because the intercommunication is required. Added to it, all the members of a group should have the basic understanding of the problem and the proposed solution. This training consumes a lot of time if people are added at a later stage.

18. Fallacious Thought: Man-Month
2 people, 1 channel
3 people, 3 channels
4 people, 6 channels
5 people, 10 channels
N=n(n-1) 2
Communication Paths
As the number of people increase the complexity of inter communication increases.
20 PEOPLE, 190 CHANNELS!

19. The Mythical Man Month
In a perfectly partitionable task (each task can be done independently), as the number of men increase the number of months decrease. Even it is not perfectly linear. After a certain limit it is not possible to reduce the months required to do the job.
In unpartitionable job (each task depends on the other), it is not possible to do it faster.
If communication is required then after a certain number of people, the number of months stops to fall down.
In complex interrelationship, after a certain number of people, the complexity increases so much so that the number of months required increases. An example can be system program which is already 60% done and all the modules are interlinked. Adding more programmers will complicate it further. (refer to previous slides)

20. System Tests
Component debugging and system test are thoroughly affected by sequential constrains.
The time required depends on the number and subtlety of the errors encountered.
Theoretically, this number should be zero (expectation/optimism).
Because of optimism, we usually expect the number of bugs smaller than it turns out to be.
In a perfectly partitionable task (each task can be done independently), as the number of men increase the number of months decrease. Even it is not perfectly linear. After a certain limit it is not possible to reduce the months required to do the job.
In unpartitionable job (each task depends on the other), it is not possible to do it faster.
If communication is required then after a certain number of people, the number of months stops to fall down.
In complex interrelationship, after a certain number of people, the complexity increases so much so that the number of months required increases. An example can be system program which is already 60% done and all the modules are interlinked. Adding more programmers will complicate it further. (refer to previous slides)

21. System Tests Failure to allow enough time for system test
Unsettle customers and managers
Delay comes at the end of schedule, bad news also comes at the almost delivery date.
Project is fully staffed and cost-per-day is maximum
Secondary cost very high
(shipping of computers, operation of new facilities, etc.)
In a perfectly partitionable task (each task can be done independently), as the number of men increase the number of months decrease. Even it is not perfectly linear. After a certain limit it is not possible to reduce the months required to do the job.
In unpartitionable job (each task depends on the other), it is not possible to do it faster.
If communication is required then after a certain number of people, the number of months stops to fall down.
In complex interrelationship, after a certain number of people, the complexity increases so much so that the number of months required increases. An example can be system program which is already 60% done and all the modules are interlinked. Adding more programmers will complicate it further. (refer to previous slides)

22. Building a Software System
Distinctive Issues
Quality of workers – Are they same?
Conceptual Integrity – Building the right system?
Communication – How to communicate?
Estimation – What should be the criteria?
Milestones – How to define?
Debugging – Major part of the job?
In a perfectly partitionable task (each task can be done independently), as the number of men increase the number of months decrease. Even it is not perfectly linear. After a certain limit it is not possible to reduce the months required to do the job.
In unpartitionable job (each task depends on the other), it is not possible to do it faster.
If communication is required then after a certain number of people, the number of months stops to fall down.
In complex interrelationship, after a certain number of people, the complexity increases so much so that the number of months required increases. An example can be system program which is already 60% done and all the modules are interlinked. Adding more programmers will complicate it further. (refer to previous slides)

23. Surgical Team Problem:
There is an order of magnitude difference between good programmers and bad programmers.
More people working on a project = more miscommunication between those people
Smaller groups are better, but a small group is too slow to create a large system in a reasonable amount of time.
For small projects we can have a surgical team model for programming too.

24. Surgical Team Solution: Mills’ Proposal:
Break up the programming teams into smaller sub-groups, with only one or two people doing actual coding. Everyone else in the team acts as support for these people. Thus, only a limited number of minds need to coordinate ideas, which reduces communications problems.
Solution:
Miller proposed that there can be sub-groups, which are small, working on a small to medium project. Only a few do the programming while others think and contribute in other ways like documentation, technical help etc.

25. Surgical Team the pilot documentation the know-it-all guy
This is a graphical representation of a surgical team.
The main programmer can be the surgeon.
Editors do documentation, administration supervise (like project manager).
Copilots are the helpers in programming. Language lawyer is an authority in a particular programming language. Tester tests the codes. Tool-smith manages to get libraries and other required resources. Programming clerk keep track of all programming procedures.
documentation
the know-it-all guy

26. Aristocracy, Democracy, and System Design
Conceptual Integrity is the most important consideration in system design
“It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.
Features Vs. Simplicity
Where they balance is when ease of use is optimum.
Conceptual Integrity leads to a good design and a good design leads to a better model and better model leads to a better system. This better system will make the process repeatable by providing a template for future job.

27. Aristocracy, Democracy, and System Design
Architect
“If a system is to have conceptual integrity, someone has to control the concepts.”
The architects are to become the aristocrats from whom all design decisions originate.
The implementers are then the peasants, soldiers, builders, and thinkers that support the aristocrat’s ideas.
Where architecture tells what is to happen, while implementation tells how it is to happen.
On architect maintains the conceptual integrity and knows what exactly is to be done. Implementers just build the system based on his guidelines. This will preserve the conceptual design and the actual design will be as close as possible to the thought-of design.
Implementers

28. The Second-system Effect
When a programmer works on a large system for the first time, he generally keeps things simple and to the point.
Radical ideas, features, or innovative implementations he would like to try are filed away for later use.
When a programmer works on his second large system, these files come out of storage with a vengeance.
Great care must be taken to insure that the system design is adhered to by all team members.
Second system effect is one of the major factors in software development delays. One learns from experience that over-enthusiasm and over-optimism leads to a messed up system.

29. The Fall of Babel
… “…let us build ourselves a city with a tower whose top shall reach the heavens…”… then the Lord came down... said “Come, let us go down, and there make such a babble of their language that they will not understand one another’s speech.”
And thus the Tower of Babel was
left incomplete.
Communication is the most important aspect of a work done in a group.

30. The Fall of Babel
When people lost the ability to communicate with one another, they could no longer work together to complete the Tower of Babel.
Likewise, when communication is lost to a software development team, the project they are working is doomed as well.
Combative measures
Informal / telephone service
Regularly scheduled meetings
Project Workbook
Communication should be very clear and effective. The measure taken to maintain good communication could be recording communications for future reference.

31. Calling the Shot Programming effort is a function of program size.
Naturally, the larger and more complex the program, the longer it takes to complete
However, this relationship is not linear. It’s an exponential growth function.
Effort = (constant) x (number of instructions) 1.5
The effort put in to write a program is non-linearly related to the size. After a certain size, the complexity also increases (to keep it coherent) and it takes more effort to code it but it more lines of code will surely mean more effort.

32. Calling the Shot Man-months Thousands of machine instructions
incomplete
Man-months
This figure shows the relation between effort and the program size.
Sudden rise in the actual work curve (red line) shows how the effort grows exponentially with the program size.
Thousands of machine instructions

33. Hatching a Catastrophe
Schedules are important to keep
Give the team 100% certifiable milestones
Clearly define what needs to be done
Pay attention to schedule slipping
Small slips can quickly compound into major project tardiness
Under the employee rug
There are always manager-boss conflicts
Minimize the conflict between you and your managers
But occasionally, yank the rug out from under them
Stick to schedules. Milestones should be well defined and must be reached on time.

34. The Whole and the Parts Design the bugs out of the system
Bug-proof the definition
Use structured programming
Component debugging
Test cases
System debugging
Use debugged components
Scaffolding
Control changes
Add one component at a time
The parts make up the whole component. All the parts of a system must conform to the standards you set for the entire system. All parts must be tested individually.

35. Man-Month: A Scenario Scenario:
Suppose a task is estimated at 12 man-months and is assigned to 3 men for 4 months.
There are measurable mileposts A, B, C, D which are scheduled at the end of each month.
Now suppose the first milepost is not reached until two months have passed.
For small projects we can have a surgical team model for programming too.

36. Man-Month: A Scenario Alternative 1:
Assume that the task must be done on time.
Assume that only the first part of the task was misestimated.
9 man-months of effort and 2 month remain.
So, 9/2 = 4.5 men will be needed.
Add 2 men to the 3 assigned.
For small projects we can have a surgical team model for programming too.

37. Man-Month: A Scenario Alternative 2:
Assume that the task must be done on time.
Assume that the whole estimate was uniformly low.
We have 18 man-months of effort and 2 months remain.
So, 18/2 = 9 men will be needed.
Add 6 men to the 3 assigned.
For small projects we can have a surgical team model for programming too.

38. Man-Month: A Scenario Reschedule Allow enough time in the new schedule
Alternative 3:
Reschedule
Allow enough time in the new schedule
To ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.
For small projects we can have a surgical team model for programming too.

39. Man-Month: A Scenario Trim the job Alternative 4:
This tends to happen in practice.
The manager’s only alternatives are to trim it formally and carefully, to reschedule, or to watch the task get silently trimmed by hasty design and incomplete testing.
For small projects we can have a surgical team model for programming too.

40. Demythologizing Man-Month
For the first alternative.
The 2 new men will require training in the task by one of the experienced men. If it takes 1 month, then 3 man-months not in the original estimate will be added.
9 [remain effort] +3 [added burden] – 5 [5 men effort for 3rd month] = 7 [man-month remain]
Similarly, the project will be even further delayed for the alternative 2
For small projects we can have a surgical team model for programming too.

41. Demythologizing Man-Month
The number of months of a project depends upon its sequential constrains.
The maximum number of men depends upon the number of independent subtasks.
From the above two quantities
Can derive schedule using fewer men and more months.
Cannot get workable schedule using more men and fewer months.
For small projects we can have a surgical team model for programming too.

42. Conclusion
The tar pit of software engineering will continue to be sticky for a long time to come.
Software systems are the most intricate and complex of man’s handiworks.
The management will demand our best use of new language and systems, our best use of engineering management methods, liberal doses of common sense, and humility to recognize our fallibility and limitations.
Design is easy; managing development is not.
For small projects we can have a surgical team model for programming too.

43. Future IBM, Microsoft get the best programmer from the world.
What hope is there for the organizations left with the average talent?
Management, metrics and methodologies will become even more important to the software development process than individual programmers. Optimizing the development system may prove more useful than optimizing the development individuals.
For small projects we can have a surgical team model for programming too.

44. References
The Mythical Man Month – Fredrick P. Brook’s Jr., Pearson Education Asia Publishers.
Software Engineering – A practitioner’s Approach by Roger S. Pressman
Software Project Management (Lecture)- Peking University, Fall Semester, 2001
No Silver Bullet : Essence and Accident in Software Engineering by Prof. Fred Brooks, IEEE Computer, April 1987
Frederick P. Brooks Jr. The Mythical Man-Month. Addison-Wesley, 1995
Brad Cox, No Silver Bullet Revisited,
Information on Fred Brooks,
Ed Yourdon, Managing Projects to Produce "Good Enough" Software,
These books, sites, papers were consulted to make this presentation.