Tess’s Blog Title provides profoundly important advice to every developer - “If broken it is, fix it you should” – Words of wisdom, which are much more important than they would sound the first time you hear them.
A young an enterprising engineer recently looked at one of our code base and asked me why we use interfaces and abstract classes so extensively when we could have coded using code-behinds in ASPX pages.
Another engineer I worked with in the past often wondered why I sent out long and loud emails to team members when I discovered they were using band-aids to mend their code and were moving on to new functionality without fixing small problems and issues resulting out of their using these band-aids.
Another young college graduate fresh out of college, who I worked with in the past also, believed that I often strive for – “perfection for the sake of perfection” – and questioned why I push developers to use Re-sharper, CodeRush or other similar tools.
The answer to all of these questions and why I strongly insist on every developer developing a certain sense of responsibility towards writing clean, small, cohesive and maintainable code can be summed up in two words – “Broken Windows”.
The Broken Windows theory has been rather old but I continue to be amazed at how much influence it has, on both – software development and our lives in general.
For the last couple of weeks, during my stay in a hotel suite in San Francisco, I was working working a client during the day time and a small but very smart team back at work during the late evenings. A lot of work was leaving me way too tired to cook and I had primarily moved to frozen food, vegan broccoli hot-pockets, chips and snacks – all of which came in plastic packets.
The first time I used the frozen food I left the empty plastic packet on the cooking shelf because I was way too tired to thrash it. The next day, I was tired again and history repeated itself. Soon packets started piling up on my kitchen shelf. The housekeeper stopped cleaning the kitchen and in a matter of less than a couple of weeks plastic packets started showing up in my entire suite making it look like a thrash-room. This in turn started making me feel very depressed every time I returned to the suite from work.
What I had experienced first-hand, in my very own life, was a classic example of the Broken Windows Theory in action.
As someone who has read about this theory many-a-times and has tried his best to keep this theory from becoming a reality in his projects, I keep getting amazed at how the broken windows theory does in fact, starts affecting us, both in our projects and our lives, every time we leave just one little broken window unfixed.
Broken Windows can destroy lives and projects faster than most people think they can.
Andrew Hunt describes the Broken Windows Theory and why it is dangerous to live with Broken Windows in his book the pragmatic programmer and his online interview. He describes the basic theory much more articulately than the little hotel suite example from the recent past I described above. He explains:
Researchers studying urban decay wanted to find out why some neighborhoods escape the ravages of the inner city, and others right next door - with the same demographics and economic makeup - would become a hell hole where the cops were scared to go in. They wanted to figure out what made the difference.
The researchers did a test. They took a nice car, like a Jaguar, and parked it in the South Bronx in New York. They retreated back to a duck blind, and watched to see what would happen. They left the car parked there for something like four days, and nothing happened. It wasn't touched. So they went up and broke a little window on the side, and went back to the blind. In something like four hours, the car was turned upside down, torched, and stripped - the whole works.
Hunt in the same interview gives another example:
They did more studies and developed a "Broken Window Theory." A window gets broken at an apartment building, but no one fixes it. It's left broken. Then something else gets broken. Maybe it's an accident, maybe not, but it isn't fixed either. Graffiti starts to appear. More and more damage accumulates. Very quickly you get an exponential ramp. The whole building decays. Tenants move out. Crime moves in. And you've lost the game. It's all over.
Jeff Atwood in his post on this topic brings out a new perspective. He believes that it’s all about perception. He explains:
Programming is insanely detail oriented, and perhaps this is why: if you're not on top of the details, the perception is that things are out of control, and it's only a matter of time before your project spins out of control. Maybe we should be sweating the small stuff.
As developers we all make compromises for the sake of shipping. It's also a hard fact of life that after all, we all make shitty software with bugs.
But here is what differentiates the veterans who have seen the light or have mastered the art of shipping, from the programmers who can’t program.
- The Veterans know that they have written shitty software when they have and they are unashamed to admit it.
- The Veterans know when and how the shit usually gets out of control and are very careful about fixing the broken windows as soon as they are broken, before things start getting out of control.
Ever been a part of a project that you wished you were never a part of? Ever been a part of a project where you felt glad that the project ended and felt happy that you could run far away from it?
Look back. Chances are that it all started with one or two broken windows which no one bothered to fix.
Do you have broken windows in your current project? Fix your broken windows, before you yourself and others in your team, start getting a perception that your project is a dumping ground for bad code and start vandalizing your own project, subconsciously, innocently and unknowingly.
For today I tweak Tess’s blog title slightly and leave you dear reader, with a thought worth harping on, for your project and your life - “if broken your windows are, fix them you must”.