41–50 of 89 posts
I'll join others here by saying I haven't heard of it as well and it would seem "tracer bullet" did just fine in The Pragmatic Programmer published much earlier.
The author doesn't state who came up with the term "steel thread" and I'm suspecting it was the author.
They make it somewhat easy to do using Yet Another Reverse Proxy (YARP). I’m in the middle of it for a .NET 4 to 6 migration. The challenge for me is that it introduces complexity. Developers have to think “do I fix this bug in v1 code or v2?” We have to host two backends instead of one. They both touch the same db, so that adds complexity- what if v2 does something in data that breaks v1? All solvable problems but just thought I’d share a from the trenches take. I do still think it is the right approach for this scenario.
As an ex-machinist this thread title really threw me!
I always wonder how these sorts of things happen. MBA: "we have a new technique, you'll love it, it's called a 'steel thread'" "So like, on a bolt?" "..." "Or do you mean more like,,, a wire?" "...Steel. Thread." "Excellent sir. I shall be adding the term 'steel thread' to my next quarterly report. Give my best to the missus."
Earlier quoted context omitted.
As much as I am a fan of monoliths, too many configuration parameters will land you in a world of hurt. You may start with 20 options but people will demand more and more options if you don't stop them very early. Those options will have side effects that other options are supposed to fix and those will also have side effects and in the end you have 1000 options, all doing various things nobody knows. The worst part…
This is not correct. Not all the options are equal. It's possible to soundly define, verify and instantiate big modular contexts. https://github.com/7mind/izumi/
Pros: Gives a real work indicator of performance with very low risk. Data could be truncated and then backfilled before the final release.
Cons: not always possible depending on complexity or feature. Requires implementing the parallel path which carries some risk in itself.
This 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…
So I when someone suggests “we can build X” I say yes but first we need to build “hello world”. The discussion about what constitutes Hello World is often valuable, but often ends up with examples like the article, eg "can we write a message and the recipient gets it?" "can we do one trade?" etc. These sometimes seems like trivial goals but implementing them can be surprising.
The 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…
and probably a bunch more.
Also, referred to as a "steel thread". Runs the length of the application architecture (front-to-back, top-to-bottom, whatever) of what you are building. Each new top-to-bottom feature is a new thread. Steel threads wrapped together incrementally form a cable stronger than an equivalent diameter solid cable extruded all at once. Thread akin to string, as in string testing. - NormanECarpenter