As an ex-machinist this thread title really threw me!
Thread forming instead of thread cutting gets you some of the strongest results.
Steel Threads are a powerful but obscure software design approach
21–30 of 89 posts
Re: Steel Threads are a powerful but obscure software design approach
#22Earlier quoted context omitted.
> TDD, which assumes how an API is going to be used, I think you misunderstand TDD.
If 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.
That 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?
Re: Steel Threads are a powerful but obscure software design approach
#23> 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?
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…
I 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.
Re: Steel Threads are a powerful but obscure software design approach
#24This 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
Read the fibonaci example at the end of Becks book. He does in fact start with the smallest possible PoC.
Re: Steel Threads are a powerful but obscure software design approach
#25Never 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/
Indeed, tracer bullet is immediately what I thought of from The Pragmatic Programmer.
Re: Steel Threads are a powerful but obscure software design approach
#26[dead]
Re: Steel Threads are a powerful but obscure software design approach
#27The Pragmatic Programmer book, published 1999, calls this "tracer bullets". Topic 12 in the book.
Re: Steel Threads are a powerful but obscure software design approach
#28> 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?
Because you don't have access to a time machine, usually.
Re: Steel Threads are a powerful but obscure software design approach
#29This 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.
Re: Steel Threads are a powerful but obscure software design approach
#30> 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?
I just replaced this with "let's say you're modularizing a portion of your monolith"
Also optimize in-process before going out-of-process