Here’s a pattern I’d like to be able to talk about. It might be known under a certain name somewhere, but if it is, I don’t know it. I call it a Spaghetti Tower. It shows up in large complex systems that are built haphazardly.
Someone or something builds the first Part A.
Later, someone wants to put a second Part B on top of Part A, either out of convenience (a common function, just somewhere to put it) or as a refinement to Part A.
Now, suppose you want to tweak Part A. If you do that, you might break Part B, since it interacts with bits of Part A. So you might instead build Part C on top of the previous ones.
And by the time your system looks like this, it’s much harder to tell what changes you can make to an earlier part without crashing some component, so you’re basically relegated to throwing another part on top of the pile.
I call these spaghetti towers for two reasons: One, because they tend to quickly take on circuitous knotty tangled structures, like what programmers call “spaghetti code”. (Part of the problem with spaghetti code is that it can lead to spaghetti towers.)
Especially since they’re usually interwoven in multiple dimensions, and thus look more like this:
“Can you just straighten out the yellow one without touching any of the others? Thanks.”
Second, because shortsightedness in the design process is a crucial part of spaghetti machines. In order to design a spaghetti system, you throw spaghetti against a wall and see if it sticks. Then, when you want to add another part, you throw more spaghetti until it sticks to that spaghetti. And later, you throw more spaghetti. So it goes. And if you decide that you want to tweak the bottom layer to make it a little more useful – which you might want to do because, say, it was built out of spaghetti – without damaging the next layers of gummy partially-dried spaghetti, well then, good luck.
Note that all systems have load-bearing, structural pieces. This does not make them spaghetti towers. The distinction about spaghetti towers is that they have a lot of shoddily-built structural components that are completely unintentional. A bridge has major load-bearing components – they’re pretty obvious, strong, elegant, and efficiently support the rest of the structure. A spaghetti tower is more like this.
(The motto of the spaghetti tower is “Sure, it works fine, as long as you never run lukewarm water through it and unplug the washing machine during thunderstorms.”)
Where do spaghetti towers appear?
Basically all of biology works like this. Absolutely all of evolution is made by throwing spaghetti against walls and seeing what sticks. (More accurately, throwing nucleic acid against harsh reality and seeing what successfully makes more nucleic acid.) We are 3.5 billion years of hacks in fragile trench coats.
Scott Star Codex describes the phenomenon in neurotransmitters, but it’s true for all of molecular biology:
You know those stories about clueless old people who get to their Gmail account by typing “Google” into Bing, clicking on Google in the Bing search results, typing “Gmail” into Google, and then clicking on Gmail in the Google search results?
I am reading about serotonin transmission now, and everything in the human brain works on this principle. If your brain needs to downregulate a neurotransmitter, it’ll start by upregulating a completely different neurotransmitter, which upregulates the first neurotransmitter, which hits autoreceptors that downregulate the first neurotransmitter, which then cancel the upregulation, and eventually the neurotransmitter gets downregulated.
Meanwhile, my patients are all like “How come this drug that was supposed to cure my depression is giving me vision problems?” and at least on some level the answer is “how come when Bing is down your grandfather can’t access Gmail?
My programming friends tell me that spaghetti towers are near-universal in the codebases of large companies. Where it would theoretically be nice if every function was neatly ordered, but actually, the thing you’re working on has three different dependencies, two of which are unmaintained and were abandoned when the guy who built them went to work at Google, and you can never be 100% certain that your code tweak won’t crash the site.
I think this also explains some of why bureaucracies look and act the way they do, and are so hard to change.
I think there are probably a lot of examples of spaghetti towers, and they probably have big ramifications for things like, for instance, what systems evolution can and can’t build.
I want to do a much deeper and more thoughtful analysis about what exactly the implications here are, but this has been kicking around my brain for long enough and all I want to do is get the concept out there.
Does this feel like a meaningful concept? Where do you see spaghetti towers?
Also "Normal accidents" by Perrow may be relevant: spaghetti towers have some natural rate of crashes, not too often, as this will not allow them to be built so high, but also not very rare, as they are not designed to be stable.
Promoted to curated: I've wanted to curate this for a while, mostly because it introduces a concept in a nice and concise way, while also connecting it to existing concepts and scientific disciplines. I've also found the images pretty useful and good, and I do think we have a lack of images, and see this as a good example of low-effort images increasing the quality of a post by a lot.
Suddenly very inspired with the idea of a programming language where even the most carelessly constructed spaghetti towers are fairly easy to refactor.
I want to design a medium that can be assembled into a fairly decent set of shelves by just progressively throwing small quantities of it at a wall.
I want to design tools that do not require foresight to be used well, because if you're doing something that's new to you, that challenges you- and I want to live in a world where most people are- foresight is always in scarce supply.
I would call this a good visual representation of technical debt. I like to think of it as chaining lots of independently reasonable low order approximations until their joint behavior becomes unreasonable.
It's basically fine to let this abstraction be a little leaky, and it's basically reasonable to let that edge case be handled clumsily, and it's basically acceptable to assume the user won't ever give this pathological input, etc., until the number of "basically reasonable" assumptions N becomes large enough that 0.99^N ends up less than 0.5 (or some other unacceptably low probability of success). And even with a base as high as 0.99, the N that breaks 50% is only ~70!
The visual depiction of this as parts being stacked such that each additional part is placed in what looks to be a reasonable way but all the parts together look ridiculously fragile is excellent! It really emphasizes that this problem mode can only be understood with a global, rather than a local or incremental, view.
I wonder to what extent tax codes are spaghetti towers - every time someone finds a loophole a new bit of tax code gets added to close it without considering how to make a coherent whole. This would explain how the uk tax code runs to >10,000 pages
Extending that the legislation and law in general seems appropriate as well. I wonder if one contrasts and compares slice of time views of both common law regimes and statutory law regimes if there would be any differences.
Having looked into this, it's partly that, but mostly that tax codes are written in legalese. A simple options contract for a call, which can easily be described in 10 lines of code, or a one-line equation. But the legal terms are actually this 188 page pamplet; https://www.theocc.com/components/docs/riskstoc.pdf which is (technically but not enforced to be a) legally required reading for anyone who wants to purchase an exchange traded option. And don't worry - it explicitly notes that it doesn't cover the actual laws governing options, for which you need to read the relevant US code, or the way in which the markets for trading them work, or any of the risks.
I seem to work (and possible live) in such a setting ;-)
On one level I wonder how much we need to worry. The idea behind that comment is the problem we all face with the asymmetric nature of our knowledge when facing the future. The distinction here is not to say that sloppy planning and maintenance should be consider acceptable but that we can only avoid the spaghetti to some extent. This is not to suggest the author was suggesting that. Only saying we might want to think about where the margins of efficiency are.
I was also wondering if some of the innovations in graph theory might help manage decision-making in a spaghetti world. The idea of a programming language that can help refactor the spaghetti might use such tools.
The last (actually first but...) thought I had was "Hello Gordian Knot."
Where it would theoretically be nice if every function was neatly ordered
...but another problem is this: when you build a bridge, you know in advance what you need and what you don't. Nobody (sane) will demand that you add a platform for selling Coca-Cola and a pier at the bottom with an elevator to ground level,and whatnot mid-construction. In programming, you either work for military where you will get proper specification several inches thick, or you start developing and try to accommodate for sudden requirement changes on the fly. Good programmer is better at predicting which changes are more likely and designs their code so that those are relatively easy to implement. But when redesigning from scratch is not an option and refusing to change is not an option - spaghetti tower becomes the most viable option left.
Fixed it manually. The url specified didn't have a www or an http at the beginning, which means it was interpreted as a relative URL. Not sure what I want the behavior to be here, since sometimes we do want relative URLs. Will probably just start paying attention to it and fix it whenever I see someone accidentally adding a relative URL, and if it starts happening often will change the default behavior.
Many automobiles are spaghetti towers. The longer a model or drivetrain is in production, the more spaghetti. I drive a 1985 Volkswagen Vanagon. Its ancestors had horizontally opposed four cylinder air-cooled engines in the rear, like all ancestral VWs. In 1984 the Vanagon got water cooled, but still horizontally opposed four cylinder rear-engine. The plumbing is, as they say, like a submarine. Some later Vanagon models layered onto this concept four-wheel drive and air conditioning. Talk about plumbing.
Of course, most every automobile wiring system grew from simple ignition-lights-radio-heater-fan-windshield-wipers to include airplane-like control panels, wireless entry locks, theft alarms, seatbelt buzzers, seat warmers, electric windows, seats, hatches, sun roofs, and steering-wheel adjusters. I think four fuse panels is the norm now. My modern diesel pickup truck had two batteries, two alternators, and every gizmo in the catalog, layered onto the basic automotive wiring system.