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

11–20 of 89 posts

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

#11

Post by mpweiher »

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…

> TDD, which assumes how an API is going to be used,

I think you misunderstand TDD.

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

#14

Post by foepys »

pshirshov wrote: post #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?

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

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

#15

Post by fwlr »

t344344 wrote: post #3

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

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

#16

Post by d--b »

mpweiher wrote: post #11
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…

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

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

#18

Post by radicalbyte »

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…

This is how I do TDD - first I build out the smallest possible thing (usually with code, sometimes with comments) then iterate / play around a little until I have the structure right. Then start putting tests in.

Then later in the cycle you have high-level structure so it's easier to start with the test.

We teach TDD and a lot of Software Engineering practises largely to beginners to make them productive for the maintenance of software - as that is about 95% of or work. So the flows that are stressed are those suitable to maturing/mature code not to completely new systems.

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

#19

Post by chris_j »

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…

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 thin vertical slices of functionality.

The book that really helped me to start working in this way is Growing Object Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce [0]. The book has been around for a few years at this point and tech has moved on since then, as have some of the techniques, but it's still a very interesting read. (Disclosure: I was lucky enough to briefly work with one of the authors a few years ago but I was a fan of the book long before then.)

[0] http://www.growing-object-oriented-software.com/

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

#20

Post by samatman »

TaylorAlexander wrote: post #13

As an ex-machinist this thread title really threw me!

I 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."

Post reply on HN