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
2003.Dec.06 Sat
Sometimes someone says that they can't do an iterative and incremental software development process, like Extreme Programming with its "frequent releases" practice, because the product is "all or nothing". They can't imagine a "partial" product being useful. This is, of course, a failure of imagination. A thread on this topic is on the XP mailing list.
Jeff Grigg made the analogy to building a fence around the back yard of a house (separating our yard from three neighbors). We estimate that it would take two days to build the entire fence, but we don't say we can't do it because we can't build it one day - nor do we need to redefine the length of the day to be 48 hours long. A partial fence can deliver value - we could build just one or more sections of fence each day.
We could divide the fence-building into post-hole-digging, post-planting, cross-beams, vertical slats, and so on. This means that the end of day one, we might have all the post-holes dug, and one-third of the posts planted. This would be the "infrastructure-first" approach that XP does NOT recommend, because this doesn't allow changing requirements easily, nor does it take in account learning that comes from completing a "small" feature.
Steve Howell expands on this 'learning' point: by building one section first, "to separate my yard from Bob's yard", we not only learn fence-building techniques on a smaller "sub-project", but also may learn that fencing-building takes longer than expected - maybe it took two days to do that one section, when we thought it would take a half-day. That learning allows us to change requirements. Instead of the next story being "build a fence to separate my yard from Mary's yard," we might opt for a "plant a hedge to separate my yard from Mary's yard" instead.
Note that if we had dug all the post-holes for the entire fence first, followed by post-planting, we'd have a less predictable situation for estimating the end of the entire job. The portions we have done so far do not form a good basis for estimating how long the next portions we're going to do, because the activities are so different. If we had done a 'complete' fence for just Bob's yard, we would have done ALL of the activities for building a fence, and thus estimating the fencing-building for Mary's yard would be more accurate.
If we had dug all the post-holes for the entire fence, and then decided not to fence away two of the three neighbors, (business requirements have changed), then we've wasted our effort, and he'd have to fill in those holes. If we did a partial fence first, that might be valuable enough "as is" not to remove, even though our plans have changed. The post-holes by themselves have little value.
Now, construction analogies to software are NOT my favorite thing. So let's talk about breaking down requirements for a software application. Steve Howell proposes thinking about the requirements for a coffee-house order system. "Until you put the entire menu on the system, you can't really use the system... How do you break this down?"
Jeff Grigg proposes the following sequence of stories, saying that many real diners work just this way:
- Server types in the total of the food items. System computes tax and total.
- System computes change.
- System tracks tips.
- System tracks which servers did which orders.
- System accepts some simple and very common orders.
John Roth proposes a couple of different stories, prioritized early:
...many places include the ability to insert orders that aren't on the official menu. That's what I'd do first, and then add in the menu items roughly in order of volume...
...I'd put in the ability to process credit (and debit) cards somewhere before tracking the servers and tips...
Now an infrastructure-first approach might have decided that a full-fledged (*) relational database with transaction processing would be a necessary first step, and a distributed system of order-station-clients a necessary second step. This is a bit like digging all the post-holes before planting any posts. However, that's not the XP way. The first several stories could have been done with a single station with a few simple text-files instead of a relational database.
The XP practices of Refactoring, Simple Design, and once and only-once would put all the code for reading and writing the text files in one or a few classes, which can be changed to deal with a relational database a later date. A little re-work would be involved, but good cohesion and loose coupling allow the change to be done without rewriting the entire application.
(*) Footnote: how may of us recall that the literal meaning of "full-fledged" is having all of your feathers -- "having fully developed adult plumage". Birds don't get all their feathers/features at once, neither do software applications.