This page is a collection of summaries of commentaries on the original "No Silver Bullet" article.
The "No Silver Bullet" paper states that software development is composed of "essential" and "accidental" activities. Brooks' opinion is that the accidental is definitely less than 90% of the total effort, so in order to make an order of magnitude improvement in productivity, it is essential to attack the essence, not just make the accidental go to zero.
Evolutionary improvements are more likely to have an positive impact. Shrink-wrapped software and reusable components have some positive impact on productivity. Brooks points out that there hasn't been as much reuse savings (in 1995) as had been expected. He blames part of this on the problems of programmers learning a complex library. It can be very hard to learn the syntax and semantic rules of all of the functions and classes in a large library.
Main point: The "silver bullet" is a paradigm shift, not a technology. Cox thinks of "software components" as blocks of functionality that could be accessed and used on demand -- each component would have some kind of "usage rights" that the user would have to pay for each time the component was used.
Irrational belief in the existence of a "silver bullet" can be useful, because it can be used to help support doing the right thing when faced with a legacy system that really needs to be rewritten (to meet new requirements while bypassing the defects of the old design).
"Developers can abandon their old code without having to explain the awkward truth; they'll also get to update their technical skills and brighten their employment prospects. Managers will be seen as heroes for taking a bold step with the new technology... Developers and managers also buy an insurance policy. If the transition plan fails and the bullet's magical productivity increases don't materialize, they can claim that the technology is still immature or had hidden flaws."
This is an extended version of a paper that appeared in the proceedings of the International Workshop on Time-Constrained Requirements Engineering 2002.
One important point in this paper: It is not just the "essence" and "accidents" of software development that cause difficulty, it is the interface between the essential problems and accidental problems, and the feedback loops that are caused by that interface.