Wednesday, November 25, 2009

Steel Threading

This is a true story. Names of people and components have been changed to protect the innocent.

Background:
There are a few things you need to know:
  • We work in two week iterations.
  • We basically work from stories in the XP(ish) style.
  • Stories as written have customer benefit
The Problem:
We wanted to put in a major feature (let's call it the "Behemoth"). The Behemoth was going to basically be a UI replacement. It was going to be great for our customers, and give us better UI scalability and testability, too. There was only one downside: the Behemoth was huge. As in a year or so, rough estimate. There's no way it was going to fit in an iteration, or even in a single release.

Options:
As with most things, we have options. We could....
  • ... branch and send a team off to work on this. When it's done, merge, test, and release!
  • ... hold the release until it's done (eep!).
  • ... break it down into parts.
Now that last one, that's interesting. What if we could break the Behemoth down to some size that would fit in a release, or even better, in an iteration? That sounds good except we have a mandate to not put anything in that doesn't help the customer.

Normally, when you break a Behemoth down, we'd do it into components - say, coordinator, and renderer, and config, for example. We'd then build each component, and at the end we'd string them all together and we'd have a Behemoth. Trouble is, a coordinator is no good to any of our customers, so now we have unused code in the system and we're not providing customer benefit. That's not particularly good of us.

Enter steel threading.

Steel threading is when you break down a project into the smallest end-to-end thing you can do. Then you do another small end-to-end thing. Repeat until you have the thing you're looking for. I don't actually know where the name came from, but I think of it like bridge cable - lots of long skinny steel threads all wrapped up together to make a huge cable that holds up a bridge.


We can use the same trick on our Behemoth. Instead of building a coordinator and then a renderer, we're going to do one tiny use case. For example, we're going to do "view a single widget" in the Behemoth, and we're going to write just enough code to be able to do that. It's far from the customer's full need, but it provides some marginal benefit to the customer, and we can write it small. Next iteration, when we've done "view a single widget", we're going to do "view 2 widgets". Then we'll do "add a widget", followed by "view 1000 widgets". And we'll just keep going until the whole Behemoth is built. This also tends to reduce integration problems, because you've had to integrate your components the whole way along, so if your coordinator can't talk to your renderer, you find out before you'd written a whole lot of code.

As with any technique, steel threading is not universally appropriate. In cases where you're faced with a huge task, though, give it a shot.

3 comments:

  1. Hi Catherine thank you for the post. We did a major UI update and did it iteratively, though it didn't take a year to do (our app is a bit simpler than yours it sounds). I like your approach though of breaking it down into very small parts that can be done.

    How hard of a sell was this approach, or did the powers that be see the value right away?

    ReplyDelete
  2. Robert, this one was actually easy to sell for the simple reason that it lets you see results fairly early. You can get your UI (or your whatever) visible to end-users or management more quickly than if you're doing component-oriented work. And that makes the powers that be feel more comfortable early.

    ReplyDelete
  3. This strategy was called Tracer Bullet Development in _The Pragmatic Programmer_. Good to hear a real life anecdote about using it, and on a large feature to boot!

    ReplyDelete