Agreed! Also, the example the author gives about building a Slack clone sounds like just the tracer bullet part - there’s no replacing of existing stuff going on, like in the first example. This confused me a bit since it’s unclear whether what steel thread really refers to.
Between the dually analogized name Steel Threads and the following description:
With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case.
followed by Step 1 from the example:
Think about the new system you’re building. Come up with some narrow use cases that represent Steel Threads of the system – they cover useful functionality into the system, but don’t handle all use cases, or are constrained in some ways.
I’m left wondering what I’m doing in step 1? Am I defining a thinnest possible version of something that crosses some boundaries of a system that constitutes one important use case? What does that mean?
I am left with so many more questions.
How does one define thinness?
What is a “thinnest possible version” a version of? A use case? If so, what is a version of a use case?
What is the unuseful functionality in a system that sets the “useful functionality” distinctly apart?
Is a “use case” always a useful version? Are versions a different word for use cases?
Are there thin versions that don’t cross system boundaries?
I’m not pooh-poohing on the concept. I’ve used the development pattern that I think Steel Threads attempts to describe, and I don’t think the name Steel Threads is useful or descriptive. What I’m hearing described is more of a development pattern mixed with a release strategy, and “steel threads” makes it sound like a specific tool or implementation detail. I understand why Wikipedia removed the article.
This seems like a good pattern with an utterly terrible name. I’m never going to use or remember that name, because it doesn’t make sense to me even now, having just read an explanation of it!
Even just “agile cutover” (to make up a term) would be a better name.
Unpopular opinion from 2.5 decades of coding: Different jargons make most patterns look cool. Trial and error becomes fancy tracer bullet, piece wise upgrade becomes steel thread…
Back when GoF design pattern book was the gospel truth in design and software architecture, it sadly promoted lawyer style architects just quoting fancy pattern names to common sense approaches (BS) and appeared cool.
This feels less like a distinct pattern and more like an application of two different patterns: tracer bullets and the strangler fig pattern.
Agreed! Also, the example the author gives about building a Slack clone sounds like just the tracer bullet part - there’s no replacing of existing stuff going on, like in the first example. This confused me a bit since it’s unclear whether what steel thread really refers to.
Between the dually analogized name
Steel Threadsand the following description:followed by Step 1 from the example:
I’m left wondering what I’m doing in step 1? Am I defining a thinnest possible version of something that crosses some boundaries of a system that constitutes one important use case? What does that mean?
I am left with so many more questions.
I’m not pooh-poohing on the concept. I’ve used the development pattern that I think Steel Threads attempts to describe, and I don’t think the name Steel Threads is useful or descriptive. What I’m hearing described is more of a development pattern mixed with a release strategy, and “steel threads” makes it sound like a specific tool or implementation detail. I understand why Wikipedia removed the article.
I have literally done all of the various approaches the author mentions, and I am still left confused about what Steel Threads actually means.
I think this is a poorly-defined pattern that is better expressed in other ways.
It strikes me as tech garbage language.
That was a good read, thanks. Intensely triggering, but good.
Oh my god this is amazing.
see also
This seems like a good pattern with an utterly terrible name. I’m never going to use or remember that name, because it doesn’t make sense to me even now, having just read an explanation of it!
Even just “agile cutover” (to make up a term) would be a better name.
Unpopular opinion from 2.5 decades of coding: Different jargons make most patterns look cool. Trial and error becomes fancy tracer bullet, piece wise upgrade becomes steel thread…
Back when GoF design pattern book was the gospel truth in design and software architecture, it sadly promoted lawyer style architects just quoting fancy pattern names to common sense approaches (BS) and appeared cool.