Rereading No Silver Bullet

While re-reading "No Silver Bullet" (http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html), I was amazed by the intemporality of the article. It was published in April 1987 (Computer, Vol. 20, No. 4) and written by Frederick P. Brooks, and as it's almost TWENTY years old it feels more actual than ever.

In the article, Brooks divides the difficulties in Software Engineering between Essence and Accidental.

On the side of the essential difficulties, are the complexity, conformity, changeability and invisibility of software. Meaning that software is inherently complex as it is an abstract entity that represents complex interactions (business rules) and interfaces with complex systems/processes/procedures. Not only that, but generally it's the software that must change to accomodate the business process and frequently the client doesn't know what he wants/needs (funny to see how something never changes J).

The past breakthroughs (and some current silver bullets, in my opinion) only solve accidental difficulties. These are difficulties not inherent to building software, but with the way it was done.
Among these are: High-level Languages (raises the expressive power of the language, but doesn’t attack the complexity of software), Time-Sharing (reduces the time gap between code, build and execution) and Unified Programming Environments (back then Unix and Interlisp, J).

Among the hopes, there is ADA, OO programming, Artificial Intelligence, Graphical Programming, Environments and Tools and Workstations, all with marginal increment.

The possible breakthroughs must come from:
Buy vs Build (if one builds a system from bought components and minimal adjustments, the cost can be much lower, because it’s already tested, the delivery is immediate)
Requirements refinement and rapid prototyping (most agile methodologies revolve around the iterative construction of a system. Considering the first iterations of a system, as a prototype that evolves to the final system, this point%2