9 ms·
Steel Threads are a powerful but obscure software design approach
- deleted 4y ago[deleted]
- t344344 4y agoHow is that different from agile, TDD and refactoring? > A steel thread is a very thin slice of functionality that threads through a software system. They are called a “thread” because they weave through the various parts of the software system and implement an important use case. This sounds awfully like spaghetti code.
- vkou 4y agoIt's not spaghetti, it forces you to think about how the various layers are going to integrate, with a real-world testcase before you've written so much code that making corrections necessary to fix any abstraction errors you have made is painful.
- miceeatnicerice 4y agoOr - it sounds like spaghetti, but ordered into a sounder structure
- fwlr 4y agoIt seems possible to do agile, TDD, and/or refactoring all without this practice of “following a single use case from start to finish throughout the entire application”. That’s all this is, an evocative name for the suggestion that taking a single use case through the entire system from beginning to end, implementing just what’s necessary at each step, is a good way to program. I think it has benefits but you also hit on the biggest risk, if you aren’t careful you’ll end up writing spaghetti code, except now your spaghetti is made of steel which is way harder to untangle.
- d--b 4y agoThis 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 used, without actually writing the actual thing that's going to use it.
- thom 4y agoYou can (and perhaps should!) do this with TDD, you just start with functional tests instead. Only commit to unit and integration tests when you know you’re not going to be throwing lots of stuff away through refactorings.
- mpweiher 4y ago> TDD, which assumes how an API is going to be used, I think you misunderstand TDD.
- d--b 4y agoIf you write tests first, you don't write a complete front to back "thread" first, right? If you write tests first, you assume that the test is going to match how you're going to use the stuff in a real situation, which you generally don't know.
- zidad 4y agoThat complete front-to-back 'happy path' test is exactly what I would normally start with as a first test, and it should of course be representative of how you are going to use it in a real situation. Not sure what kind of tests you write if they don't represent the actual expected behavior?
- mpweiher 4y agoYou don't write production code unless there is a need for it. The need is documented in a failing test case. Where does the failing test case come from? Hopefully from some other part of the code needing that code to be there. Or are you just conjuring up test cases out of thin air? If you're doing that, I'd venture you're not doing TDD. And certainly doing a spike to get the lay of the land is very mach part of XP where TDD came from. As is slicing your system vertically, so complete units of functionality within an incomplete system. Rather than slicing horizontally, which is what you seem to be doing.
- fedeb95 4y agoI didn't know this way to operate was called such, but it's the only way a sane person (i.e. someone who has to replace a monolith with smaller services AND do maintenance on the result) would.
- MauranKilom 4y agoPro: Quick feedback cycle, particularly with how the new software fits the requirements. Some would call it agile. Con: Early design decisions are the hardest to change. For example, retro-fitting security (or parallelism) onto a system that was not designed with it in mind is a fool's errand.
- pshirshov 4y ago> Let’s say you’re building a new service to replace a part of your monolithic codebase. Why would I do that instead of building good configurable monoliths?
- foepys 4y agoAs 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 was: since every option was global, people used options for things they weren't supposed to be used for across multiple modules. I worked at a company with over 15,000 options in their on-prem monolith. Nobody can know about all of them and each consultant demanded more and more customer-specific options. It was a nightmare and we tried to get the mess sorted with a plugin system where each plugin had their own options that couldn't pollute the global configuration. But it was very hard, very painful, and in the end we could only eliminate a few thousand global options.
- jsrcout 4y agoI think the developers of the system I work on used your product:-). Although I don't think it has plugins. They said that in the early days they brought in a vendor engineer for a week to configure it. Currently the main config file is over 3K lines and some variants are close to 10K.
- pshirshov 4y agoThis 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/ https://github.com/7mind/izumi/
- sokoloff 4y agoThings that are possible are frequently not the default condition.
- mpweiher 4y agoHmm... http://wiki.c2.com/?SpikeDescribed http://wiki.c2.com/?SpikeDescribed
- TaylorAlexander 4y agoAs an ex-machinist this thread title really threw me!
- samatman 4y agoI 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."
- ochoseis 4y ago“Marketing driven development”
- mikewarot 4y agoThread forming instead of thread cutting gets you some of the strongest results.
- iamflimflam1 4y agoNever heard it called this before. We used to describe this as a tracer bullet through the system. https://flylib.com/books/en/1.315.1.25/1/ https://flylib.com/books/en/1.315.1.25/1/
- voiper1 4y agoIndeed, tracer bullet is immediately what I thought of from The Pragmatic Programmer.
- black_13 4y ago[dead]
- sampo 4y agoThe Pragmatic Programmer book, published 1999, calls this "tracer bullets". Topic 12 in the book.
- sveme 4y agoSounds like a very common approach - build a small atomic feature front to end, test it, expand on top of that. This is, for example, the suggested approach in the Shape Up process. Works quite well for my team.
- xmcqdpt2 4y agoThe 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 thing? It's not clear to me what the qualitative difference is that requires the introduction of new terminology?
- prmph 4y agoExactly, 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.
- iandanforth 4y agoAgree, when I'm looking to pull out a service I'm often looking for state boundaries. Is there some part of state or a data model which is separable? If so I can abstract around that and pull it out. If I try to pull out something smaller then I end up in trying to run a service with a split-brain backing datastore, which is far more problematic IME.
- TeeMassive 4y agoThe main difference between the two is that the cutter approach means that the two features must coexist at more or less the same place in the code and that the architecture must be adapted to accommodate this half-dead half-alive chimera. In the end you have three states two deal with with the code before the new feature, the chimeric code and then the code with the new code enabled. With the steel thread approach the feature exists on its own and is used and tested in production at the very beginning, although with limited traffic first. Important to note that the author seems to assume a micro-service architecture.
- asplake 4y agoSee also Walking Skeleton https://wiki.c2.com/?WalkingSkeleton https://wiki.c2.com/?WalkingSkeleton
- jmull 4y agoIt's saying switchovers, when refactoring a system, can be hard, with a big risk of unforeseen complications. So identify as narrow a case as you can, implement that first, and once that's good, build out from there. That is, break down your problem into manageable chunks. Nothing new... the part that might not be obvious (there are many ways to break down a problem, after all) is the idea to fully deliver a narrow case. Seems pretty reasonable to me.
- tonetheman 4y ago[dead]
- hidelooktropic 4y agoThe author states Wikipedia removed the term in 2013 because it's not notable. 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.
- distcs 4y ago> The author doesn't state who came up with the term "steel thread" and I'm suspecting it was the author. That's a weird type of suspicion. A simple search yields some prior usage of this term: https://dl.acm.org/doi/10.5555/2608547.2608553 https://dl.acm.org/doi/10.5555/2608547.2608553 https://simplicable.com/IT/steel-thread https://simplicable.com/IT/steel-thread
- shireboy 4y agoMicrosoft calls this the strangler fig pattern and recommends it for large migrations: https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html 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.
- jollyllama 4y agoAgreed. I've seen steel thread used to refer to a technique in developing new applications. In this context, it means building one feature to completion before starting others. For example in web development, build a screen that uses a route and an api endpoint to fetch data from your datastore before building other screens using only mocks. Edit: the advantage of this is that any systemic problems will become apparent quicker; your earlier tasks become a proof of concept for the viability of the project as a whole.
- robertlagrant 4y agoThat sounds like vertical slices.
- jollyllama 4y agoI hadn't heard of that term before but yes it is accurate.
- sb8244 4y agoA small tweak to the "old style" plan that I'd look at is running the new service in parallel with the old but not actually taking customer facing action. For example, send all writes to the new microservice when the write happens in the monolith. 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.
- moomin 4y agoaka Tracer Bullets aka Walking Skeleton and probably a bunch more.
- dnh44 4y agoI’ve written software like this for as long as I can remember but I don’t remember ever learning it or being taught. It’s always just seemed like easiest way to compartmentalise complexity.
- smusamashah 4y agoFound it on C2 wiki. It's not exactly the same definition as in the linked article though. 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 https://wiki.c2.com/?SpikeSolution https://wiki.c2.com/?SpikeSolution (too bad the c2.wiki has modernized the UI, its now almost unusable)
- PaulHoule 4y agoThere's the general agile principle that you implement complete features end-to-end on a regular basis. (e.g. a "user story") It's arguable, but I'd say the definition of a good software design is that it makes the above straightforward (e.g. testing, DRY, ... are means to that end)
- tpoacher 4y agoSounds like a better name would have been "the Theseus Ship approach".
- legulere 4y agoHow is this different from the relatively well-known concept of a minimum viable product? > A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. https://en.wikipedia.org/wiki/Minimum_viable_product https://en.wikipedia.org/wiki/Minimum_viable_product
- chaboud 4y agoThe article starts with stating a desire to bring the term "Steel thread" back to Wikipedia, formerly removed for the term's lack of use in the industry. After reading the linked article, I'm actually more convinced that removal was the correct course of action.
- kdazzle 4y agoIsnt this just the strangler pattern? https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html Not sure I agree with the steel thread metaphor
- chubot 4y agoI call this a “vertical slice”, rather than horizontal layers Not sure steel threads is a very good name
- angarg12 4y agoI hope people will excuse my cynicism Step 1: Rehash a bunch of existing ideas together (PoC, vertical slice, strangler pattern). Step 2: Give it a flashy new name. Step 3: Market your consulting services as an expert for flashy new name. Sell to companies how they can build high performing organizations with this new technique.
- jdonaldson 4y agoThe problem with steel threads is that they take only a single path through a series of components. Rather than building something robust, you're more or less wearing a rut through the implementation strategy for a single service, and piling on use cases as you go. This is more or less how you end up with b2b "get 'er done" software, and you have to ask yourself if that's what you want.
- grandinj 4y agoSounds like XP's (eXtreme Programming) Spike Solution
- carterschonwald 4y agoThis sounds like monad transformers in Haskell. But fuzzier
- paulrpotts 4y agoI think the concept is good, but the name is pretty bad - I mean, we have "green threads," "POSIX threads," "kernel threads," "user threads," etc. Given that this concept from software engineering has absolutely nothing to do with execution threads, it needs a less confusing name.
- andrewshawcare 4y agoThis is the strangler (fig) pattern under a different name: https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html
- DeathArrow 4y agoThis reminds me of Vertical Slice Architecture by Jimmy Bogard. https://jimmybogard.com/vertical-slice-architecture/ https://jimmybogard.com/vertical-slice-architecture/
- rbanffy 4y agoI think this is a very used technique, but I was unfamiliar with the name.
- lfpeb8b45ez 4y agoWhere 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.
- airbreather 4y agoWe 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.
- steponlego 4y agoThis sounds like it was written with AI assistance.