As a programmer I spend a lot of time in front of the computer. But despite appearances, I am not there. I am not in front of a computer every day for 8 hours drying my eyes and weakening my muscles. I am somewhere else.

I am in an amazing world of executable ideas, manipulating abstract artifacts made of concepts. I am assembling them to generate a meaningful structure in which a computer program can evolve. This world is like a city that grows as we add more behavior to it. This world has the neighborhood of repositories, the shopping cart markets, the fashion contests of views, controllers directing traffic, etc.

But this city is not mine alone. It’s built by all the people on my team. It’s a place shared with others, where our creations grow together. It starts small and simple like a village with just a few small classes, but as time passes it can evolve into a crowded city which abounds with components. Some of the neighborhoods are clean and artfully crafted with well decoupled skyscrapers, while others are rotting, under the pressure to “Deliver now!”

The Broken Window Theory

The Broken Window Theory is based on a set of experiments on abandoned cars. Researchers left a car parked in Palo Alto, Calif., where it remained intact for more than a week. After a week, a researcher returned to the car and broke a window. Once the car seemed abandoned, rather than simply parked, it didn’t take long to be vandalized and destroyed. It only took one broken window to start the process.

The theory, in a nutshell, states that social perception of how much the people around you “care” about something is an important factor in how much care you devote to the same thing. When you see litter in the streets, throwing one more wrapper doesn’t make a difference. When the streets around you are clean, you pause and question yourself.

The other part of the theory is that problems are easier to fix when they are small. What begins with a single broken window leads to more broken windows, and eventually to abandoned or bug-infested buildings. Small problems can easily become big problems if we don’t fix them quickly.

Are you contributing to the Broken Window Effect?

As a good programmer, chances are that you are really good at finding errors, or better ways to implement another developer’s code. Sometimes I find myself wondering what the dev who wrote that code was thinking, or even calling it “crap” out loud. But what happens if I don’t actually change it?

What’s the effect of highlighting something really wrong with the code, and not doing anything about it? It’s like pointing at a broken window and letting everybody know that vandalizing this neighborhood is acceptable.

Having broken code is not great, but the real danger lies in what happens when you and your team accept it as reality and nobody fixes it. Imagine the effect on new team members when everybody acts like that. It’s like an invitation to live in one of the worst parts of the city. Would you like to stay there? Would you have the courage to improve things if no one else does?

If broken windows accumulate, then at some point the gradual decay in quality of your project gets out of control. As with the Broken Window Theory, the cost of refactoring entangled code is smaller up front, but if you delay it, it quickly becomes unaffordable.

The biggest difference-maker in the quality of a project is the development team’s attitude toward improving things.

The Boy Scout rule

Good teams follow the Boy Scout rule: “Always leave the campground cleaner than you found it.” Good teams improve the environment, making it easier for the rest to add new code. Make your city better by slowly fixing one window at the time. Do it while you are adding a new feature nearby. There is no bad neighborhood for the Boy Scout rule.

One of the first steps for applying the rule is to stop ignoring the difficult code. By calling code bad, you are labeling it as code that is not worth rescuing. When you do so, you are reinforcing the idea that your neighborhood is a bad neighborhood. Being ‘crap’ is then an essential part of your code, and there is nothing you could do about it.

Instead, treat it as “unattended.” This does not state that the code is good, but it expresses your willingness to improve it. It’s a piece of software that is actually working, but is waiting for (and deserves) some attention and care.

So, now what?

If you feel like you don’t know where to start improving your city... If you see a lot of broken windows... If you know your city needs to get better... Then start taking action now.

You can encourage people to take actions by just changing the words you use. Start talking about the state of the code in a time frame (e.g. “It’s unattended for now”) and take away the idea of code being “crap.” Doing so, you generate the proper environment to apply the Boy Scout rule. Start refactoring little pieces of software when you see the opportunity, and encourage your team to do the same.

Resources:

"Is the Broken Windows Theory Effective?" - SiOWfa13: Science in Our World: Certainty and Controversy. N.p., n.d. Web. 01 Oct. 2015.