More on this book
Community
Kindle Notes & Highlights
Read between
November 12 - November 19, 2019
Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.
He depends upon other people's programs. These are often maldesigned, poorly implemented, incompletely delivered (no source code or test cases), and poorly documented. So he must spend hours studying and fixing things that in an ideal world would be complete, available, and usable.
Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them
The bearing of a child takes nine months, no matter how many women are assigned.
Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.
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. 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.
Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
Adding manpower to a late software project makes it later.
It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.
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.
By the architecture of a system, I mean the complete and detailed specification of the user interface.
If a system is to have conceptual integrity, someone must control the concepts.
Extrapolation of times for the hundred-yard dash shows that a man can run a mile in under three minutes.
Programming productivity may be increased as much as five times when a suitable high-level language is used.
Much more often, strategic breakthrough will come from redoing the representation of the data or tables.
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
Delivering that throwaway to customers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down.
Plan the System for Change The ways of designing a system for such change are well known and widely discussed in the literature—perhaps more widely discussed than practiced. They include careful modularization, extensive subroutining, precise and complete definition of intermodule interfaces, and complete documentation of these. Less obviously one wants standard calling sequences and table-driven techniques used wherever possible. Most important is the use of a high-level language and self-documenting techniques so as to reduce errors induced by changes. Using compile-time operations to
...more
Management structures also need to be changed as the system changes. This means that the boss must give a great deal of attention to keeping his managers and his technical people as interchangeable as their talents allow.
managers themselves often think of senior people as "too valuable" to use for actual programming.
Managers need to be sent to technical refresher courses, senior technical people to management training. Project objectives, progress, and management problems must be shared with the whole body of senior people.
Whenever talents permit, senior people must be kept technically and emotionally ready to manage groups or to delight in building programs with their own hands. Doing this surely is a lot of work; but it surely is worth it!
The fundamental problem with program maintenance is that fixing a defect has a substantial (20–50 percent) chance of introducing another.
even a subtle defect shows itself as a local failure of some kind. In fact it often has system-wide ramifications, usually nonobvious. Any attempt to fix it with minimum effort will repair the local and obvious, but unless the structure is pure or the documentation very fine, the far-reaching effects of the repair will be overlooked. Second, the repairer is usually not the man who wrote the code,
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.
How does a project get to be a year late? . . . . One day at a time.
Exploiting the mass market to avoid constructing what can be bought. • Using rapid prototyping as part of a planned iteration in establishing software requirements. • Growing software organically, adding more and more function to systems as they are run, used, and tested. • Identifying and developing the great conceptual designers of the rising generation.
The complexity of software is an essential property, not an accidental one.
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.
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements.
find that teams can grow much more complex entities in four months than they can build
We can get good designs by following good practices instead of poor ones. Good design practices can be taught. Programmers are among the most intelligent part of the population, so they can learn good practice.
Software construction is a creative process.
The differences between the great and the average approach an order of magnitude.
Good cooking takes time; some tasks cannot be hurried without spoiling the result.
Partitioning a task among multiple people occasions extra communication effort—training and intercommunication.
The conceptual integrity of the product, as perceived by the user, is the most important factor in ease of use.
Software products are both complex and fiercely competitive in schedule.
The waterfall model puts system test, and therefore by implication user testing, at the end of the construction process. Thus one can find impossible awkwardnesses for users, or unacceptable performance, or dangerous susceptibility to user error or malice, only after investing in full construction.
"The manager's function is not to make people work, it is to make it possible for people to work."
The key thrust [of recent years] was delegating power down. It was like magic! Improved quality, productivity, morale. We have small teams, with no central control. The teams own the process, but they have to have one. They have many different processes. They own the schedule, but they feel the pressure of the market. This pressure causes them to reach for tools on their own.
