trailblazer jeopardy [07/18/2007 06:02:34]

Something about trailblazer has been bugging me for a while, and tonight, hopped up on pepsi max and unable to sleep, I realized the thing that was bugging me wasn't a bug, but a feature.

In order to explain it, I have to explain how I visualize a trail.

A trail is like a timeline. The most important features get implemented first, so they go on the left. The less important features come last, so they go on the right.

But there are actually several layers to the timeline, representing stages in the development process, so it makes a table, like so:

-	feature 1	feature 2	feature 3
requirement	...	...	...
use case	...	...	...
feature	...	...	...
test case	...	...	...
working code	...	...	...
user manual	...	...	...

So now, there are basically two strategies for moving through this table.

One strategy looks like this:

# extreme programming model
for x in columns:
    for y in rows:
        do phase y of feature x

Another strategy looks like this:

# waterfall model
for y in rows:
    for x in columns:
        do phase y of feature x

In other words, some methodologies go left to right and some methodologies go up and down. (Yes, my mental model of the "waterfall" runs sideways.)

Most people these days seem to use an iterative approach, where they first break the table into groups of columns, and then apply the waterfall model to each iteration.

The point is, most methodologies choose a grid navigation strategy up front, and apply it consistently. XP bounces up and down, delivering complete working code for a feature before moving on to the next. Traditional models tend to plan further ahead.

I said before that both approaches lose knowledge. The grid illustrates this: the XP folks don't go far enough to the right to get the benefit of hindsight, so they have to refactor at each new column. The iterative waterfallers travel far to the right and wind up with a design, but they forget to mark the trail, so the guys on the next row down - the developers implementing the design - have to fumble along, covering the same ground. Then later (assuming a miracle happens) someone else makes the same long trip and writes some documentation.

The thing that bugged me about trailblazer was I couldn't figure out how I was supposed to navigate the grid. Sometimes one stratey looked better, sometimes the other way looked better. Sometimes I'd jump around working on whatever caught my interest.

Like I said, I thought this was a bug, but it's a feature. Trailblazer gives you a choice.

The trailblazer approach is to make the grid explicit. I don't actually draw a grid. The tools I've cobbled together actually work on an outline basis, with the important features near the top, and the various levels of implementation being represented by more and more detail in the outline. But conceptually, it's equivalent to the grid.

Anyway, the point is that with trailblazer, you can adapt your traversal of the grid to your changing needs. If the pressure's really on, you can do the agile thing and crank out column after column. If you have more time, you can plan ahead and refactor your code while it's still in the abstract or pseudocode phase.

Basically, it's exactly like that game show, Jeopardy. You can pick any column, and do the topmost thing in that column, creating more and more value as you move down.

I dunno about you, but I think that's pretty darn cool.

Kebert Xela!