Sounds 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.
Steel Threads are a powerful but obscure software design approach
31–40 of 89 posts
Re: Steel Threads are a powerful but obscure software design approach
#32The 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?
Re: Steel Threads are a powerful but obscure software design approach
#33See also Walking Skeleton https://wiki.c2.com/?WalkingSkeleton
Re: Steel Threads are a powerful but obscure software design approach
#34> 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…
This is not correct.
Not all the options are equal.
It's possible to soundly define, verify and instantiate big modular contexts.
Re: Steel Threads are a powerful but obscure software design approach
#35This 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…
On the subject of TDD, the way I've done TDD has been very similar to the technique described in the article. Work in very small increments, try to get a very thin vertical slice of functionality working through the system as soon as possible and, whatever you build, try to get it working end-to-end as soon as you can. Of course, I use tests to drive the work but I find it very helpful to use tests to drive those thi…
I don't remember where I heard this, but the method was described to me using the story of how a suspension bridge is built: first an arrow with twine tied to it is shot from one side of the canyon to the other. Then that twine is used to pull thicker twine, then rope, then steel cables, and so on. From a string to a suspension bridge, with the gap between the canyons conquered the entire time. To achieve large scale software projects, start with the thinnest logical twine that goes from start to finish for the project at hand, and build out with a start to finish operating environment as soon as possible and throughout the duration of the project.
Re: Steel Threads are a powerful but obscure software design approach
#36Earlier 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.
You 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.
Re: Steel Threads are a powerful but obscure software design approach
#37It'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.
Re: Steel Threads are a powerful but obscure software design approach
#38[dead]
Re: Steel Threads are a powerful but obscure software design approach
#39Earlier quoted context omitted.
On the subject of TDD, the way I've done TDD has been very similar to the technique described in the article. Work in very small increments, try to get a very thin vertical slice of functionality working through the system as soon as possible and, whatever you build, try to get it working end-to-end as soon as you can. Of course, I use tests to drive the work but I find it very helpful to use tests to drive those thi…
I don't remember where I heard this, but the method was described to me using the story of how a suspension bridge is built: first an arrow with twine tied to it is shot from one side of the canyon to the other. Then that twine is used to pull thicker twine, then rope, then steel cables, and so on. From a string to a suspension bridge, with the gap between the canyons conquered the entire time. To achieve large scale…
I use this metaphor all the time!
Re: Steel Threads are a powerful but obscure software design approach
#40The 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.