Chesterton Fence: Don’t Destroy What You Don’t Understand!

preview_player
Показать описание
Chesterton’s Fence is a simple rule of thumb that suggests you should never destroy a fence, change a rule, or alter a tradition if you do not understand why it was created in the first place. China’s Four Pests Campaign during the Great Leap Forward shows the tragic consequences of meddling with things we do not fully understand.

SUPPORT us to help understand human beings better!

DOWNLOAD video without ads and background music 🤫:

SIGN UP to our mailing list and never miss a new video from us 🔔:

SOURCES and teaching resources 🎓:

VISIT our website 🌐:

CONTRIBUTE by upvoting your favorite topic or suggesting new ones☑️ :

THANKS to our patrons

COLLABORATORS
Script: Jonas Koblin
Artist: Pascal Gaggelli
Voice: Matt Abbott
Coloring: Nalin
Editing: Peera Lertsukittipongsa
Production: Selina Bador
Fact-checking: Ludovico Saint Amour Di Chanaz
Sound Design: Miguel Ojeda

SOUNDTRACKS
On Eggshells - Richard Canavan
Terror Avenue - Jack Pierce
Cheeky Plum Fairy - Shaun Frearson

DIG DEEPER with these top videos, games and resources:
Read about the Chesterton’s Fence and second order thinking

On the longevity of ideas, see The Lindy Effect

On unintended consequences read about the Butterfly Effect and Chaos Theory

Read about outdated or weird laws in the US, the UK and around the world

SOURCES

CLASSROOM ACTIVITY
Visit our website to find suggested exercise on this topic!

CHAPTER
00:00 Introduction
00:17 Chesterton's principle
00:48 Chesterton Fence in business
01:30 Tragic example from China
02:42 Conclusion
03:35 What do you think?
03:59 Patrons credits
04:08 Ending

#sproutsschools #principles #chesterton #learning #laws #rules #sociology #psychology #history #tradition
Рекомендации по теме
Комментарии
Автор

"Chesterton's Fence" is from an essay by G. K. Chesterton, not F. K. Chesterton, as we stated in the video. Please excuse the typo.

sprouts
Автор

Chesterton's fence is not about never destroying the rules but a call to understand the intent and purpose behind the rule so that you can make intelligent changes. Understanding the rule leads to the follow up questions of "Is it working as intended?", "If it needs replaced, what can I replace it with?", "Does it simply need abolished?", and "How do I make this work better?"

ianbelletti
Автор

My friend used to work for a company and his office timings was 9:00 AM to 6:00 PM, also they gave a relaxation of 20 minutes if at all they come late due to traffic. most of the employees arrived before 9:10 and few of them before 9:20. But all of them used to work until 7:00 PM plus and sometimes for few extended hours.
The new HR policy thought to make the timing to be exact 9:00 AM and a circular was issued and as usual few employees requested HR to review the policy, but they just indirectly told they they are paying for your job from 9:00 AM so you all should be here by 9:00 AM or it will be absent this is the company policy.
And i think the readers have already guessed the outcome, yes the employees followed the rule strictly, they all came before 9:00 AM and left exactly at 6:00 PM.
obviously the project progress has declined, and when management asked employees why they are not completing the work before deadlines, they simply responded by saying we are paid to work till 6:00 PM only.
the management realised the mistake and reversed the policy.
But most of the employees strictly adhered to 9:00 AM to 6:00 PM and never stayed back.

raghukiran
Автор

This is so true. I was a mainframe programmer for 40 years and I always presumed that code was there for a reason unless I discovered otherwise. At my second job there was a program that called a subroutine (of another language) to handle an array. It puzzled me, but I left it alone. Eventually it dawned on me that the original programmer didn't know how to handle arrays in the main language, so he used the language he was familiar with. I rewrote that piece and got rid of the subprogram.

On a different note, my older house has an upstairs porch over the driveway that I tore down because it was rotting. I dawdled about replacing it. Part of the reason was cost, but I was also nervous because only two 4x4s braced it. Over time (years) it dawned on me that the porch had been too big. The previous owners must have made it larger (I found the old railing in the garage). It needed to be smaller, just for shaking rugs and such. When my contractor rebuilt it, he put vertical boards against the house so that the angle 4x4s would lock into it. That resolved my other concern.

These stories are different but share a theme: given time and thought, I figured out exactly what the situation was and how it got that way. So when I took action, I was confident that I was doing the right thing.

SIde note: I read a story long ago where a woman was cooking a ham and cut the ends off first. Why? Because her mother did. They traced it back to the grandmother, who said, "Because it wouldn't fit in the pan." So sometimes the original reason no longer exists, but the tradition continues.

Paul_Wetor
Автор

