Accidentally Load Bearing
post by jefftk (jkaufman) · 2023-07-13T16:10:00.806Z · LW · GW · 14 commentsSometimes 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:
The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep. It is highly improbable that it was put there by escaped lunatics who were for some reason loose in the street. Some person had some reason for thinking it would be a good thing for somebody. And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious. — G. K. Chesterton, The Drift From Domesticity
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.
14 comments
Comments sorted by top scores.
comment by Andrew Tate (andrew-tate-1) · 2023-07-18T04:36:41.199Z · LW(p) · GW(p)
Can we term this 'Kaufman's Closet' ?
comment by Ericf · 2023-07-14T18:59:46.438Z · LW(p) · GW(p)
Obligatory xkcd: https://xkcd.com/2347/
Replies from: jkaufman↑ comment by jefftk (jkaufman) · 2023-07-14T23:02:47.742Z · LW(p) · GW(p)
Alternatively: https://xkcd.com/1172/
comment by Andrew Antes (andrew-antes) · 2023-07-20T15:32:09.759Z · LW(p) · GW(p)
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.
comment by Ruby · 2023-07-20T07:53:21.690Z · LW(p) · GW(p)
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.
comment by Algon · 2023-07-13T17:58:35.074Z · LW(p) · GW(p)
I made a tweet about this post. Should I delete it? Here's the link: https://twitter.com/Algon_33/status/1679550677373034505.
Replies from: jkaufman, Haiku↑ comment by jefftk (jkaufman) · 2023-07-13T18:02:49.077Z · LW(p) · GW(p)
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)
comment by Gunnar_Zarncke · 2023-07-14T16:41:17.925Z · LW(p) · GW(p)
In software, Architectural Decision Records (ADRs) can help make both clear - why something was added and what happened later to it.
comment by Anna M (anna-m) · 2023-08-17T18:44:50.874Z · LW(p) · GW(p)
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."
comment by Rocket (utilistrutil) · 2023-08-13T01:40:13.496Z · LW(p) · GW(p)
This happens in chess all the time!
comment by markapeaty · 2023-07-22T07:41:41.548Z · LW(p) · GW(p)
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.
Replies from: Davidmanheim↑ comment by Davidmanheim · 2023-07-31T19:10:17.852Z · LW(p) · GW(p)
I think a related concept gets at even more of the point you're making: https://www.lesswrong.com/posts/NQgWL7tvAPgN2LTLn/spaghetti-towers [LW · GW]
comment by Roger Scott (roger-scott) · 2023-07-20T14:35:46.303Z · LW(p) · GW(p)
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.