For years I had been observing that every software development method or tool offered by anyone seemed to work when it is applied to a first-time development, but began to fail when it was necessary to subject the software to changes. After thinking about it for a while, I sat down and wrote a paper titled ``The Inevitable Pain of Software Development: Why There Is No Silver Bullet'' It observes that programming technology has improved immensely since its earliest days. However, no single improvement can be classified as a silver bullet, despite all claims of its proponents. A vexing question is why there has been no silver bullet. A variety of programming improvements, i.e., models, methods, artifacts, and tools, are examined to determine that each has a step that programmers find painful enough that they habitually avoid or postpone the step. This pain is generally where the programming accident meets the essence of software and its relentless volatility. Hence, there is no silver bullet. It is claimed no substantial programming improvement can avoid all pain; therefore there will never be a silver bullet.

Among the models, methods, artifacts, and tools examined are (in alphabetical order):

build-and-fix model,
changes,
configuration management,
daily build,
documentation,
extreme programming,
formal methods,
inspection,
open sourcing,
rapid prototyping,
regression testing,
requirements engineering,
structured programming,
traceability, and
waterfall model.

Part of this still growing paper has been published at the International Workshop on Time-Constrained Requirements Engineering 2002 (TCRE'02)

Part of this still growing paper has been published at the Monterey Workshop 2002: Radical Innovations of Software and Systems Engineering in the Future (RISSEF)

Part of this still growing paper has been published in the Radical Innovation of Software and Systems Engineering in the Future, Proceedings of the 2002 Monterey Conference, Selected Papers, LNCS 2941, Springer, 2004.

The fullest paper is the technical report mentioned in the first paragraph of this page.

I give a dynamite talk on the subject.

I am interested in hearing other people's opinions.

Other observations about extreme programming can be found in ``More Requirements Engineering Adventures with Building Contractors''. A PDF preprint is available