As an engineer working on a program that has been around for a long time, we have a saying: “No until you know.”

jakelilevjen
Автор

This is a good lesson, I always found that just telling people to blindly follow the rules may lead to them disregarding them when inconvenient, but if you explain the reason they exist they might be more inclined to follow them, or at least be better able to choose when they don't apply in a given situation, or when a better solution that performs the same goal exists.

MindCaged
Автор

This was a timely video. Violation of the “fence” bankrupted the last company I worked for. CFOs, freshly minted MBAs, social policy reformers, and especially lawyers, accountants, and financial advisors taking over new accounts.

What’s sad is when they have the architect of the fence in front of them but instead of engaging with the architect, they disparage the architect in cathartic, willful ignorance and air of self-righteousness.

chamuuemura
Автор

I worked in Construction for many years growing up before getting into software development Chesterton Fence is perfectly displayed in the real world in both professions. You will have coders or tradesmen come across someone else's "custom" work and have no clue why it's there. Rather than take the time to investigate, they start tearing things out and "improving" things only to create new problems in hindsight. You can argue that "it should have been done "right" the first time", but some solutions are unique not just to a situation, but a specific function that creates positive effects. Example: You come across some "Old code" and remove it for something new. Well the code might be newer and better but now all the older systems that used your code are incompatible or creating errors. Now you either have to patch or revert. I know some people will say "why do that want that old stuff?" There are many reasons. Simplicity. Reliability. End User Preference. This is especially true when dealing with older clients.

SSingh-nrqz
Автор

I think the key is for people to "question" things with genuine curiosity and never accept "because this is how we've always done it" as an answer. This lets us revisit the reasons for why things are the way they are, and examine if those reasons are still relevant. And maybe they are, but at least then we're actively choosing to keep things as they are, and not just forgetting to change them.

sirgregoryadams
Автор

A similar rule I've heard is: "Good advice comes with an explanation, so you can tell when it becomes bad advice." That would be analogous to a sign on the fence explaining its purpose, so people wouldn't have to guess/think/research why it was up.

TyphinHoofbun
Автор

Tradition is your shield and progression is your sword. Learn to wield both or fall with nothing.

joshuawadsworth
Автор

"Tradition is the solution to problems we forgot we had."

Terminarch
Автор

25 years ago I was a supervisor in banking operations at a midsized US bank. One day I got a new boss. His philosophy was to break down fences without understanding the reason for the fence. I think his underlying motivation was his annual bonus and that there was at least a 50/50 chance that something very good would come out of breaking down the fence. When by sheer luck something good would come out of breaking down the fence he would communicate his triumph to his boss. When something very bad happened by breaking down the fence he would leave the mess for others to clean up and not so coincidentally, he would leave the defeat out of hit the reports that he would provide to his boss. I vote understand what you are destroying before you destroy it. It doesn’t take very long learn about what are contemplating destroying.

fredwoodson
Автор

In the coal mines if a mechanic was called out for a breakdown during the night, he was awarded a free breakfast and a cup of tea. The accountants put a stop to this so the guys felt devalued and refused to turn out for breakdowns. We then lost millions of pounds in lost production because the machinery was standing idle. Pennies saved and millions of pounds lost.🤷🏻‍♂️

patrickbarrett
Автор

This is also a fantastic example of respect (about other people's decisions) and trust (believing they have thought it through - which unfortunately nowadays is getting more and more unlikely. And it is a HUGE difference of *not knowing* or *not caring* about the consequences!)

mizzwitty
Автор

This is a great principle, for sure. It's important to remember that this principle isn't teaching that "old fences" should never be torn down, but rather that truly understanding the original reasons for them, and there were reasons, will help to avoid the unintended consequences of removing them. Sometimes, the original reasons, valid as they may have been, are no longer valid, but we would do well to make sure!

BobRoyAce
Автор

The worst part is, it's usually not who actually think about the purpose of the fence, who have the call to destroy it.

Alan_Skywalker
Автор

When the CFO was hired at Netscape in 1995 he tried to do the same thing, chard employees for sodas.

We were working 60-80 hour weeks as the startup was taking off like a rocket.

There was a quick response.

Knock it off or the core developers were going to walk out.

He got the message.

lohphat
Автор

Yeah, I heard of that sparrow thing. There was something similar in America but with wolves. Wolves were nearly wiped out because they were a supposed threat to human campers in Yellowstone. What actually happened was that the removal of an apex predator nearly caused the collapse of Yellowstone's ecosystem. Wolves were reintroduced and the ecosystem stabilized.

sapphirewingthefurrycritic
Автор

The Chinese sparrow example is also cited as the law of unintended consequences.

When making change, pause to check or think of any unexpected consequences.

jaybestnz