the mythical man-month the myth behind the real prashant kashyap

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…


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.


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.


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…


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



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.



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)


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


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


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:


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:


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.



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.



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.


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

the mythical man-month the myth behind the real prashant kashyap

Documents