Skimming : The Mythical Man-Month
The Mythical Man-Month
The Tar Pit
- Human beings are not accustomed to being perfect, and few areas
of human activity demand it. Adjusting to the requirement for
perfection is, I think, the most difficult part of learning to program.
(p.8)
- The last woe, and sometimes the last straw, is that the product
over which one has labored so long appears to be obsolete upon (or
before) completion. Already colleagues and competitors are in hot
pursuit of new and better ideas. (p.9)
The Mythical Man Month
- our estimating techniques fallaciously confuse effort with
progress, hiding the assumption that men and months are
interchangeable. (p.14)
- All programmers are optimists. (p.14)
- Cost does indeed vary as the product of the number of 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. (p.16)
- Men and months are interchangeable commodities only when a task
can be partitioned among many workers with no communication among them
(p.16)
- In 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. (p.17)
- For some years I have been successfully using the following rule
of thumb for scheduling a software task:
- l/3 planning
- 1/6 coding
- 1/4 component test and early system test
- 1/4 system test, all components in hand. (p.20)
- Until estimating is on a sounder basis, individual managers will
need to stiffen their backbones and defend their estimates with the
assurance that their poor hunches are better than wish derived
estimates. (p.21)
- Adding manpower to a late software project makes it later. (p.25)
- The number of months of a project depends upon its sequential
constraints. The maximum number of men depends upon the number of
independent subtasks. From these two quantities one can derive
schedules using fewer men and more months. (p.25)
The Surgical Team
- Within just this group the ratios between best and worst
performances averaged about 10:1 on productivity measurements and an
amazing 5:1 on program speed and space measurements! (p.30)
- The dilemma is a cruel one. For efficiency and conceptual
integrity, one prefers a few good minds doing design and construction.
Yet for large systems one wants a way to bring considerable manpower to
bear, so that the product can make a timely appearance. How can these
two needs be reconciled? (p.31)
- ... but that the team be organized like a surgical team rather
than a hog-butchering team. That is, instead of each member cutting
away on the problem, one does the cutting and the others give him every
support that will enhance his effectiveness and productivity. (p.32)
- The surgeon. Mills calls him a chief programmer. He personally
defines the functional and performance specifications, designs the
program, codes it, tests it, and writes its documentation. (p.32)
- The copilot. He is the alter ego of the surgeon, able to do any
part of the job, but is less experienced. (p.32)
- The administrator. The surgeon is boss, and he must have the last
word on personnel, raises, space, and so on, but he must spend almost
none of his time on these matters. (p.33)
- The editor. The surgeon is responsible for generating the
documentation—for maximum clarity he must write it. This is true of
both external and internal descriptions. The editor, however, takes the
draft or dictated manuscript produced by the surgeon and criticizes it,
reworks it, provides it with references and bibliography, nurses it
through several versions, and oversees the mechanics of production.
(p.33)
- The program clerk. He is responsible for maintaining all the
technical records of the team in a programming-product library. (p.33)
- The toolsmith. ... He needs a toolsmith, responsible for ensuring
this adequacy of the basic service and for constructing, maintaining,
and upgrading special tools—mostly interactive computer services—needed
by his team. (p.34)
- The tester. The surgeon will need a bank of suitable test cases
for testing pieces of his work as he writes it, and then for testing
the whole thing. (p.34)
- The language lawyer. The language lawyer can find a neat and
efficient way to use the language to do difficult, obscure, or tricky
things. (p.34)
- ... lack of division of the problem and the superior-subordinate
relationship—make it possible for the surgical team to act uno animo. Yet the specialization
of function of the remainder of the team is the key to its efficiency,
(p.35)
Aristocracy, Democracy, and
System Design
- The purpose of a programming system is to make a computer easy to
use. (p.43)
- For a given level of function, however, that system is best in
which one can specify things with the most simplicity and
straightforwardness. Simplicity is not enough. ... Simplicity and
straightforwardness proceed from conceptual integrity. (p.44)
- Conceptual integrity in turn dictates that the design must
proceed from one mind, or from a very small number of agreeing resonant
minds. (p.44)
- The separation of architectural effort from implementation is a
very powerful way of getting conceptual integrity on very large
projects. (p.44)
- Are not the architects a new aristocracy, an intellectual elite,
set up to tell the poor dumb implementers what to do? (p.46)
- Good features and ideas that do not integrate with a system's
basic concepts are best left out. ... If a system is to have conceptual
integrity, someone must control the concepts. That is an aristocracy
that needs no apology. (p.46)
- Indeed, the cost-performance ratio of the product will depend
most heavily on the implementer, just as ease of use depends most
heavily on the architect. (p.46)
The Second-System Effect
- An architect's first work is apt to be spare and clean. He knows
he doesn't know what he's doing, so he does it carefully and with great
restraint. (p.55)
- Sooner or later the first system is finished, and the architect,
with firm, confidence and a demonstrated mastery of that class of
systems, is ready to build a second system. This second is the most
dangerous system a man ever designs. (p.55)
- How does the architect avoid the second-system effect? Well,
obviously he can't skip his second system. But he can be conscious of
the peculiar hazards of that system, and exert extra self-discipline to
avoid functional ornamentation and to avoid extrapolation of functions
that are obviated by changes in assumptions and purposes. (p.58)
Passing the Word
- The manual is the external specification of the product. It
describes and prescribes every detail of what the user sees. As such,
it is the chief product of the architect. (p.62)
- The manual must not only describe everything the user does see,
including all interfaces; it must also refrain from describing what the
user does not see. That is the implementer's business, and there his
design freedom must be unconstrained. (p.62)
- As noted, formal definitions are precise. They tend to be
complete; gaps show more conspicuously, so they are filled sooner. What
they lack is comprehensibility. (p.63)
- For these reasons, I think we will see future specifications to
consist of both a formal definition and a prose definition. (p.64)
- An ancient adage warns, "Never go to sea with two chronometers;
take one or three." The same thing clearly applies to prose and formal
definitions. If one has both, one must be the standard, and the other
must be a derivative description, clearly labeled as such. (p.64)
- Needless to say, meetings are necessary. ... Anyone can propose
problems or changes, but proposals are usually distributed in writing
before the meeting. (p.66)
- In most computer projects there comes a day when it is discovered
that the machine and the manual don't agree. When the confrontation
follows, the manual usually loses, for it can be changed far more
quickly and cheaply than the machine. Not so, however, when there are
multiple implementations. Then the delays and costs associated with
fixing the errant machine can be overmatched by delays and costs in
revising the machines that followed the manual faithfully. (p.68)
- It is essential, however, to encourage the puzzled implementer to
telephone the responsible architect and ask his question, rather than
to guess and proceed. ... One useful mechanism is a telephone log kept
by the architect. In it he records every question and every
answer. (p.69)
- Every development organization needs such an independent
technical auditing group to keep it honest. (p.69)
Why Did the Tower of Babel Fail?
- According to the Genesis account, the tower of Babel was man's
second major engineering undertaking, after Noah's ark. Babel was the
first engineering fiasco. (p.74)
- If there are n workers on a project, there are (n2-n)/2
interfaces across which there may be communication, and there are
potentially almost 2" teams within which coordination must occur. The
purpose of organization is to reduce the amount of communication and
coordination necessary; hence organization is a radical attack
- on the communication problems treated above. (p.78)
- Let us consider a tree-like programming organization, and examine
the essentials which any subtree must have in order to be effective.
They are:
- a mission
- a producer
- a technical director or architect
- a schedule
- a division of labor
- interface definitions among the parts
(p.79)
- What is the role of the producer? He assembles the team, divides
the work, and establishes the schedule. He acquires and keeps on
acquiring the necessary resources. This means that a major part of his
role is communication outside the team, upwards and sideways. (p.79)
- How about the technical director? He conceives of the design to
be built, identifies its subparts, specifies how it will look from
outside, and sketches its internal structure. He provides unity and
conceptual integrity to the whole design; thus he serves as a limit on
system complexity. (p.80)
Calling the Shot
- First, one must say that one does not estimate the entire task by
estimating the coding portion only and then applying the ratios. The
coding is only one-sixth or so of the problem, and errors in its
estimate or in the ratios could lead to ridiculous'results. (p.88)
- effort goes as a power of size even when no communication is
involved except that of a man with his memories. (p.88)
- Productivity seems constant in tenns of elementary statements, a
conclusion that is reasonable in terms of the thought a statement
requires and the errors it may include."
- Programming productivity may be increased as much as five times
when a suitable high-level language is used. (p.94)
Ten Pounds in a Five-Pound Sack
- Fostering a total-system, user-oriented attitude may well be the
most important function of the programming manager. (p.100)
- Obviously, more function means more space, speed being held
constant. So the first area of craftsmanship is in trading function for
size. (p.101)
- The second area of craftsmanship is space-time trade-offs. For a
given function, the more space, the faster. This is true over an
amazingly large range. It is this fact that makes it feasible to set
space budgets. (p.101)
- The programmer at wit's end for lack of space can often do best
by disentangling himself from his code, rearing back, and contemplating
his data. Representation is the essence of programming. (p.103)
The Documentary Hypothesis
- The act of writing turns out to require hundreds of
mini-decisions, and it is the existence of these that distinguishes
clear, exact policies from fuzzy ones (p.111)
- the documents will communicate the decisions to others. The
manager will be continually amazed that policies he took for common
knowledge are totally unknown by some member of his team. Since his
fundamental job is to keep everybody going in the same direction, his
chief daily task will be communication, not decision-making, and his
documents will immensely lighten this load. (p.111)
- The task of the manager is to develop a plan and then to realize
it. But only the written plan is precise and communicable. Such a plan
consists of documents on what, when, how much, where, and who.
(p.112)
Plan to Throw One Away
- In most projects, the first system built is barely usable. It may
be too slow, too big, awkward to use, or all three. There is no
alternative but to start again, smarting but smarter, and build a
redesigned version in which these problems are solved. (p.116)
- The management question, therefore, is not whether to build a
pilot system and throw it away. You will do that. The only question is
whether to plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers. (p.116)
- The first step is to accept the fact of change as a way of life,
rather than an untoward and annoying exception. (p.117)
- Quantization of change is an essential technique. Every product
should have numbered versions, and each version must have its own
schedule and a freeze date, after which changes go into the next
version. (p.118)
- He observes that the reluctance to document designs is not due
merely to laziness or time pressure. Instead it comes from the
designer's reluctance to commit himself to the defense of decisions
which he knows to be tentative. (p.118)
- The barriers are sociological, and they must be fought with
constant vigilance. First, managers themselves often think of senior
people as "too valuable" to use for actual programming. (p.119)
- The fundamental problem with program maintenance is that fixing a
defect has a substantial (20-50 percent) chance of introducing another.
So the whole process is two steps forward and one step back. (p.122)
- They find that the total number of modules increases linearly
with release number, but that the number of modules affected increases
exponentially with release number. All repairs tend to destroy the
structure, to increase the entropy and disorder of the system. (p.122)
Sharp Tools
- General-purpose tools are not enough, however. Both specialized
needs and personal preferences dictate the need for specialized tools
as well; so in discussing programming teams I have postulated one
toolmaker per team. (p.128)
- When a man had his component ready for integration into a larger
piece, he passed a copy over to the manager of that larger system, who
put this copy into a system integration sublibrary. Now the original
programmer could not change it, except by permission of the integration
manager. (p.133)
- The chief reasons for using a high-level language are
productivity and debugging speed. (p.135)
- The debugging improvement comes from the fact that there are
fewer bugs, and they are easier to find. There are fewer because one
avoids an entire level of exposure to error, a level on which one makes
not only syntactic errors but semantic ones, such as misusing
registers. (p.135)
- What high-level language should one use for system programming?
The only reasonable candidate today is PL/I. (p.135)
The Whole and the Parts
- conceptual integrity of the product not only makes it easier to
use, it also makes it easier to build and less subject to bugs. (p.142)
- Many poor systems come from an attempt to salvage a bad basic
design and patch it with all kinds of cosmetic relief. Top-down design
reduces the temptation. I am persuaded that top-down design is the most important new
programming formalization of the decade. (p.144)
- Common sense, if not common practice, dictates that one should
begin system debugging only after the pieces seem to work. (p.147)
- the use of clean, debugged components saves much more time in
system testing than that spent on scaffolding and thorough component
test. (p.148)
- By scaffolding I mean all programs and data built for debugging
purposes but never intended to be in the final product. It is not
unreasonable for there to be half as much code in scaffolding as there is in product. (p.148)
- Note that one must have thorough test cases, testing the partial
systems after each new piece is added. And the old ones, run
successfully on the last partial sum, must be rerun on the new one to
test for system regression. (p.150)
Hatching a Catastrophe
- Coding, for a counterexample, is "90 percent finished" for half
of the total coding time. Debugging is "99 percent complete" most of
the time. "Planning complete" is an event one can proclaim almost at will. (p.154)
- Rarely will a man lie about milestone progress, if the milestone
is so sharp that he can't deceive himself. But if the milestone is
fuzzy, the boss often understands a different report from that which
the man gives. (p.155)
- There is no substitute for a PERT chart or a critical-path
schedule. Such a network shows who waits for what. It shows who is on
the critical path, where any slip moves the end date. It also shows how much an activity can slip
before it moves into the critical path. (p.156)
- The boss must first distinguish between action information and
status information. He must discipline himself not to act on problems
his managers can solve, and never to act on problems when he is explicitly reviewing status.
(p.157)
- The investment of a modest amount of skilled effort in a Plans
and Controls function is very rewarding. ... For the Plans and Controls
group is the watchdog who renders the imperceptible delays visible and
who points up the critical elements. It is the early warning system
against losing a year, one day at a time. (p.160)
The Other Face
- Thomas J. Watson, Sr. told the story of his first experience as a
cash register salesman in upstate New York. Charged with enthusiasm, he
sallied out with his wagon loaded with cash registers. He worked his
territory diligently but without selling a one. Downcast, he reported
to his boss. The sales manager listened a while, then said, "Help me
load some registers into the wagon, harness the horse, and let's go
again." They did, and the two called on customer after customer, with
the older man showing how to
sell cash registers. All evidence indicates that the lesson took.
(p.164)
- To use a program. Every user needs a prose description of the
program. Most documentation fails in giving too little overview. The
trees are described, the bark and leaves are commented, but there is no
map of the forest. (p.165)
- To believe a program. The description of how it is used must be
supplemented with some description of how one knows it is working. This
means test cases. (p.165)
- The solution, I think, is to merge the files, to incorporate the
documentation in the source program. This is at once a powerful
incentive toward proper maintenance, and an insurance that the
documentation will always be handy to the program user. Such programs
are called self-documenting. (p.169)
- The first notion is to use the parts of the program that have to
be there anyway, for programming language reasons, to carry as much of
the documentation as possible. So labels, declaration statements, and
symbolic names are all harnessed to the task of conveying as much
meaning as possible to the reader. (p.172)
No Silver Bullet - Essence and Accident in Software Engineering
- Not only are there no silver bullets now in view, the very nature
of software makes it unlikely that there will be any—no inventions that
will do for software productivity, reliability, and simplicity what
electronics, transistors, and large-scale integration did for computer
hardware. (p.181)
- Following Aristotle, I divide them into essence—the difficulties
inherent in the nature of the software—and accidents—those difficulties
that today attend its production but that are not inherent. (p.182)
- The complexity of software is an essential property, not an
accidental one. Hence descriptions of a software entity that abstract
away its complexity often abstract away its essence. (p.183)
- Einstein repeatedly argued that there must be simplified
explanations of nature, because God is not capricious or arbitrary. No
such faith comforts the software engineer. ... These differ from
interface to interface, and from time to time, not because of necessity
but only because they were designed by different people, rather than by
God. (p.184)
- What does a high-level language accomplish? It frees a program
from much of its accidental complexity. (p.186)
- The concept of the abstract data type is that an object's type
should be defined by a name, a set of proper values, and a set of
proper operations, rather than its storage structure, which should be
hidden. (p.189)
- The hard thing about building software is deciding what to
say, not saying it. (p.191)
- For almost 40 years, people have been anticipating and writing
about "automatic programming," the generation of a program for solving
a problem from a statement of the problem specifications. (p.193)
- The VLSI analogy is fundamentally misleading—a chip design is a
layered two-dimensional object whose geometry reflects its essence. A
software system is not. (p.195)
- Language-specific smart editors are developments not yet widely
used in practice, but the most they promise is freedom from syntactic
errors and simple semantic errors. (p.196)
- Buy versus build. The most radical possible solution for
constructing software is not to construct it at all. (p.197)
- The cost of software has always been development cost, not
replication cost. (p.198)
- During the 1950s and 1960s, study after study showed that users
would not use off-the-shelf packages for payroll, inventory control,
accounts receivable, etc. ... During the 1980s, we find such packages
in high demand and widespread use. What has changed? (p.198)
- The buyer of a $2-million machine in 1960 felt that he could
afford $250,000 more for a customized payroll program, Buyers of
$50,000 office machines today cannot conceivably afford customized
payroll programs; so they adapt their payroll procedures to the
packages available. (p.198)
- Therefore the most important function that software builders do
for their clients is the iterative extraction and refinement of the
product requirements. For the truth is, the clients do not know what
they want. (p.199)
- Therefore one of the most promising of the current technological
efforts, and one which attacks the essence, not the accidents, of the
software problem, is the development of approaches and tools for rapid
prototyping of systems as part of the iterative specification of
requirements. (p.200)
- The secret is that it is grown, not built. So it must be with our
software systems. Some years ago Harlan Mills proposed that any
software system should be grown by incremental development (p.201)
- I find that teams can grow much more complex entities in four
months than they can build. (p.201)
- The central question of how to improve the software art centers,
as it always has, on people. ... Great designs come from great
designers. Software construction is a creative
process. Sound methodology can empower and liberate the creative mind;
it cannot enflame or inspire the drudge. (p.202)
- My first proposal is that each software organization must
determine and proclaim that great designers are as important to its
success as great managers are, and that they can be expected to be
similarly nurtured and rewarded. (p.203)
- How to grow great designers? Space does not permit a lengthy
discussion, but some steps are obvious:
- Systematically identify top designers as early as possible. The
best are often not the most experienced.
- Assign a career mentor to be responsible for the development of
the prospect, and keep a careful career file.
- Devise and maintain a career development plan for each
prospect, including carefully selected apprenticeships with top
designers, episodes of advanced formal education, and short courses,
all interspersed with solo design and technical leadership assignments.
- Provide opportunities for growing designers to interact with
and stimulate each other.
(p.203)
The Mythical Man-Month after 20 Years
- Human history is a drama in which the stories stay the same, the
scripts of those stories change slowly with evolving cultures, and the
stage settings change all the time. (p.255)
- A clean, elegant programming product must present to each of its
users a coherent mental model of the application, of strategies for
doing the application, and of the user-interface tactics to be used in
specifying actions and parameters. The conceptual integrity of the
product, as perceived by the user, is the most important factor in ease
of use. (p.255)
- Any product that is sufficiently big or urgent to require the
effort of many minds thus encounters a peculiar difficulty: the result
must be conceptually coherent to the single mind of the user and at the
same time designed by many minds. (p.256)
- Conceptual integrity is central to product quality. Having a
system architect is the most important single step toward conceptual
integrity. (p.257)
- Paradoxically, it is much more difficult to design a general
purpose tool than it is to design a special-purpose tool, precisely
because one has to assign weights to the differing needs of the diverse
users. (p.258)
- The larger and more amorphous the user set, the more necessary it
is to define it explicitly if one is to achieve conceptual integrity.
- Who they are
- What they need
- What they think they need
- What they want
(p.258)
- The WIMP is a superb example of a user interface that has
conceptual integrity, achieved by the adoption of a familiar mental
model, the desktop metaphor, and its careful consistent extension to
exploit a computer graphics implementation. (p.260)
- "Plan to throw one away; you will, anyhow." This I now perceive
to be wrong, not because it is too radical, but because it is too
simplistic. The biggest mistake in the "Build one to throw away"
concept is that it implicitly assumes the classical sequential or
waterfall model of software construction. (p.265)
- Rather less familiar, but very important, is Parnas's concept of
designing a software product as a family of related products. He urges
the designer to anticipate both lateral extensions and succeeding
versions of a product, and to define their function or platform
differences so as to construct a family tree of related products. The
trick in the design of such a tree is to put near its root those design
decisions that are less likely to change. (p.269)
- Parnas was right, and I was wrong. I am now convinced that
information hiding, today often embodied in object-oriented
programming, is the only way of raising the level of software design.
(p.272)
- that creativity comes from individuals and not from structures or
processes, then a central question facing the software manager is how
to design structure and process so as to enhance, rather than inhibit,
creativity and initiative. (p.277)
- The classical industry tended to be dominated by large firms with
established management styles and work cultures. The shrink-wrapped
industry, on the other hand, began as hundreds of start-ups,
freewheeling and fiercely focused on getting the job done rather than
on process. (p.284)
- An especially promising trend is the use of mass-market packages
as the platforms on which richer and more customized products are
built. (p.285)
- Because the build-on-package phenomenon does not today affect the
average MIS programmer, it is not yet very visible to the software
engineering discipline. Nevertheless, it will grow rapidly, because it
does attack the essence of fashioning conceptual constructs. (p.285)
No comments:
Post a Comment