Studies in the fields of criminology and urban decay have repeatedly found an interesting trigger mechanism – one that turns a clean and intact building, into a smashed and abandoned one. Care to hazard a guess what it could be?
A single broken window.
That single broken window, left unrepaired for a period of time has invariably lead to the rapid decline of the building and its community.
How does this happen?
It happens as a result of the sense of abandonment felt by those that live in and around the building; the sense that the powers that be don’t care about the building. So another window gets broken; then another. Later graffiti appears, followed by damage to the structure of the building. The spiral then continues until it gets to the point where the damage is beyond the building owner’s desire or willingness to fix it.
In one experiment in 1969, Stanford psychologist Philip Zimbardo arranged to have a car without license plates parked with its hood up in the Bronx, New York and another in Palo Alto California. In the New York example, vandals attacked the car within 10 minutes of its ‘abandonment’ and within 24 hours everything of any value had been taken. In California, the car sat untouched for more than a week. At this point Zimbardo himself smashed the windshield with a sledge hammer and then within minutes people passing by were joining in and then within a few hours the car was turned upside down and completely destroyed.
Social scientists Wilson and Kelling wrote about this ‘Broken Windows Theory’ in the March 1982 issue of ‘The Atlantic’. In this article they made these ‘inextricable linkages’ between disorder (or at least the perception of disorder) and crime. The New York vs. California example above – also referenced in the piece – notes how ‘untended property becomes fair game for people out for fun or plunder and even for people who ordinarily would not dream of doing such things and who probably consider themselves law-abiding’, and further, ‘vandalism can occur anywhere once communal barriers – the sense of mutual regard and the obligations of civility – are lowered by actions that seem to signal that “no one cares”’.
The Broken Windows theory has been credited in part for community based policing initiatives in various cities, perhaps most notably in New York City under the leadership of Rudolph Giuliani in the 1990s, where the focus was put on small crimes (e.g. vandalism, subway turn-style jumping) as a means of the prevention of larger crimes – by creating an atmosphere of order and lawfulness.
So, what does this have to do with software development?
Since the Broken Windows theory was theorized, software development teams have found inspiration in it, as a metaphor for focusing on the small things in order avoid larger problems down the road. Dealing with the ‘broken windows’, if you will, since ignoring them can result in ‘technical debt’ that will eventually have to be paid.
The idea is, that in addition to ensuring you’re doing all the right things – sweating the [seemingly] ‘small stuff’ – you’re not only developing a higher quality solution, you’re also creating an atmosphere on your project/team/company where process and quality matters. The Broken Windows theory as it applies to software development – generally speaking – asserts that issues should be dealt with before any further code is written. If the build doesn’t compile – fix it now. If there are bugs – fix them now. While this sounds simple enough, it’s not always the way it goes for one reason or another.
While each team and even each project for that matter will have different sets of processes for different reasons, there are still principles from this theory that can be used. Make it a point to agree on processes and standards for delivery. From unit tests, to comments and documentation, continuous integration and bug fixing – establish what your process and expected quality levels are and stick to them; even when you’re busy.
Especially when you’re busy.
In fact, ensure you’re working closely with whoever needs to be involved to make sure that you don’t find yourself constrained to the point where you’re unable to do all of these ‘little’ things, since that is a slippery slope to somewhere you don’t want to be.
I would further assert that this goes far beyond strategies related directly to the software development/coding aspect of solution delivery. Teams should also ensure that the overarching processes for solution delivery are agreed upon and maintained. While adherence to processes around things like communication, status reporting and risk analysis can sometimes seem like easy-pickings for corner cutting, the outcomes of doing so can lead you to a place where you could find yourself wondering how you got there.
One broken window at a time.