This is a true story. Names of people and components have been changed to protect the innocent.
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
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.
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.