mythical man-month

Mythical Man-Month

Presentation by: Steven Braverman

What is the Mythical Man-Month?

What is the Mythical Man-Month?

Book written by Fred Brooks – Published in 1975

What is the Mythical Man-Month?

Book written by Fred Brooks – Published in 1975

Essays about software engineering and project management

What is the Mythical Man-Month?

Book written by Fred Brooks – Published in 1975

Essays about software engineering and project management

Still relevant today?

The Man-Month?

The Man-Month

Man Month – A unit for measuring the size of a job.

The Man-Month

Man Month – A unit for measuring the size of a job. Dangerous and deceptive myth.

The Man-Month

Man Month – A unit for measuring the size of a job. Dangerous and deceptive myth. Implies men and months are

interchangeable

The Man-Month

Interchangeable if the task(s):

The Man-Month

Interchangeable if the task(s): Can be partitioned among many

workers

The Man-Month

Interchangeable if the task(s): Can be partitioned among many

workers Requires no communication between

the workers

Project Failures

Project Failures

Calendar time – The major cause of project mishaps.

Project Failures

Calendar time – The major cause of project mishaps. Methods of estimation are poorly developed

Project Failures

Calendar time – The major cause of project mishaps. Methods of estimation are poorly developed

Estimation techniques confuse effort with progress

Project Failures

Calendar time – The major cause of project mishaps. Methods of estimation are poorly developed

Estimation techniques confuse effort with progress

Software managers lack courteous stubbornness due to uncertainty in estimates

Project Failures

Calendar time – The major cause of project mishaps. Methods of estimation are poorly developed

Estimation techniques confuse effort with progress

Software managers lack courteous stubbornness due to uncertainty in estimates

Schedule progress is poorly monitored.

Project Failures

Calendar time – The major cause of project mishaps. Methods of estimation are poorly developed

Estimation techniques confuse effort with progress

Software managers lack courteous stubbornness due to uncertainty in estimates

Schedule progress is poorly monitored.

Manpower is added when schedule slippage is recognized

Systems Test

Systems Testing

Testing is the most mis-scheduled part of programming

Systems Testing

Testing is the most mis-scheduled part of programming– Optimism allows us to expect less bugs than will actually

turn up.

Systems Testing

Testing is the most mis-scheduled part of programming– Optimism allows us to expect less bugs than will actually

turn up.

– Failing to give enough time for testing allows for failure to come at the end

Gutless Estimation

False Scheduling to match a patron's desired date is common in software engineering discipline but is rarely seen elsewhere in engineering

Gutless Estimation

False Scheduling to match a patron's desired date is common in software engineering discipline but is rarely seen elsewhere in engineering

1/3 Planning

1/6 Programming

1/4 Component test

1/4 System Test

Hatching a Catastrophe Disastrous schedule slippage is usually

caused by termites, not tornadoes.

Hatching a Catastrophe Disastrous schedule slippage is usually

caused by termites, not tornadoes.

–Communication is key

Hatching a Catastrophe Disastrous schedule slippage is usually

caused by termites, not tornadoes.

–Communication is key

–System down time, sickness, high-priority short, unrelated jobs, meetings, paperwork,

Silver Bullet

Silver Bullet– There is no silver bullet on the horizon

to improve in orders of magnitude productivity, reliability, or simplicity

Silver Bullet– There is no silver bullet on the horizon

to improve in orders of magnitude productivity, reliability, or simplicity

– The hard part of building software is specification, design and testing the conceptual construct, not the labor

Silver Bullet– There is no silver bullet on the horizon

to improve in orders of magnitude productivity, reliability, or simplicity

– The hard part of building software is specification, design and testing the conceptual construct, not the labor• Complexity - no two parts are the same. If two things do similar

things, they are merged

Silver Bullet– There is no silver bullet on the horizon

to improve in orders of magnitude productivity, reliability, or simplicity

– The hard part of building software is specification, design and testing the conceptual construct, not the labor• Complexity - no two parts are the same. If two things do similar

things, they are merged

• Changeability - Code can be easily malleable and updated unlike cars/building

Silver Bullet– There is no silver bullet on the horizon

to improve in orders of magnitude productivity, reliability, or simplicity

– The hard part of building software is specification, design and testing the conceptual construct, not the labor• Complexity - no two parts are the same. If two things do similar

things, they are merged

• Changeability - Code can be easily malleable and updated unlike cars/building

• Invisibility - reality of software is not inherently embedded in space - severs communication between mind

Silver Bullet Continued

Silver Bullet Continued The cost of software is development not

of replication

Silver Bullet Continued The cost of software is development not

of replication The hardest single part of building a

software system is deciding precisely what to build

Silver Bullet Continued The cost of software is development not

of replication The hardest single part of building a

software system is deciding precisely what to build

Clients themselves do not know what they want. requirements need to be constantly updated and reiterated meetings

Conceptual Integrity

Conceptual Integrity Conceptual integrity is the most

important consideration in system design

Conceptual Integrity Conceptual integrity is the most

important consideration in system design

– System should reflect one set of design ideas

Conceptual Integrity Conceptual integrity is the most

important consideration in system design

– System should reflect one set of design ideas – Ease of use is enhanced when time gained in

functional specification exceeds time lost in learning, remembering, and searching manuals.

Conceptual Integrity Conceptual integrity is the most

important consideration in system design

– System should reflect one set of design ideas – Ease of use is enhanced when time gained in

functional specification exceeds time lost in learning, remembering, and searching manuals.

– Ratio of function to conceptual complexity is the ultimate test of system design.

Aristocracy and Democracy

Aristocracy and Democracy Group that decides the architecture Group that works on the

implementation

Aristocracy and Democracy Group that decides the architecture Group that works on the

implementation

–Creativity exists in both

Aristocracy and Democracy Group that decides the architecture Group that works on the

implementation

–Creativity exists in both

– Form can be liberating

Aristocracy and Democracy When a small architecture team writes

all external specifications for a computer programming system, implementers raise three concerns

Aristocracy and Democracy When a small architecture team writes

all external specifications for a computer programming system, implementers raise three concerns– Specifications will be too rich in function and fail to

reflect practical cost consideration

Aristocracy and Democracy When a small architecture team writes

all external specifications for a computer programming system, implementers raise three concerns– Specifications will be too rich in function and fail to

reflect practical cost consideration – Architects will take all the creative fun and shut out the

inventiveness of the implementors

Aristocracy and Democracy When a small architecture team writes

all external specifications for a computer programming system, implementers raise three concerns– Specifications will be too rich in function and fail to

reflect practical cost consideration – Architects will take all the creative fun and shut out the

inventiveness of the implementors

– Implementors will sit around waiting while architects come up with the specifications

Aristocracy and Democracy– Specifications will be too rich in function and fail to reflect

practical cost consideration – Architects will take all the creative fun and shut out the

inventiveness of the implementors

– Implementors will sit around waiting while architects come up with the specifications

Aristocracy and Democracy– Specifications will be too rich in function and fail to reflect

practical cost consideration – Architects will take all the creative fun and shut out the

inventiveness of the implementors

– Implementors will sit around waiting while architects come up with the specifications

Aristocracy and Democracy– Specifications will be too rich in function and fail to reflect

practical cost consideration – Architects will take all the creative fun and shut out the

inventiveness of the implementors

– Implementors will sit around waiting while architects come up with the specifications

Total Creative effort:

– Architecture

– Implementation

– Realization