Steel Threads are a powerful but obscure software design approach
1–10 of 89 posts
Re: Steel Threads are a powerful but obscure software design approach
#2[deleted]
Re: Steel Threads are a powerful but obscure software design approach
#3How 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.
Re: Steel Threads are a powerful but obscure software design approach
#4This 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.
Re: Steel Threads are a powerful but obscure software design approach
#5This 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…
You 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.
Re: Steel Threads are a powerful but obscure software design approach
#6I 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.
Re: Steel Threads are a powerful but obscure software design approach
#7How 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.
It'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.
Re: Steel Threads are a powerful but obscure software design approach
#8Pro: 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.
Re: Steel Threads are a powerful but obscure software design approach
#9> 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?
Re: Steel Threads are a powerful but obscure software design approach
#10How 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.
It'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.
Or - it sounds like spaghetti, but ordered into a sounder structure