In 1969 a car with no license plates was parked with it’s hood up in the Bronx. Within minutes it was vandalized and stripped. That car was part of an experiment to test a theory called “broken windows”.
The Broken windows theory
The original broken windows theory was introduced in 1982:
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 pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.
[Wilson, James Q; Kelling, George L (Mar 1982), "Broken Windows: The police and neighborhood safety", The Atlantic]
The bottom line is that we need to fix the small issues quickly in order to prevent bigger issues down the road. And by fixing these problems we avoid escalation and make sure that the neighborhood does not become a crime ridden cesspool, or the inspiration of the next Fallout game.
What does it have to do with my code?
Code can also have broken windows – bad design, leftover comments that doesn't mean anything anymore and dead code. I’ve seen it happen countless times – long methods become longer (instead of refactored to smaller methods) and messy code becomes harder to read and maintain as time go by.
I remember one code review in which the developer didn’t bother with writing unit tests for a new feature since “the existing code did not have any unit tests in place”…
When code issues are left unattended development of new features becomes harder (or even impossible) and every change introduces new and exotic bugs. Weird governing processes are created – I’ve seen one place where is was common practice to have the equivalent of two weeks of meetings before a single line of code was written.
Broken windows in code leads to fear – fear of changing code, fear of writing new code and overall
The funny thing is that usually fixing broken windows in code is simple – refactoring when applied correctly can solve most issues before they become and impossible mess. Since most modern IDEs support at least a subset of the common refactoring (such as rename and extract to method) – these refactorings can be done safely and without breaking existing code.
Other broken windows in software development
But there are other ways in which we can unintentionally create a broken window that has nothing to do with our code. At one job we had to use a tool that made building a new version impossible to automate, no once know why we’ve been using it and no one could explain the merits on using it but every single time I’ve tried to replace it I was met with fierce resistance – since it’s the tool that all the big players are using.
If releasing a new version takes three days and a hundred steps of manual work – this could be a problem that can escalate quickly, and before you know it a wrong version is shipped to your customer.
And it could be the small things such as a version number of another dependency that seem to change without any logic behind it (yesterday version was 1.0.0.111, today’s is 1.0.0.9) – this pseudo randomness can cause big problems once you need to revisit a change (hotfix anyone?) or distribute a new version using automatic update tool.
The solution for most of these ALM related is education and automation which seems like a lot of work at beginning but once it place saves quite a lot of time every single day.
Summary
Broken windows are everywhere – it’s the small things that can becomes huge problems if left unchecked. It becomes a real problem once the development team (or the whole organization) accept them as a fact of life (a.k.a it’s the way it was always done here).
In the book “Clean code” Bob Martin explain about the “boy scout rule”:
If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn't have to be something big. Change one variable name for the better, break up one function that's a little too large, eliminate one small bit of duplication, clean up one composite if statement.
Can you imagine working on a project where the code simply got better as time passed? Do you believe that any other option is professional? Indeed, isn't continuous improvement an intrinsic part of professionalism?
So pay attention to the small pains – it usually means that you can fix something today instead of waiting until it would be impossible to change. At once company we had a rule – if something annoyed us more than three times – we would change it. I still find this to be a useful way of finding ways to improve my code as well as the development process.
Happy coding…Labels: Clean Code
by Sylvain Raybaud
