## Highlights There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. ([View Highlight](https://read.readwise.io/read/01k3hk01fafvbbd7h56446jpfs)) --- All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. ([View Highlight](https://read.readwise.io/read/01k3hk0nt0pvgw5j1c4zndxvkv)) --- Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. ([View Highlight](https://read.readwise.io/read/01k3hk1v8dgy4n08q55x1s2dtk)) --- How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement. ([View Highlight](https://read.readwise.io/read/01k3hk20yth97qst3hrxqr8xvz)) --- I suggest: • 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. ([View Highlight](https://read.readwise.io/read/01k3hk2p9vhjcqfqh3jkswy98v)) --- to see what rate of progress we can expect in software technology, let us examine its difficulties. Following Aristotle, I divide them into essence−the difficulties inherent in the nature of the software−and accidents−those difficulties that today attend its production but that are not inherent. ([View Highlight](https://read.readwise.io/read/01k3hk6k6f3czctz57b1j27g32)) --- The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. ([View Highlight](https://read.readwise.io/read/01k3hk77cy24f9cw3q48zj0vjf)) --- I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. ([View Highlight](https://read.readwise.io/read/01k3hk7ecsstkp8v7gvwf7sk0v)) --- If this is true, building software will always be hard. There is inherently no silver bullet. ([View Highlight](https://read.readwise.io/read/01k3hk7pzmnx0880nf2k77nhw8)) --- **Complexity.** Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a subroutine, open or closed. In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound. ([View Highlight](https://read.readwise.io/read/01k3hk8j1d5xnr3vpyvprb6tkp)) --- 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. Much of the complexity he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must confirm. These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God. ([View Highlight](https://read.readwise.io/read/01k3hkdkmmwzvqg6qm2v86vgdz)) --- But in all cases, much complexity comes from conformation to other interfaces; this cannot be simplified out by any redesign of the software alone. ([View Highlight](https://read.readwise.io/read/01k3hke5j0cymsweq3zx2wp8dn)) --- **Changeability.** The software entity is constantly subject to pressures for change. ([View Highlight](https://read.readwise.io/read/01k3hkegfqktgf18cq2vmzvkh7)) --- All successful software gets changed. Two processes are at work. As a software product is found to be useful, people try it in new cases at the edge of, or beyond, the original domain. The pressures for extended function come chiefly from users who like the basic function and invent new uses for it. Second, successful software also survives beyond the normal life of the machine vehicle for which it is first written. If not new computers, then at least new disks, new displays, new printers come along; and the software must be conformed to its new vehicles of opportunity. ([View Highlight](https://read.readwise.io/read/01k3hkfmmdkn4bbnvq11f02q1k)) --- the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the software product. ([View Highlight](https://read.readwise.io/read/01k3hkfx0fg0c4n8am2bpsq78c)) --- **Invisibility.** Software is invisible and unvisualizable. ([View Highlight](https://read.readwise.io/read/01k3hkg24c8c5zz4eamzgvz10d)) --- The reality of software is not inherently embedded in space. Hence it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics. As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs, superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. ([View Highlight](https://read.readwise.io/read/01k3hkh29q0d25ywt21h0th31q)) --- The slow turnaround of batch programming means that we inevitably forget the minutiae, if not the very thrust, of what we were thinking when we stopped programming and called for compilation and execution. This interruption of consciousness is costly in time, for we must refresh. The most serious effect may well be the decay of grasp of all that is going on in a complex system. ([View Highlight](https://read.readwise.io/read/01k3hkmfewcyv1wp47a6xt01dz)) --- Two quite different definitions of AI are in common use today. AI-1: The use of computers to solve problems that previously could only be solved by applying human intelligence. AI-2: The use of a specific set of programming techniques knows as heuristic or rule-based programming. ([View Highlight](https://read.readwise.io/read/01k3hkyp23tda550tqmvjtx3f3)) --- The hard thing about building software is deciding what to say, not saying it. No facilitation of expression can give more than marginal gains. ([View Highlight](https://read.readwise.io/read/01k3hkwphdhd5ktmqcd8dvv9xd)) --- The most powerful contribution of expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers. This is no small contribution. The gap between the best software engineering practice and the average practice is very wide−perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important. ([View Highlight](https://read.readwise.io/read/01k3hm1w13rvd4cssap2r7gy7r)) --- For almost 40 years, people have been anticipating and writing about "automatic programming", the generation of a program for solving a problem from a statement of the problem specifications. ([View Highlight](https://read.readwise.io/read/01k3hm381ndxwj55szy7p5n48g)) --- In short, automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer. ([View Highlight](https://read.readwise.io/read/01k3hm2hbjmc2wdenybngg4acw)) --- 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. ([View Highlight](https://read.readwise.io/read/01k3hm7vhxkrb28pn1f86v1nqk)) --- If, as I believe, the conceptual components of the task are now taking most of the time, then no amount of activity on the task components that are merely the expression of the concepts can give large productivity gains. ([View Highlight](https://read.readwise.io/read/01k3hma5wv4czby3dgbv4e9283)) --- 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. ([View Highlight](https://read.readwise.io/read/01k3hmbvt9re1jx2e3hqdrf5s2)) --- I believe the single most powerful software productivity strategy for man organizations to day is to equip the computer-naïve intellectual workers on the firing line with personal computers and good generalized writing, drawing, file and spreadsheet programs, and turn them loose. The same strategy, with simple programming capabilities, will also work for hundreds of laboratory scientists. ([View Highlight](https://read.readwise.io/read/01k3hmeve7yjfy4f125dyxvnkc)) --- The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is to 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 go rectify later. ([View Highlight](https://read.readwise.io/read/01k3hmf90b87wk5h74472kch14)) --- 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. ([View Highlight](https://read.readwise.io/read/01k3hmfknyn0xjn6fwv5tqrapa)) --- I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying. ([View Highlight](https://read.readwise.io/read/01k3hmgjs73e1pp18sb40g2xxj)) --- Therefore one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements. ([View Highlight](https://read.readwise.io/read/01k3hmgt92h1g6pjd079rvp5cz)) --- Much of present-day software acquisition procedures rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. ([View Highlight](https://read.readwise.io/read/01k3hmhfyhaz25hsfdxyxnm4m6)) --- I find that teams can *grow* much more complex entities in four months than they can *build* . ([View Highlight](https://read.readwise.io/read/01k3hmmh5nvnh1ss9wpgmm2q7n)) --- Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge. ([View Highlight](https://read.readwise.io/read/01k3hmnzwmdhwqhfxtrgw8xcw7)) --- 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. ([View Highlight](https://read.readwise.io/read/01k3hmphb386g2ktdzg2asj7m3)) ---