The Mythical Man-Month Quotes

Rate this book
Clear rating
The Mythical Man-Month: Essays on Software Engineering The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks Jr.
10,306 ratings, 4.05 average rating, 675 reviews
Open Preview
The Mythical Man-Month Quotes Showing 1-30 of 94
“As time passes, the system becomes less and less well-ordered. Sooner or later the fixing cease to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. ...A brand-new, from-the-ground-up redesign is necessary.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Adding manpower to a late software project, makes it later.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“A baseball manager recognizes a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. It is essential for great programming teams, too.”
Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering
“The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“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.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“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.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“A basic principle of data processing teaches the folly of trying to maintain independent files in synchonism.”
Frederick Phillips Brooks, The Mythical Man-Month: Essays on Software Engineering
“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 choices—wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save—burned in one part, raw in another.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Today I am more convinced than ever. Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity. These principles are by no means limited to software systems, but to the design of any complex construct, whether a computer, an airplane, a Strategic Defense Initiative, a Global Positioning System. After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager and a separate architect. Defining distinct roles in such small teams may be a little extreme, but I have observed it to work well and to contribute to design success even for small teams.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“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.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“...give a great deal of attention to keeping his managers and his technical people as interchangeable as their talents allow. The barriers are sociological... To overcome this problem some laboratories, such as Bell Labs, abolish all job titles. Each professional employee is a "member of technical staff.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“The challenge and the mission are to find real solutions to real problems on actual schedules with available resources.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Adding manpower to a late software project makes it later.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Conway's Law predicts: "Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations."[1] Conway goes on to point out that the organization chart will initially reflect the first system design, which is almost surely not the right one. If the system design is to be free to change, the organization must be prepared to change.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Years later, when I got to college, I learned about an important theory of psychology called Learned Helplessness, developed by Dr. Martin E. P. Seligman. This theory, backed up by years of research, is that a great deal of depression grows out of a feeling of helplessness: the feeling that you cannot control your environment.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“By documenting a design, the designer exposes himself to the criticisms of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“I do not believe we will find the magic here. Program verification is a very powerful concept, and it will be very important for such things as secure operating system kernels. The technology does not promise, however, to save labor. Verifications are so much work that only a few substantial programs have ever been verified. Program verification does not mean error-proof programs. There is no magic here, either. Mathematical proofs also can be faulty. So whereas verification might reduce the program-testing load, it cannot eliminate it. More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“Even at a cost of $100,000, a purchased piece of software is costing only about as much as one programmer-year. And delivery is immediate! Immediate at least for products that really exist, products whose developer can refer the prospect to a happy user. Moreover, such products tend to be much better documented and somewhat better maintained than homegrown software. The development of the mass market is, I believe, the most profound long-run trend in software engineering. The cost of software has always been development cost, not replication cost. Sharing that cost among even a few users radically cuts the per-user cost. Another way of looking at it is that the use of n copies of a software system effectively multiplies the productivity of its developers by n. That is an enhancement of the productivity of the discipline and of the nation.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“The big change has been in the hardware/software cost ratio. The buyer of a $2-million machine in 1960 felt that he could afford $250,000 more for a customized payroll program, one that slipped easily and nondisruptively into the computer-hostile social environment. Buyers of $50,000 office machines today cannot conceivably afford customized payroll programs; so they adapt their payroll procedures to the packages available.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“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. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified. Even the simple answer—"Make the new software system work like our old manual information-processing system"—is in fact too simple. Clients never want exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach. Let us turn to nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. 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.[11] That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below. I have seen the most dramatic results since I began urging this technique on the project builders in my software engineering laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there. The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“I believe that large programming projects suffer management problems different in kind from small ones, due to division of labor. I believe the critical need to be the preservation of the conceptual integrity of the product itself.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
“I have long enjoyed asking candidate programmers, "Where is next November?" If the question is too cryptic, then, "Tell me about your mental model of the calendar." The really good programmers have strong spatial senses; they usually have geometric models of time; and they quite often understand the first question without elaboration. They have highly individualistic models.”
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

« previous 1 3 4