# A Fence, a Deviance and a Window

2022-09-24

Imagine you’re joining a new role and see something that makes you go “wtaf did they think when they did this?!” - what’s the first thing you do?

If your answer is “change it,” then chances are you’re wrong. To explain why, let’s visit a fence, a deviance and a window.

As software engineers, our initial drive is to 👏🏻solve👏🏻all👏🏻the👏🏻problems👏🏻… but what looks like a problem isn’t necessarily one.

Chesterton’s Fence essentially says “there’s a fence, you don’t know why, don’t go removing it before understanding it.”

We’ve got three things we need to look at:

### Why do we even want this fence removed?

If it ✨feels✨ intuitively right, what is that intuition based on?

We owe it to ourselves to understand where the impulse is coming from, so that we can explain it. We might just be wrong.

### Why is this fence up in the first place?

You might get a good explanation. You don’t have to agree, but it might still be good.
Or you might not. Still not good enough of a reason to make the change, best go read the next question:

### Why is this so far from “normal” for us?

When a group of people has been together alone for long, they s-l-o-w-l-y deviate from what seems normal or standard. It’s not because of malice or incompetence, but because they’ve been in an echo-chamber and this naturally occurred.

People joining the group don’t share that “deviance”, and have a Beginner’s Mindset, so they’re primed to detect it. You may have found one.

SO CAN I FIX IT NOW ALREADY?!

Nope, wait a second, are you sure it’s unjustified? It might just be that you don’t have enough context.

Whenever a new engineer joins us, I recommend they open a private doc named My Gripes Doc and start recording the reason every time they go “wtf”. Then, as they learn and understand, go back to it and re-examine it.

I still do that with mine, nearly two years into my current role.

Now let’s assume, after all of this introspection and gathering of context, that you’ve decided this needs changing.

### Fix it…?

If you own it - decide when to fix it, then - and this is an important part - share that you will. Then go ahead and do it.

However, if you have to persuade others, first figure out if it’s in the Overton Window.

The Overton Window (and Treviño’s degrees of acceptance) are terms from Political Science, that model “what is an acceptable position?”

It’s a tool to help you understand whether the change you’re about to propose will make people simply disregard it.

Let’s assume the change you want to make, for someone living the normalized deviance, is Sensible. Won’t be a hard sell, right? On the other hand, if you’ve done your research, and it’s too Radical, stop and think how you can first move the Window.

To do this, find good ideas at the edge of the window, get buy-in and change the way people think about the general direction. This will slowly move the Window, letting you go ahead with the original change.

FYI, the need to move the Window is not terribly common.

Here’s a simplistic example: Everyone uses Hungarian Notation (oh no) and name their variables strStreetAddress and intCount. Terrible. How do we get them off that?

Let’s say we found it’s Unthinkable. No way people are just going to change. But it seems no one cares what IDE you use.

So let’s take an IDE that annotates types without changing the source code:

Now it’s time to show this off to everyone and wow them with your kick-ass IDE. No longer will you have to type the names of types as prefixes!

Assuming you’ve done this well, you’ve 🎊successfully shifted the Overton Window🎊. People no longer consider ditching Hungarian Notation that crazy, because there’s a good (better?) alternative. You’ve successfully made this Acceptable, Sensible or even Popular.

So we talked about how, when you want to drive change, you should first understand why Chesterton’s Fence is there, whether this is Normalized Deviance and how to think about the Overton Window to successfully drive that change.

Go forth and make that change happen!