About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Oct.23 Mon
Earlier this month, I became a licensed Certified ScrumMaster™. I should show up in the official rosters pretty soon; here is a screen-shot of my info in www.scrumalliance.org. (I need to correct some of that information.)
By the way, as this cartoon asserts, Scrum isn't a Silver Bullet. Neither is XP. However, they both do many of the things that Brooks recommends in his article "No Silver Bullet". (See previous posting).
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.