Thursday, November 29, 2007

Broken Windows theory, for software development

The Broken Windows theory goes like this:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars.
Basically, if some stuff is broken, then people will tend to break more stuff but if nothing is broken then people will be reluctant to break something.

You'll say, what does that have to do with software development? Beside the obvious joke about a certain operating system, it's a very important concept for software quality.


As any good software project, we, my team at work, have a set of unit tests and a regular build. Since we have a lot of people outside our team adding to our codebase, we like for people to run the tests before they submit their change. Here's where the Broken Windows effect come in.

People are reluctant to break something that works, but not so much when it doesn't. If the build is already broken, then people won't spend much time making sure their change doesn't break it(well, break it further). But if the build is pristine green, then they will be very careful about it.


I've had a recent example where I had a test which didn't work in certain client environment. A developper made a change to our code, ran the tests but had some errors unrelated to his change. He noticed it but was told it wouldn't cause any trouble. He then came back later to make a second change and still had errors in the tests but since the tests were already broken for him, he didn't investigate any errors. The obvious result? Our build broke as a result of his changes.

The lesson? If you want don't want other people to break your build make sure they have an easy way to see if their modification is affecting it. And also, make sure to make them feel guilty when they do break it! ;)

1 comment:

Mike B. said...

It's all true but unless there's a single developer assigned to committing code, there's always going to be a breaking change somewhere along the process. The people who told him it wouldn't cause any trouble should've investigated right away.

As you said, unit tests and good "versioning" habits are essential for good teamwork.