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:
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.
Accidentally Load Bearing
Link post
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.