progressive widening

In my series of context specification posts I've been working through a particular user story and writing specifications that drive my production code. Over the next few posts I'm going to explore this story in more detail but wanted to take a quick detour into another topic that is relevant to how I plan to deliver this - that topic is "Progressive Widening".

I came across this concept in a video on InfoQ by Bob Martin entitled "Craftsmanship and Ethics"

In this he describes it as the implementation of a feature right the way through your code base and I'll be attempting to do just this in my context examples so that a working application is available after each feature is implemented.

He describes it as:

"Progressive widening is the practice of adding a small feature to the system - that feature goes from the top of the system to the bottom of the system, all the way from the GUI down to the database.
It's not a very big feature, it's very, very thin; the pragmatic programmers call these things tracer bullets, the extreme programming community calls them spikes."

"We do not implement one task in the GUI, one task in the middleware and one task in the database and we certainly never complete one layer without doing the next layer at the same time."

"Once we have ths system working in a thin little slice, then we then start to widening it - progressively widening it every iteration adding a few more of these spikes, every iteration growing the system all the way from the GUI to the database.
That is progressive widening."

I love this and it's how I write my own personal code at the moment.
In the real world its a bit trickier - I'm working on an integration project that just doesn't lend itself well to thin slices, but we strive to do this where possible. I think its an admirable agile goal.