the mythical man-month the myth behind the real prashant kashyap
TRANSCRIPT
The Mythical Man-Month the MYTH behind the REAL
Prashant Kashyap
man month
Man-Month?
man X month = man-month
Man-Month?
Common wisdom
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.
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
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.
Software Projects
Other Aspects of the Problem
False assumption: Optimism
Fallacious thought: Man-Month
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…
False Assumption: Optimism
3 stages creative activity
IdeaConstructed outside time and and space but complete in the mind
ImplementationRealized in time and space by medium
InteractionCompleted 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.
False Assumption: Optimism
During the Implementation Phase ofa non-software projectThe 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.
False Assumption: Optimism
During the Implementation Phase ofSoftware project
.
The medium is tractable.
Programmer builds from concept and flexible representations.
Thus, Optimism is unjustified.
Fallacious Thought: Man-Month
In Estimating and Scheduling.
Cost increases with the increase in man-monthsCost = number of men x number of months x salary
Progress may not depend on itProgress = 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…
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.Partitionable Task
Men
Mo
nth
s
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 Unpartitionable Task
Men
Mo
nth
sThe bearing of a child takes nine months, no matter how many women are assigned.
Fallacious Thought: Man-Month
Different Tasks and their nature
CASE 3 – Partition able task requiring communicationTask = (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. Communication Required
Men
Mo
nth
s
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)
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 pathsmay 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
Fallacious Thought: Man-Month
20 PEOPLE, 190 CHANNELS!
2 people, 1 channel
3 people, 3 channels
4 people, 6 channels 5 people, 10 channels
N=n(n-1) 2
Communication Paths
Fallacious Thought: Man-Month
The Mythical Man Month
Partitionable Task
Men
Mo
nth
s
Unpartitionable Task
Men
Mo
nth
s
Communication Required
Men
Mo
nth
s
Complex Interrelationships
Men
Mo
nth
s
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.
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.)
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?
Surgical Team
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.
Problem:Problem:
Surgical Team
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:Solution:
Surgical Team
Surgeon
Administrator Editor Copilot
Secretary Secretary Programming Clerk
Tester
Tool-smith
Language Lawyer
supervisor
the pilot
documentation
the know-it-all guy
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.
Aristocracy, Democracy, and System Design
“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.
Architect
Implementers
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.
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.
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 email / telephone service Regularly scheduled meetings Project Workbook
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
Calling the Shot
0
1000
2000
3000
4000
5000
6000
7000
8000
0 100 200 300 400 500 600 700
extrapolated
Actual data
LinearlyextrapolatedActual workcurve
Thousands of machine instructions
Man
-mon
ths
incomplete
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
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
Man-Month: A 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.
Scenario:Scenario:
Man-Month: A Scenario
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.
Alternative 1:Alternative 1:
Man-Month: A Scenario
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.
Alternative 2:Alternative 2:
Man-Month: A Scenario
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.
Alternative 3:Alternative 3:
Man-Month: A Scenario
Trim the job 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.
Alternative 4:Alternative 4:
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
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.
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.
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.
References
1. The Mythical Man Month – Fredrick P. Brook’s Jr., Pearson Education Asia Publishers.
2. Software Engineering – A practitioner’s Approach by Roger S. Pressman
3. Software Project Management (Lecture)- Peking University, Fall Semester, 2001
4. No Silver Bullet : Essence and Accident in Software Engineering by Prof. Fred Brooks, IEEE Computer, April 1987
5. Frederick P. Brooks Jr. The Mythical Man-Month. Addison-Wesley, 1995
6. Brad Cox, No Silver Bullet Revisited, http://www.virtualschool.edu/cox/AmProTTEF.html
7. Information on Fred Brooks, http://www.cs.unc.edu/Events/News/TuringAward.html
8. Ed Yourdon, Managing Projects to Produce "Good Enough" Software, http://www.yourdon.com/articles/9503ieee.html