resolving loba kahayang: 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)