Transcript Document

The Mythical Man Month
Essays on Software Engineering
An Overview
Presented by
Prashant Kashyap
FREDERICK P. BROOKS, JR
Btech 2000
The tar pit

The Good


The Bad


Joys of programming
Woes of programming
The Ugly

Systems integration is a
punch in the face
System programming has been
such a tar pit – very Sticky !
The Mythical Man Month

What is the man-month?



Cost varies as the product of the number
men and the number of months
Progress does not
Hence the man-month as a unit for
measuring the size of a job is a
dangerous and deceptive myth

It implies that men and months are
interchangeable
The Mythical Man Month

“The bearing of a child takes nine months,
no matter how many women are assigned”
 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-partitionable)
The Mythical 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
The Mythical Man Month
Communication Paths
2 people, 1
channel
3 people, 3 channels
4 people, 6 channels
N=n(n-1)
2
5 people, 10 channels
20 PEOPLE, 190 CHANNELS!
The Mythical Man Month
Unpartitionable Task
Months
Months
Partitionable Task
Men
Communication Required
Complex Interrelationships
Months
Months
Men
Men
Men
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.
Surgical Team
Solution:
 Miller’s 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.
Surgical Team
the pilot
supervisor
Surgeon
Administrator
Secretary
Editor
Secretary
Copilot
Programming Clerk
Tool-smith
documentation
Tester
Language Lawyer
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.”



Architect
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.
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.
Passing the Word

Manuals

External specifications of the product (Product Manual)


Internal specifications of the product (System Manual)


Describes every technical detail about the system that may
be used by the implementers.
Meetings



Describes everything the user sees, and nothing that he
doesn’t see
Weekly half-day conferences
Annual or semi-annual “Supreme Court” meetings
Email logs
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)
Calling the Shot
8000
incomplete
7000
extrapolated
Man-months
6000
Actual data
5000
4000
3000
Linearly
extrapolated
Actual work
curve
2000
1000
0
0
100 200 300 400
500 600 700
Thousands of machine instructions
Ten Pounds in a Five Pound
Sack




Program space (memory) is a cost
Thus size control is important
Two methods to control size: space control
and data representation
Space techniques



Trading function for size
Space - time tradeoffs (CPU power)
Representation techniques

Efficient data representation (objects, data
structures)
The Documentary Hypothesis

Reasons for having formal documents



Recording decisions
Communicating those decisions
Data base / checklist (programmer
directives)
Plan to Throw One Away


"The throwaway is the
acceptance of the fact that as one
learns, he changes the design."
Pilot plants - upscale from small
to large


Modern approach: 'alpha' and 'beta'
testing
Plan your system for change

Modern approaches:


pre release: code base /
configuration managers (e.g.:
SourceSafe)
post release: patching systems
Collapse of the aerodynamically
misdesigned Tacoma Narrows Bridge
1940
Sharp Tools


“A good craftsman is known by his tools.”
The tools of a programmer are:

Target machines


Vehicle machines


The programmer’s work environment
Data services


The final testing environment
Compiler, assembler, libraries, debugging tools
HLL & interactive programming

Language and programming tool of choice (e.g.: Java
and JBuilder)
Hatching a Catastrophe


Schedules are important to keep
Give the team 100% certifiable milestones


Pay attention to schedule slipping


Clearly define what needs to be done
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 Other Face


Documentation is important to the user, as
well
What kinds of documentation do they need?





How to use the product
How the product works
How to adapt the product to their needs
Flowcharts are flawed: they can be easily
represented with code comments
Self-documenting programs

Merge source code and documentation (wellcommented code)
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
Exhaustive Testing. Really?

Simple loop,
executing ≤ 20
times


1014 possible paths
at 1 ms per test,
would take 3170
years
loop Š 20 times
No Silver Bullet- Essence and
Accident in Software Engineering
“There is no single development, in either technology
or management technique, which by itself promises
even one order of magnitude improvement in
productivity in reliability, in simplicity.” - Fred
Brooks


“... building software will always be hard” due to
difficulties in its intrinsic nature (essence);
however, improved process can solve difficulties
which surround software production and are not
part of its nature (accidents)
No Silver Bullet:
Difficulties in Essence of Software

complexity: due to
interaction of
components, number
of possible states
grows much faster
than lines of code.
No Silver Bullet:
Difficulties in Essence of Software

changeability:
must model changing
real world, increase
functionality, run on
new hardware.
No Silver Bullet:
Difficulties in Essence of Software

conformity: must
interface with existing
systems.
No Silver Bullet:
Difficulties in Essence of Software

invisibility: cannot
visualize all aspects at
once.
No Silver Bullet: Breakthroughs
for improving the Accidents






software development
environments
use of “off the shelf”
software and components
rapid prototyping
incremental development
training, encouraging
great designers
aspects at once.
Some Methods for Dealing
with Essential Difficulties

Complexity





Changeability and Conformity



Abstract models
Breakdown of system into
manageable modules
Breakdown of development
process into phases, tasks, and
subtasks
Team programming
Change management
Configuration management
Invisibility

use of multiple models, for many
views of system
No Silver Bullet: Refired

What is accidental?

Intent


Misunderstanding


accidental: incidental or appurtenant
accidental: occurring by chance,
“Shrinking the accidental part to zero will
not give an order of magnitude
productivity improvement.”
No Silver Bullet: Refired
Complexity
 Not all complexity is inevitable
 “… Yesterday’s complexity is tomorrow’s order.”
 There are no general rules to avoid complexity
 Complexity is by levels


Complexity in software construct is due to
implementation rather than conformity to the external
world.
Solution


Hierarchically, by layered modules or objects
Incrementally, so that the system always works
No Silver Bullet: Refired

Harel’s “Gloom” themes

“Sharp separation into essence and accident”

“Treatment of each silver bullet candidate in
isolation”

“Predicting for only 10 years, instead of a
long enough time in which ‘to expect any
significant improvement’”
No Silver Bullet: Refired

Productivity Follows Quality




“Focus on quality, and productivity will follow.” - Jones’s view
“… productivity drops again as one pursues extreme
quality…” - Boehm’s view
“… systematic software development disciplines were
developed in response to quality concerns … rather than
productivity concerns.” - Coqui’s view
What has happened to productivity?



Measuring productivity is difficult
Shrink-wrapped software - Buy; don’t build
Tools improve productivity

cheap, powerful tools that are easy to use
No Silver Bullet: Refired

What about REUSE?


Don’t build software.
Aims



Programmer level - 30%
Corporate level
- 75%
How does corporate-level reuse fare today?
- Jones


Large companies have reuse research
Small companies don’t
“Reuse is something that is far easier to say than to do.” - Parnas
No Silver Bullet: Refired
CONCLUSION
 Complexity


Productivity


Cannot do away with completely
Focus on Quality and it will lead to
productivity
Reuse

Don’t reinvent the wheel
The Mythical Man-Month after
20 Years

We, the programmers, pledge not to
ask the presenter of this presentation
about this! We UNDERSTAND where it
stands.

Game for a Discussion? (not me )
References
1.
2.
3.
4.
5.
6.
7.
8.
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. AddisonWesley, 1995
Brad Cox, No Silver Bullet Revisited,
http://www.virtualschool.edu/cox/AmProTTEF.html
Information on Fred Brooks,
http://www.cs.unc.edu/Events/News/TuringAward.html
Ed Yourdon, Managing Projects to Produce "Good Enough"
Software, http://www.yourdon.com/articles/9503ieee.html