Be a Developer, not a Blender

The Broken Window Theory

Imagine that a Scientist stops a car in a neighborhood for a week; when the Scientist comes back the car is normal, without a problem. The Scientist breaks a window and return one week later, he finds the car all vandalized.

Imagine a building that now has nobody living in it, but its facade is with a pleasing view. Once its windows start to break, the build will be vandalized.

Unfortunately the broken window theory is found in code as well. It is easy to find an “ugly” code and make it “uglier”. What would be the problem of adding one small “if” in a method with 300 lines?

There are some aspects that could generate a broken window problem in your project.

Keep your build working

When a build is not working a developer will think that the project is not organized.

Avoid manual configurations, details that can stop a build, e.g.: a specific file in a folder or an environment variable.

The solution to this kind of problem is to have a default value, a value that could always be used. If a default value is not possible, print a message that is easy to understand describing the error. Do not add a hidden line in a log, add something like:

log log log log log log log
log log log log log log log

If the project has an error that is easy to understand, it will be easier for the developer to solve the problem; after the first problem is solved the developer will look for other problems trusting that error logs will help. A broken build is harmful to the project, a new developer will think that the project is a mess.

Do not leave your tests breaking

The problem in committing your code with just one broken test, is that when a another test breaks no one will notice it.

When you have a project with broken tests the developer will start to “skip” the test to create a build. When we skip a build a new bug could be introduced and we would not know.

ps.: if your manager says that you must do the commit with a broken test, ask him to send an email saying so. Always remember: protect yourself.

Do not comment/ignore your tests

It is a problem if in your project the developers start commenting your tests (//@Test) or ignoring it (@Ignore).

An ignored/commented test has a huge possibility of being forgotten, a forgotten test will be an open door for a bug to “reappear” in the project.


Be zealous for your code. Do not abandon your project or broken windows will appear.

2 thoughts on “Be a Developer, not a Blender

Leave a Comment