This is the strangler (fig) pattern under a different name: https://martinfowler.com/bliki/StranglerFigApplication.html
Steel Threads are a powerful but obscure software design approach
81–89 of 89 posts
Re: Steel Threads are a powerful but obscure software design approach
#82The example in the article doesn't make sense to me. It basically says "You want to switch out a piece of a monolith to a new service, you do it with feature flags etc. That's hard." Which is true. But then it says "Steel Threads is better. Instead of switching out a part of your monolith, you... switch out a part of your monolith but it's a smaller part. That's not as hard". Which is true but isn't that the same thi…
Exactly, not sure what new insight this post is supposed to provide. On the other hand, sometimes switching over gradually, one small part at a time, actually increases the complexity of the whole migration.
It provides a useful metaphor
Re: Steel Threads are a powerful but obscure software design approach
#83This reminds me of Vertical Slice Architecture by Jimmy Bogard.
Re: Steel Threads are a powerful but obscure software design approach
#84I think this is a very used technique, but I was unfamiliar with the name.
Re: Steel Threads are a powerful but obscure software design approach
#85Where this approach really shines is in v1 of a complex project. If you have multiple teams combining to deploy edge compute pushing data to a cloud service and talking to multiple client experiences, then a steel thread approach can help maintain sanity while requirements and contracts are evolving.
Re: Steel Threads are a powerful but obscure software design approach
#86This reminds me of something John Carmack tweeted once (can't find the tweet). In the tweet, he said that when coding, he'd start by the smallest possible PoC, and code it entirely front to back. That'd give the general structure, and then he'd build upon that. (this is what I remember of it fwiw). I do this all the time too, which I think is a vastly superior approach to TDD, which assumes how an API is going to be…
Inside my particular mind, this practice is called "driving a wire through it", which is close enough to the concept of a "steel thread" that I can imagine where the author might have gotten the idea.
Re: Steel Threads are a powerful but obscure software design approach
#87We have doing something similar to this for a long time as proof of concept for h/w and s/w of control systems architectures with new, or new combinations of, equipment, but calling it a vertical slice.
Re: Steel Threads are a powerful but obscure software design approach
#88This reminds me of something John Carmack tweeted once (can't find the tweet). In the tweet, he said that when coding, he'd start by the smallest possible PoC, and code it entirely front to back. That'd give the general structure, and then he'd build upon that. (this is what I remember of it fwiw). I do this all the time too, which I think is a vastly superior approach to TDD, which assumes how an API is going to be…
> TDD, which assumes how an API is going to be used, without actually writing the actual thing that's going to use it.
That’s not TDD. It’s a common misconception that you’ve fallen for, and are now spreading further.
TDD is a series of small steps where you write a bit of test code—about five lines—and then a bit of production code—about five lines—then refactor, then repeat.
Here’s a free chapter in my book that describes how it works:
https://www.jamesshore.com/v2/books/aoad2/test-driven_develo...
Here’s a video that demonstrates it:
https://www.jamesshore.com/v2/projects/lunch-and-learn/incre...
Re: Steel Threads are a powerful but obscure software design approach
#89This sounds like it was written with AI assistance.