Accidentally Load Bearing
30Andrew Tate
15Andrew Antes
10Ericf
21jefftk
9Ruby
7Gunnar_Zarncke
7Algon
17jefftk
6Haiku
6G Wood
5Roger Scott
3Anna M
3utilistrutil
3markapeaty
5Davidmanheim
1Self
1David James
1Review Bot
New Comment
Hyrum's Law
With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
I suppose "observable behaviors" includes "emergent" observable behaviors.
Curated. I worry a little that this a bit "insight-porn-y", but Chesteron's Fence is enough of a favorite concept that I appreciate elaboration upon it. It might be the case that "Kaufman's closet" saves me/someone from a grave mistake someday.
In software, Architectural Decision Records (ADRs) can help make both clear - why something was added and what happened later to it.
I made a tweet about this post. Should I delete it? Here's the link: https://twitter.com/Algon_33/status/1679550677373034505.
No need to delete, or even ask me. It's fine to discuss anything I write publicly.
(I think it being fine is also the default for all of LW, not just my writing)
If someone did want you to delete the tweet, they might first need to understand the original intent behind creating it and the roles it now serves.
(Hehe.)
In software engineering things often become "accidentally load bearing" when people don't respect interfaces. If they go digging around in a component's implementation they learn things that happen to be true but are not intended to be guaranteed to be true. When they start relying on these things it limits the ability of the maintainer of the component to make future changes. This problem is exacerbated by under-specified interfaces, either when formal specification mechanisms are underutilized or, more often, due to the limits of most formal interfaces specification mechanisms, when important behavioral aspects of an interface are not documented.
Reminds me of an old story about developing a FEM flutter simulation code that went through ONERA, DLR, and a bunch of other institutions and programmers using different languages. There was a line with a desperate comment: "I don't know what this loop is for, but I tried removing it and everything falls apart."
Having been born ignorant I am not much surprised that I had never heard of Chesterton's Fence but it certainly seems wise, as does the augmented view provided by the writer. I'm thinking that much of biological evolution has occurred in an analogous fashion, for example the word "appendix" comes to mind. In relation to cultural evolution I think patriarchy is a baleful instance of just such a Chestertonian fence that has indeed accreted all sorts of dysfunctional attachments which will never be fixed until it is everywhere tipped over and relegated to historical museums.
I think a related concept gets at even more of the point you're making: https://www.lesswrong.com/posts/NQgWL7tvAPgN2LTLn/spaghetti-towers
I'd say Accidentally Load Bearing structures are (statistically speaking) always the work of another optimizer: - someone saw the structure, and built another (architectural, behavioral,) structure on top of it.
So the key question is whether or not this structure may at some point have seemed useful to someone. (In a way that can be retrospectively broken.)
I think the post loses out on mental succinctness not explaining this.
1Not necessarily an optimizer, though: satisficers may do it too. A core piece often involves tradeoffs, such as material efficiency versus time efficiency.
The LessWrong Review runs every year to select the posts that have most stood the test of time. This post is not yet eligible for review, but will be at the end of 2024. The top fifty or so posts are featured prominently on the site throughout the year.
Hopefully, the review is better than karma at judging enduring value. If we have accurate prediction markets on the review results, maybe we can have better incentives on LessWrong today. Will this post make the top fifty?