I’ve been returning to my source materials on Agile software development/project management methods recently, just to stay fresh. As part of my study, I ran across a blog post (more of a petulant rant, actually) that cites (actually, mentions in passing, with no real justification) the classic Fred Brooks essay No Silver Bullet in support of the assertion that big-A Agile methods cannot possibly be better than other ways of getting software delivered. Besides suffering from the fallacy of appeal to authority (however meritorious Mr. Brooks’s authority in our field might be), it also falls a bit flat to cite NSB in an anti-Scrum screed. To wit:
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 metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.
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.
Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.
So it must be with our software-systems. 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. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.
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.
(The above is, of course, excerpted from Brooks’s essay.)
Iterative development that delivers frequent releases of working software, and uses feedback to determine the direction of growth for the next increment? And a report of empirical (if decidedly anecdotal) support for the notion?
Sounds pretty Agile to me.
(The full essay is available in The Mythical Man-Month: Essays on Software Engineering
. All the while, we’ve been coding like mad and learning a ton of interesting things. While I can’t promise that we’ll “turn the posting faucet back on”, I can say that we’ll try to reduce the big draughts. Now then, on to the show!