Summary Of No Silver Bullet: Essence And Accidents Of Software Engineering By Frederick P. Books,

Summary of No Silver Bullet: Essence and Accidents of Software Engineering by Frederick P. Books, Jr.

The document states that the common software project is “innocent and straightforward” but it could easily become something complex because of problems with schedule, budget and faulty outcomes. It proceeds to mention how, unlike with hardware, the software’s cost doesn’t decrease as rapidlyas hardware does during time periods, and in fact it sometimes becomes even more expensive.
This fact is due to the inherent nature of software, were as new procedures are created they are usually more useful, but also more complex and needs more resources to be produced. This difference is not due to that software has a slow development rate but that hardware has an increasing exponentialdevelopment rate.
Also, software has inherent difficulties that make it more complex than hardware or other human technological development. The author describes it citing Aristotle, separating the problems in those inherent and those not inherent to the software’s nature, these are those of the environment.
The inherent ones are complexity, conformity, changeability and invisibility. The complexityof software is an important part of it. While physical constructs usually have repeating parts, software doesn’t. Each code of different programs for the same function differs because of its author’s way of writing it. Also, making a program larger implies making more functions and not creating ‘larger’ instances of those same functions.
Each developer has different view and approaches onsolving problems, so even inside a same team there can be differences due to these complexities that make solving a particular situation with a program less simple as it would be without this characteristic.
The conformity is described as how the software complies to certain specifications. Since there are so many ways and languages for programming, making a particular piece of software applicable inall of these is impracticable if not impossible.
The changeability of software regards how the software has to change as the surrounding applies pressure on it. An old version of software could be optimized with new developments in the interface it uses, but it would mean creating new code or changing it. Also something that was considered modern for a piece of hardware can rapidly be consideredobsolete as hardware develops. This doesn’t happen with physical objects, developments just create replacements, but since it is easier to change software than replace it, the first usually happens.
The last characteristic, invisibility, is perhaps that one that makes creating software complex and different for each individual. Unlike the physical tools, software can be seen visually or evenrepresented in a simple form. To transfer the way software works to paper diagrams are useful, but one simple diagram can’t enclose all the factors that make up the software’s nature.
The environment or non inherent difficulties can and most have been solved along the history of development. These helped cope with some result of the inherent difficulties, yet they didn’t solve them. One of thesedevelopments is high level languages; it made software development gain in “reliability, simplicity and comprehensibility”. An issue is that mastering the new language and its tools add more complexity to software itself.
Another development was time-sharing. It shortens the system’s time of response when compiling and executing and helps the programmer visualize its working without losing hisconcentration on the problem while waiting. Still, this benefit in time still isn’t noticeable after it reaches the human capacity.
The appearance of unified programming environments also contributed by making all the programs able to work on a common ground and bypassing the problem of integration of different programs into a process. This reduces time and cost of creating interfaces for the joint...