View
79
Download
0
Category
Tags:
Preview:
DESCRIPTION
Presentation on some key concepts from the book, The Mythical Man-Month
Citation preview
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
Recommended