Broken windows and broken code

Have you ever walked through a forest and suddenly encountered something akin to an elephant cemetery for white goods? A place where washing machines wander with melancholic steps when they notice that the centrifugal force has subsided, look around and then turn themselves off for the last time while the wind whirls the smell of washing powder and fabric softener into eternity? How can it be that all this junk ends up right here? And what does a theory named after a broken window have to do with this?

Photo by Jeremy Bishop on Unsplash

Is it really that important?

I was looking through a PR from a junior developer. He had given a component that would display the contents of a table cell the name ClientInfoTD. That should not be a problem, except for the fact that all the other components that rendered cells in this code base ended with Td — i.e. with the second letter in lowercase. I scrolled up and looked at the other feedback I had given this relatively new developer, and my teacher’s heart implored me, saying “you’ve already given so much feedback. Is one little letter in uppercase really that important?”

A broken window

In 1969, a researcher named Philip Zimbardo conducted an experiment. He parked a car in a wealthy California neighborhood and left it there. For the first few weeks it was left alone. Then Zimbardo went over to it and smashed one of the windows with a hammer. After that it only took 24 hours and the car was completely destroyed and everything of value had been stripped from it.

Where I grew up, we could often find a football without air lying around on a playground or football field. When an object is damaged, and this damage is not fixed within a reasonable time, it broadcasts a message that the owner, if she exists at all, does not care. Like this football — or the car with flat tires that has been standing down the street for months, the area of ​​the forest where everyone puts their broken appliances, or the code where everyone has been allowed to write names of variables and functions exactly as they want.

Photo by Jeremy Bishop on Unsplash

The theory that the aforementioned Zimbardo investigated has become known as “The broken window theory”. Among other things, it led to the police punishing seemingly small things earlier on, because they realized that it is much easier to stop something while it is still in its infancy. It is more difficult to draw graffiti on a completely clean wall than on one which already says something obscene — so keep it clean. It is much easier to take the damaged refrigerator out into the woods if there is already a stove there that can keep it company — so take away the first stove as soon as possible. As Zimbardo says: “there is considerable reluctance to take that first blow, to smash through the windshields and initiate the destruction of a form”. “The seconds blow”, on the other hand, is suddenly a lot simpler.

Broken code

In what way, then, is this relevant for us who work in development? I once took over a code base where almost all of the business logic was in global functions in one enormous file with over 5000 lines. Further down the road, I discovered that, among other things, code that was to tackle boats was copied from code that handled cars, but the variable name had not been changed from car to boat.

I do not know the history of this code, but I have a hard time believing that it started there, although that is certainly a possibility as well. It probably started with something small — like the naming convention. As soon as the developers realized that naming didn’t matter, the road to choosing the path of least resistance became shorter in other matters as well. We all probably know how tempting it is to put a function into a file that already has too many already — that file must be fixed at some point anyway — instead of finding a more suitable place. After this vicious circle had been going on for a while, fewer and fewer people cared about the code. It had become a wall covered with graffiti, with broken glass across the floor and a stench of spaghetti code. A wall that is difficult to feel proud of, and one very few people want to take ownership of. After that the race is over. No one cares anymore, and the desire to just throw the code out and start over becomes stronger and stronger.

The angry developer

Reluctantly, I pushed the little teacher who had sat down on one my shoulder away and gave a high-five to the angry developer on the other one. Then I wrote a piece of feedback stating that it was important to use the same naming convention everywhere in the code. Such a small difference may in fact be the first small crack in the code base window.

So what can we do to avoid breaking windows in our code? I think there are two answers:

1. We must be uncompromising when it comes to code quality in both big and small matters. Here, the senior developer, who knows and has experienced both what good and bad code looks like, has a special responsibility towards the juniors who will inevitably make mistakes without being aware of it. Do not take code reviews lightly!
2. Furthermore, we must not allow bad choices, big or small, to gain a foothold in our code. Making mistakes is allowed, but when we discover that something is wrong or not ideal, time should be set aside to do something about it as soon as possible before the team gets used to the way the code is. As the frog is slowly being cooked without noticing it, our view of the code will change from “this code is good”, to “this code is good — except for X” to “there are some errors in this code, and no one plans on doing anything about it ”. Before we know it, the code has become the dreaded classic: “I pity the person who has to take over this code after me”.

Bear in mind that the person who takes over that code, could end up being someone you care about !