More on this book
Community
Kindle Notes & Highlights
As a rule of thumb, I estimate that a programming product costs at least three times as much as a debugged program with the same function.
A programming system component costs at least three times as much as a stand-alone program of the same function. The cost may be greater if the system has many components.
one finds that debugging has a linear convergence, or worse, where one somehow expects a quadratic sort of approach to the end. So testing drags on and on, the last difficult bugs taking more time to find than the first.
Already the displacement of one's thought-child is not only conceived, but scheduled.
The challenge and the mission are to find real solutions to real problems on actual schedules with available resources.
Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.
For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation.
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 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.
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.
1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand.
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. Bad news, late and without warning, is unsettling to customers and to managers.
Oversimplifying outrageously, we state Brooks's Law: Adding manpower to a late software project makes it later.
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?
I will contend that conceptual integrity is the most important consideration in system design.
Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. Schedule pressures, however, dictate that system building needs many hands.
The design of an implementation, given an architecture, requires and allows as much design creativity, as many new ideas, and as much technical brilliance as the design of the external specifications.
