Brooks, Fredrick P., “No Silver Bul

Brooks, Fredrick P., “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer, Vol 20, No 4 (April 1987), pp. 10-19

This is the famous article by Brooks which Cockburn referred to in Agile Software Development. In it, Brooks defines some concepts relating to software development in order to help people see what makes software development hard in an effort (possibly) to dissuade people from believing that there is yet to be a silver bullet which will make software development easy enough for anyone to do well. He says there are two classes of qualities of software: essential qualities, and accidental qualities. The essential qualities are extremely difficult to address or improve, while the accidental qualities can be improved via tool support.

The essential qualities all have to do wth the design of software: understanding the problem and designing and testing the conceptual contstruct. The accidental qualities have to do with implementing the construct in code and testing it.

The essential qualities are these:

Complexity: software design is complex: understanding domain concepts to the extent that one can define them and the relationships between them exactly is hard; this definition is essential if we want to translate those concepts into code. Unlike physical objects, no two parts of a software construct are alike. Scaling up of a software entity necessarily means a scaling up in components and complexity. The problem associated with complexity are: difficulty of communication of design among team members; difficulty in enumerating all possible states of the program (which brings unreliability); makes programs hard to use; makes programs hard to change without inducing unwanted side-effects. The complexity makes overview hard (seeing and tying up loose ends), and the tremendous learning burden means turnover is costly.
Invisible: can’t see it all at once as you would a physical piece of something. It is also very difficult even to visualize since there are many ways to look at the same design: “the reality of software is not inherently embedded in space.” This inhibits communication of structure and design.
Changeable: we’re just pushing bits around in the end; changing ideas. Therefore it is always possible to change a piece of software. Software is inherently flexible where physical products are not. (McConnell , pp. 19-20). Change comes in two ways: people use the software in ways not originally forseen in the design and want better support for that; and the physical machine/OS changes underneath us.
Conformity: software must conform to external constraints (particular hardware, legacy systems and data, regulations) that make it difficult to reduce complexity. Much of the complexity of interacting with human systems is arbitrary, and since software is percieved as changeable, it is most often seen as the thing which should conform, not the human system.
The accidental qualities are all about implementation and testing, and these have been solved almost as well as they are likely to be solved, so don’t expect many more breakthroughs. Here are things that Brooks says have helped to reduce the impact of the accidental qualities (keep in mind he’s writing this in the middle of the 1980s):

High level languages (including object orientation). High level languages allow programmers to express implementation with concepts closer to that which we use in design. We’re reducing or eliminating the translation step between data models, operations, sequances and communication and registers and bits. This eliminates a lot of the translation complexity. But Brooks says that “the most a high-level language can do is to funish all the constructs that the programmer imagines in the abstract program” and although our level of thinking about those constructs is improving, it does so at an ever decreasing rate.
Time sharing and better OS support: Time sharing is contrasted with batch processing, and it helps because we spend much less time in the code and test cycle. By better OS support, I mean the difference betweeen DOS (which has no library and almost no system call support) and UNIX (which contains many libraries and a vast system call set, allowing you to not have to implement display code, disk drivers, filesystems code, etc.).
He then talks about hopes for the future, and discounts all as being silver bullets: Ada and other high-level languages, object orientation, AI (both in the idea of software solving problems that were previously the domain of human intelligence; and in expert systems), expert systems, automatic programming (we specify the requirements and the software writes code for us); graphical programming (a la LabVIEW), proof based design verification, better tools, and workstations.

He identifies three promising areas that may help promote obtaining (note: not necessarily building) better software:

Buy versus build. Remember that in the mid 1980s, the software market was still small.
Incremental, iterative development with feedback from end users: because this helps to refine requirements, prove the design, and improves morale
Identify, retain and coddle great designers: some people are just better at software design than others. Try to identify them, retain them in your organization, and coddle them so that they get the skills and compensation that they need.