Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Steel Threads are a powerful but obscure software design approach

rubick.com

Post reply on HN
Print view View original

51–60 of 89 posts

Re: Steel Threads are a powerful but obscure software design approach

#51

Post by jollyllama »

shireboy wrote: post #42

Microsoft calls this the strangler fig pattern and recommends it for large migrations: 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…

Agreed. 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.

Re: Steel Threads are a powerful but obscure software design approach

#52

Post by PaulHoule »

There'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)

Re: Steel Threads are a powerful but obscure software design approach

#53

Post by ta988 »

prmph wrote: post #40
xmcqdpt2 wrote: post #32

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…

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.

Especially when you now have to sync two data stores and one only has a limited feature set.

Re: Steel Threads are a powerful but obscure software design approach

#54

Post by q7xvh97o2pDhNrh »

lordnacho wrote: post #29
d--b wrote: post #4

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…

That works if you are experienced in architecting these things. As with anything, if you're already pretty close in structure, you won't have as many problems adapting the PoC to the final form. If you were further away that you thought you'll end up with a bunch of inelegant hacks to reach the working state. The real problem is getting to the point where the initial solution you imagine is close to the initial PoC.

> The real problem is getting to the point where the initial solution you imagine is close to the initial PoC.

IMHO Carmack's point is closer to the standard advice given to writers (which is also true and good):

Just get something on paper that you know is somewhat workable, and then reshape it from there.

Especially in team situations (as opposed to solo coding), the effect is magical. Endless meetings and weeks of technical flailing can be skipped by just having something instead of nothing.

Although, lately I've been finding I like this approach for solo coding too. Last night I opened up a Terminal, along with a browser tab for my new coding buddy, ChatGPT. The code I got from ChatGPT was absolutely horrendous for my needs, but at least it was something — and, an hour later, I'd scrapped and rewritten everything except for a couple function names.

There's something just plain nice about keeping things moving along — about getting some more clay on the table, some more paint on the canvas, and not being shy about reworking it after that.

I think TDD tries to capture this (especially in its pair-programming ping-pong-style implementations) — but, in its haste to come up with a one-size-fits-all system, TDD glosses over the soul of what we actually do. You're getting at exactly why — it over-constrains the freedom to reshape things, and it slaps those constraints in too early.

Re: Steel Threads are a powerful but obscure software design approach

#55

Post by robertlagrant »

d--b wrote: post #4

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…

> I think is a vastly superior approach to TDD, which assumes how an API is going to be used

I think this is a function of how much you're designing up front, not of TDD itself. The stuff you design, you write tests for and then build. How much you choose to design up front (maybe almost nothing) is up to you.

Re: Steel Threads are a powerful but obscure software design approach

#56

Post by robertlagrant »

jollyllama wrote: post #51
shireboy wrote: post #42

Microsoft calls this the strangler fig pattern and recommends it for large migrations: 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…

Agreed. 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 appare…

That sounds like vertical slices.

Re: Steel Threads are a powerful but obscure software design approach

#57

Post by andonisus »

d--b wrote: post #4

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…

I take a similar but somewhat orthogonal approach.

Most of the time, any major features that require refactoring are usually around the data model and its representation in code (the existing control flow and overall flow of a request through the system is generally fine).

I will build out what I believe the new data model should be, and then just work front-to-back, updating any references and refactoring the shared state and responsibility into the new data model, clearly separating out concerns and encapsulating responsibility.

This method has proved itself time and again, and I recommend it to anyone who needs to make large changes to and existing code base. That is, start with how the kernels of data, state, and responsibility should look, and everything grows from there.

Re: Steel Threads are a powerful but obscure software design approach

#59

Post by thefourthchime »

d--b wrote: post #4

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…

I've nice to hear that. This is also how I approach building software. My goal after at the end of a V1 is that if anyone looked at the code, they would wonder where it all is, shouldn't there be more code?

I try to make the features, structure, everything as simple as possible. As you do this you'll see things that should be probably be abstracted, things you'll want to do as soon as this next part is in.

Don't do it yet, wait for that actual feature to be written, then you refactor, make a system, etc.. Don't do it prematurely. You want to wait because the longer you wait, the chance the features parameters or use case will be different, or it won't even exist. Half the requirements they think they need at the start will be side thoughts by the end.

Re: Steel Threads are a powerful but obscure software design approach

#60

Post by legulere »

How 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

Post reply on HN