These pages: The Mythical Man-Month
| Category: | index pages:
|
The Mythical Man-Month
Essays on Software Engineering Copyright © 1975 by Addison-Wesley Publishing Company, Inc.
| ||
---|---|---|
1 The Tar Pit | ||
No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits. In the minds eye one sees dinosaurs, mammoths, and sabertoothed tigers struggling against the grip of the tar. The fiercer the struggle, the more entangling the tar, and no beast is so strong or so skillful but that he ultimately sinks. Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. Most have emerged with running systemsfew have met goals, schedules, and budgets. Large and small, massive or wiry, team after team has become entangled in the tar. No one thing seems to cause the difficultyany particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. | ||
The Joys of the Craft | ||
Why is programming fun? What delights may its practitioner expect as his reward? First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of Gods delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake. Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the childs first clay pencil holder for Daddys office. Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate. Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both. Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. | Topic: | |
The Woes of the Craft | ||
One rarely controls the circumstances of his work, or even its goal. In management terms, ones authority is not sufficient for his responsibility. It seems that in all fields, however, the jobs where things get done never have formal authority commensurate with responsibility. In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment. | ||
2 The Mythical Man-Month | ||
Optimism | ||
Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages: the idea, the implementation, and the interaction. A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author. It is realized in time and space, by pen, ink, and paper, or by wire, silicon, and ferrite. The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker. [...] For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, working out are essential disciplines for the theoretician. | ||
The programmer builds form pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified. In a single task, the assumption that all will go well has a probabilistic effect on the schedule. It might indeed go as planned, for there is a probability distribution for the delay that will be encountered, and no delay has a finite probability. A large programming effort, however, consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small. | ||
The Man-Month | ||
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. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them [...] When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging. 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. [...] The added burden of communication is made up of two parts, training and intercommunication. [...] This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers. Intercommunication is worse. If each part of the task must be separately coordinated with each other part, the effort increases as | ||
Systems Test | ||
Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore, testing is usually the most mis-scheduled part of programming. | Topic: | |
In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing. Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. | ||
Gutless Estimating | ||
An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choiceswait or eat it raw. Software customers have had the same two choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can saveburned in one part, raw in another. | ||
Regenerative Schedule Disaster | ||
Oversimplifying outrageously, we state Brookss Law: Adding manpower to a late software project makes it later. This then is the demythologizing of the man-month. 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. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men and fewer months. | Compare to: | |
3 The Surgical Team | ||
The Problem | ||
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? | ||
Millss Proposal | ||
A proposal by Harlan Mills offers a fresh and creative solution. Mills proposes that each segment of a large job be tackled by a team, 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. Note (Hals): end note | ||
4 Aristocracy, Democracy, and System Design | ||
Conceptual Integrity | ||
Most European cathedrals show differences in plan or architectural styles between parts built in different generations by different builders. The later builders were tempted to improve upon the designs of the earlier ones, to reflect both changes in fashion and differences in individual taste. So the peaceful Norman transept abuts and contradicts the soaring Gothic nave, and the result proclaims the pridefulness of the builders as much as the glory of God. Against these, the architectural unity of Rheims stands in glorious contrast. The joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. As the guidebook tells, this integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design. The result proclaims not only the glory of God, but also His power to salvage fallen men from their pride. | Topic: | |
Achieving Conceptual Integrity | ||
Ease of use is enhanced only if the time gained in functional specification exceeds the time lost in learning, remembering, and searching manuals. [...] Because ease of use is the purpose, this ratio of function to conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design. | ||
Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity. | ||
Aristocracy and Democracy | ||
By the architecture of a system, I mean the complete and detailed specification of the user interface. [...] For the entire system it is the union of the manuals the user must consult to do his entire job. The architect of a system, like the architect of a building, is the users agent. | ||
There are many examples from other arts and crafts that lead one to believe that discipline is good for art. Indeed, an artists aphorism asserts, Form is liberating. The worst buildings are those whose budget was too great for the purposes to be served. Bachs creative output hardly seems to have been squelched by the necessity of producing a limited-form cantata each week. | ||
5 The Second-System Effect | ||
Self-DisciplineThe Second-System Effect | ||
An architects first work is apt to be spare and clean. He knows he doesnt know what hes doing, so he does it carefully and with great restraint. As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used next time. 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. | ||
Consider the linkage editor, designed to load separately-compiled programs and resolve their cross-references. Beyond this basic function it also handles program overlays. It is one of the finest overlay facilities ever built. [...] In a sense it is the culmination of years of development of static overlay technique. Yet it is also the last and finest of the dinosaurs, for it belongs to a system in which multiprogramming is the normal mode and dynamic core allocation the basic assumption. This is in direct conflict with the notion of using static overlays. | ||
text checked (see note) Nov 2007 |
Background graphic copyright © 2003 by Hal Keen