More on this book
Community
Kindle Notes & Highlights
Read between
February 3 - February 4, 2018
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.
In the lower right-hand corner of Fig. 1.1 stands the programming systems product. This differs from the simple program in all of the above ways. It costs nine times as much. But it is the truly useful object, the intended product of most system programming efforts.
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.
Second is the pleasure of making things that are useful to other people.
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.
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task.
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.
Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.
The dependence upon others has a particular case that is especially painful for the system programmer. He depends upon other people's programs.
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.
The real tiger is never a match for the paper one, unless actual use is wanted.
The challenge and the mission are to find real solutions to real problems on actual schedules with available resources.
First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.
All programmers are optimists.
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.
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.
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.
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.
Second, in the conventional team the partners are equal, and the inevitable differences of judgment must be talked out or compromised.
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.
The architect of a system, like the architect of a building, is the user's agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user, as opposed to the interests of the salesman, the fabricator, etc.
"Where architecture tells what happens, implementation tells how it is made to happen."[3] He gives as a simple example a clock, whose architecture consists of the face, the hands, and the winding knob.
Good features and ideas that do not integrate with a system's basic concepts are best left out.
Many actors, of course, entered into that mistaken decision; but the overwhelming one was schedule time and the appeal of putting all those 150 implementers to work. It is this siren song whose deadly hazards I would now make visible.
• remember that the builder has the inventive and creative responsibility for the implementation; so the architect suggests, not dictates;
This second is the most dangerous system a man ever designs.
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.
"Never go to sea with two chronometers; take one or three."
The precise nature of this trash turns out to be part of the de facto definition,
The project manager's best friend is his daily adversary, the independent product-testing organization.
Shortly the clans began to move apart, preferring isolation to wrangling.
Thinkers are rare; doers are rarer; and thinker-doers are rarest.
The linear extrapolation of such sprint figures is meaningless. Extrapolation of times for the hundred-yard dash shows that a man can run a mile in under three minutes.
Who: organization chart. This becomes intertwined with the interface specification, as 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.
It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. —FRANKLIN D. ROOSEVELT
In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three.
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that.
Hence plan to throw one away; you will, anyhow.
the programmer delivers satisfaction of a user need rather than any tangible product.
Nevertheless, some changes in objectives are inevitable, and it is better to be prepared for them than to assume that they won't come.
the common failing of programming groups today is too little management control, not too much.
The simulator will surely fail in some respect to be a faithful and accurate implementation of the new machine's architecture. But it will be the same implementation from one day to the next, and the new hardware will not.
How does a project get to be a year late? . . . . One day at a time.
Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness.
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.
The flow chart is a most thoroughly oversold piece of program documentation.
The detailed blow-by-blow flow chart, however, is an obsolete nuisance, suitable only for initiating beginners into algorithmic thinking.
