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.
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, Architectural Decision Records (ADRs) can help make both clear - why something was added and what happened later to it.
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
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.
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?
Sometimes people will talk about Chesterton's Fence, the idea that if you want to change something—removing an apparently useless fence—you should first determine why it was set up that way:
Figuring out something's designed purpose can be helpful in evaluating changes, but a risk is that it puts you in a frame of mind where what matters is the role the original builders intended.
A few years ago I was rebuilding a bathroom in our house, and there was a vertical stud that was in the way. I could easily tell why it was there: it was part of a partition for a closet. And since I knew its designed purpose and no longer needed it for that anymore, the Chesterton's Fence framing would suggest that it was fine to remove it. Except that over time it had become accidentally load bearing: through other (ill conceived) changes to the structure this stud was now helping hold up the second floor of the house. In addition to considering why something was created, you also need to consider what additional purposes it may have since come to serve.
This is a concept I've run into a lot when making changes to complex computer systems. It's useful to look back through the change history, read original design documents, and understand why a component was built the way it was. But you also need to look closely at how the component integrates into the system today, where it can easily have taken on additional roles.