The Steel Thread

When building software, particularly complex software, there's a technique that I've seen applied that I think has some merit.

The technique has a name "steel thread" - (Vaughn Vernon tells me this originated with Tim Miller, CEO of Avitek (later acquired by BEA), who went on to become CEO of Rally Software).

Either way, I think the idea has some value in many cases.

I have heard the technique described by contrasting two different ways of building a vehicle: Imagine you are building a vehicle to get people from one place to another. Do you begin by building a piece of an airplane wing, then the other wing, then an engine, and so forth, until you have a whole airplane - or do you begin with a bicycle, upgrade it to a scooter, then upgrade it to a car, then upgrade to an airplane.... you see the difference.

The first pass at a system achieves and end-to-end functionality, but in a minimal way - much like a bicycle will get you from A to B, but not in much comfort and not very quickly.

Another analogy (which resulted in the name) is the construction of a bridge across a river: You don't start with a 5 foot piece of the whole bridge - it would fall down, unsupported. You begin with a simple cable right across the river - a steel thread. Then you use this thread to pull over the first narrow beam... then you attached other parts to that beam... until you have a bridge.

For software, you begin with a minimal system (not an Minimal Viable Product - that's far richer) that does just the core piece of functionality, end-to-end. Then you add another piece of functionality, in it's entirety, until you have achieved an MVP.

That's all there is to it - but the technique has many benefits.

You get to see that your overall concept for the system is actually going to work - this reduces risk on the whole project, as the value of the system is proven out early on.

Issues relating to architecture and integration and usually discovered, as that very first feature goes "all the way" - including an integration with external systems, storage systems, UI and so forth. The cost of changing architecture with only one feature built is far less than not discovering problems until the entire system is relying on the wrong architecture.

It holds to the old adage "keep the cost of changing your mind as low as possible".

I recommend the Steel Thread, and hope you'll give it a try on your own projects!