The Mythical Man-Month: Essays on Software Engineering
Rate it:
Open Preview
60%
Flag icon
Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge.
67%
Flag icon
Reusability at the corporate level aims for 75% reused code by volume, and requires special library and administrative support.
69%
Flag icon
The programming project converges more slowly the nearer one gets to the end, whereas one expects it to converge faster as one approaches the end.
72%
Flag icon
Productivity seems constant in terms of elementary statements.
73%
Flag icon
The project manager's chief daily task is communication, not decision-making; the documents communicate the plans and decisions to the whole team.
74%
Flag icon
Both the actual need and the user's perception of that need will change as programs are built; tested, and used.
75%
Flag icon
Fixing a defect has a substantial (20 to 50 percent) chance of introducing another.
77%
Flag icon
activity time estimates revised carefully every two weeks do not significantly change as the start time approaches, that during the activity overestimates come steadily down; and that underestimates do not change until about three weeks before scheduled completion.
79%
Flag icon
Product-development processes in many industries cannot, however, afford this straightforward approach to conceptual integrity. Competitive pressures force urgency; in many modern technologies the end product is quite complex, and the design inherently requires many man-months of effort. Software products are both complex and fiercely competitive in schedule.
79%
Flag icon
The subsystem boundaries must be at those places where interfaces between the subsystems are minimal and easiest to define rigorously.
80%
Flag icon
write down explicit guesses for the attributes of the user set. It is far better to be explicit and wrong than to be vague.
82%
Flag icon
"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.
« Prev 1 2 Next »