Broken Windows effect proved?

There has been a bunch of stuff written about the “Broken Windows” effect - the way that even good people will begin to do bad things if everything else is bad around them. In areas that look badly maintained, people tend to drop more litter. Where people are obviously flouting the rules others are more likely to bend them themselves. And in software, when you are working on bad code you are more likely to write more bad code.

I first stumbled across the idea in an interview with the Pragmatic Programmers, but the evidence given is fairly apocryphal. So I was pleased to find something more definite. And it does make for interesting reading. The effect is indeed real, and significant. The number of people breaking social norms when they see that others have done something similar more than doubles. It's the 'no-one will notice another little bit of mess' effect.

The study quoted in the article reinforces the need to maintain a high level of hygiene in your software. Some typical pointers:

• Keep classes small, compact and easy to read. Keep honest by using peer review (pair programming, formal review etc).
• Keep your code syntactically green. Don't tolerate compiler warnings unless absolutely unavoidable, and even then try to make these exceptions explicit (eg by using annotations). All modern IDEs are able to apply rules to warn of potentially error prone constructs and styles.
• If you are serious about unit testing, unit test everything. If you need exceptions (mutators?) then make sure everyone knows what they are and agrees with the decision, then get everyone to police it. Reinforce the social norm.
• Keep your tests green. No excuses. If it breaks, fix it or roll back quickly (I have heard of one team using an SVN hook on their gateway build; if that fails, the changes are immediately and automatically reverted to the last successful build).
  
• Make sure your processes (QA, deployment etc) are slick and clean. If they're not, iterate them until they are. Anything that is difficult to do will encourage quick, dirty hacks and workarounds "until we get around to sorting things out".
• Actively drive out all forms of technical debt. Or as one team succinctly put it, “Don’t step over the poo”. Don’t let tech debt accumulate and become acceptable otherwise it will fester and grow. Technical debt is the software equivalent of broken windows.

I could go on, but you get the idea. The golden rule is:

Don’t live with broken windows. If you see one, fix it!