In this article, learn more about Steel Threads: a powerful but obscure software design approach that can help you avoid common problems like integration pain.
Steel Threads are a powerful but obscure software design approach. Learning about Steel Threads will make you a better engineer. You can use them to avoid common problems like integration pain, and you can use them to cut through the complexity of system design.So Obscure It Was Deleted From Wikipedia in 2013
How unknown are Steel Threads? The concept was deleted from Wikipedia in 2013 because “the idea is not notable within Software Engineering, and hasn’t received significant coverage from notable sources.” Let’s add to the coverage, and also talk through why it is such a useful approach.What Are Steel Threads?
A Steel Thread is a very thin slice of functionality that threads through a software system. They are called “threads” because they weave through the various parts of the software system and implement an important use case. They are called “steel” because the thread becomes a solid foundation for later improvements.
With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case.Example of Conventional, Problematic Approach
Let’s say you’re building a new service to replace a part of your monolithic codebase. The most common way to do this would be to:
Look at the old code, and figure out the needs of the new system.
Design and build out the APIs that provide the capabilities you need.
Go into the old code, and update references to use the new APIs. Do it behind a feature flag.
Cut over using the feature flag.
Fix any issues that come up until it’s working, turning off the feature flag if necessary to go back to the old code path.
When it’s stable, remove the old code paths.
Sounds reasonable, right? Well, this is the most common way software engineers operate, but this approach has a lot of landmines.
What problems would I expect in this project?
It may be appealing to build the new service in a way disconnected from the old system. After all, the design might feel purer. But you’re also introducing significantly more structural change and you’re making these changes without any integration into the old system. This increases integration pain significantly. My expectation would be that all the estimates for the project are unrealistic. And I’d expect the project to be considered a failure after it is completed, even if the resulting service has a generally good design.
I would expect the switchover to the new system to be problematic. There will be a series of problems uncovered as you switch over, that will require switching back to the old code paths or working intensely to fix problems in the final stages of the project.
