This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: No Silver Bullet
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
So many people say "No Silver Bullet" mindlessly, without having read the article that made that phrase a clich�� in the software profession. I'm speaking of the article by Frederick P. Brooks "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, Vol. 20, No. 4 (April 1987). Here's a copy.
Lately, I've even seen the phrase "No Silver Bullet" used to argue against adopting agile methods. Here's what that article really says; you might find its emphasis on agile concepts surprising. Concepts like: "Working software over comprehensive documentation", "Customer collaboration over contract negotiation", and "Responding to change over following a plan". Quotes:
The familiar software project, at least as seen by the nontechnical
manager, has something of this character [of the werewolf]; it is
usually innocent and straightforward, but is capable of becoming a
monster of missed schedules, blown budgets, and flawed products. So we
hear desperate cries for a silver bullet--something to make software
costs drop as rapidly as computer hardware costs do.
But, as we look to the horizon of a decade hence, we see no silver
bullet. [...]
He's referring to fact that hardware costs get cut regularly and why software costs does not have a similar perpetual future of cost reductions. But he also says: (Boldfacing is my emphasis)
Skepticism is not pessimism, however. Although we see no startling
breakthroughs--and indeed, I believe such to be inconsistent with the
nature of software--many encouraging innovations are under way. A
disciplined, consistent effort to develop, propagate, and exploit
these innovations should indeed yield an order-of-magnitude
improvement. [...]
He goes on to describe the essential hard parts of software development (where the costs can't be compressed):
The essence of a software entity is a construct of interlocking
concepts: data sets, relationships among data items, algorithms, and
invocations of functions. This essence is abstract in that such a
conceptual construct is the same under many different representations.
It is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification,
design, and testing of this conceptual construct, not the labor of
representing it and testing the fidelity of the representation. We
still make syntax errors, to be sure; but they are fuzz compared with
the conceptual errors in most systems.
He then goes on to say why software specification,
design, and testing can't be just once:
All successful software gets changed. Two processes are at work.
First, as a software product is found to be useful, people try it in
new cases at the edge of or beyond the original domain. The pressures
for extended function come chiefly from users who like the basic
function and invent new uses for it.
After some discourse in various areas, Brooks gets back to requirements: (Boldfacing is my emphasis)
Therefore, the most important function that the software builder
performs for the client is the iterative extraction and refinement of
the product requirements. [...] Complex software systems are,
moreover, things that act, that move, that work. The dynamics of that
action are hard to imagine. So in planning any software-design
activity, it is necessary to allow for an extensive iteration between
the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify
completely, precisely, and correctly the exact requirements of a
modern software product before trying some versions of the product.
Sounds like he's advocating agile software development with frequent releases and close customer involvement. He mentions Rapid Application Development(RAD) and protyping. today we have experience in iteratively and incrementally producing software without throw-away-prototypes, and without some of the difficulties of RAD.
He also mentions the consequences of this style of development to morale: (Individuals and interactions over processes and tools.)
The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.
Brooks says:
Incremental development--grow, don't build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about
building a program, as opposed to writing one. In a flash he broadened
my whole view of the software process.[...]
The building metaphor has outlived its usefulness. It is time to
change again. If, as I believe, the conceptual structures we construct
today are too complicated to be specified accurately in advance, and
too complex to be built faultlessly, then we must take a radically
different approach.
[...]
Some years ago Harlan Mills proposed that any software system should
be grown by incremental development. That is, the system should
first be made to run, even if it does nothing useful except call the
proper set of dummy subprograms. Then, bit by bit, it should be
fleshed out, with the subprograms in turn being developed--into
actions or calls to empty stubs in the level below.
I have seen most dramatic results since I began urging this technique
on the project builders in my Software Engineering Laboratory class.
Nothing in the past decade has so radically changed my own practice,
or its effectiveness.
He mentions the necessity of writing code top-down, which isn't entirely a necessity today. We can write programs in vertical slices, but not everything in that slice has to be "final" code. Since (as Brooks says in his article) coding isn't the hardest work of software development, we can code simple things in earlier iterations and grow those later into more complex things as needed, making time available for the customer to see some functionality early.
Previous Topic
