“No Silver Bullet, Essence and Accident in Software Engineering” http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf is a renown paper written by Frederick P. Brooks nearly three decades ago. Paper mainly investigates performance improvement possibilities in software engineering. As it turns out repeatedly, working software, one day unexpectedly turns into a monster, because of a bug about unforeseen complexity. Brooks investigate this problem in hope for finding a silver bullet to leash the monster. As a first step, Brooks divides these unforeseen complexities into two major parts as essential and accidental complexities. Besides he investigates each of these in various perspectives to conclude that, there may not be a magic solution that will yield huge gains as computer hardware industry realized.
Essential complexities appear when we try to construct conceptual structures to form, called abstract software entity. This part should encapsulate the idea, abstract concept that what our customer wants. Essential complexities mainly result because of software’s complexity, conformity, invisibility and changeability. On the other hand, accidental complexities are well studied in the past with introduction of high level languages, time sharing and unified programming environments. These all deal mostly with technical perspectives in software engineering, implementing the concept, realization of idea and essence, so any complexity here is not inherent but accidental. Because of the fact that this area is well studied, any more improvements would be marginal.
Brooks also suggests some promising attitudes in reducing essential complexity. This includes “do not reinvent the wheel”, which means, if there is some software in market, buy it instead of trying to build on your own. Market software would be (hopefully) well tested and corrected in terms of essential complexities. Unless, you need a really customized software, it will be safer to choose ready ones. Another attitude may be rapid prototyping and refinement. Since software is generally can not be projected to a physical basis, it will be hard to conceptualize the actual requirement, and a solution may be a rapid prototype that will show the important interfaces and usability. With this prototype, some essential complexities about communication and requirement analysis may be avoided. By incremental development and rapidly growing perspective, we can have a chance to have an early prototype and be immune to changing environments. It improves the morale of the team and allows immediate feedback. It is found to be productive and yield to somehow “evolutionary model“ in software development. The last but not the least suggestion of Brooks is investing in human factor. Good and effective programs are product of great designers. Some people have inherent talent in making good quality design which reduces most of essential complexities. We should either hire great designers, or try educate what we already have.