Month: December 2006

Iterative Delivery: Finish Something, Ship, Repeat.

I’m in the habit, and we (Oasis Digital) are in the habit, of having a lot of irons in the fire: many features in progress (in development) at a time, working a bit on each. There are good reasons to do this – for example, it helps keeps a team engaged, it avoids being “stuck” on a feature in need of customer feedback, etc.

But it is also a form of multitasking (which makes us stupid). It turns out that within certain constraints, we can deliver value to our customers much better by not multitasking, but rather by a focused approach:

  • Pick a small number of features, those most important to customer(s).
  • Bite off a reasonable small scope of each – if a feature is large (or even not-really-small), split it in to a part of finish right now and another part to put in the backlog
  • Work on them to 100% completion (delivered to the customer, done) of some useful scope
  • Repeat.

Of course, this is called “iteration” and we all know that’s like mom and apple pie. And yet… knowing something is good, is not the same as doing it.

Regarding the splitting of scope in to “now” and “later”: Some developers and teams are prone to use this as a way to not give the customer what they want. That is an abuse of the idea of iteration. Rather:

  • “Let” customers want what they want; you can’t stop them anyway.
  • Don’t try to talk them out of it.
  • Don’t try to avoid giving it to them.
  • Don’t look for ways to stall “forever”
  • Don’t look for ways to drag out the delivery of the first piece
  • Do work with them to split what they want in to a series of pieces which you can deliver iteratively.
  • Starting delivering pieces soon.
  • Keep delivering.

$200 -> Rubinius

I’ve been using Ruby sporadically for some time, including in a bit of production code (in which it is running well), but the apparent lack of progress toward a more modern VM for Ruby makes it harder to get more deeply involved. On the one hand, today’s Ruby interpreter/runtime is sufficiently good to build very successful services on (37Signal’s Rails-based services, for exampel); but in my own testing for the kinds of higher volume data handling I often need to do, it’s among the slowest I’d used. That matters little for populating a web page, but matters a lot for things like OLAP ETL.

So today I joined Geoffrey Grosenbach in supporting Evan Phoenix’s rubinius project, by sending $200 to help sponsor the work. It’s not much in the grand scheme of things, but I believe in “putting your money where your mouth is”.

This isn’t the first time I mentioned Geoff; earlier this year I took him to task for his choice of music for the Ruby on Rails podcast, which has changed since then to something more suitable.