Don’t Live with Broken Windows

I think this one is very similar to the boy scout rule and one of the things that was teached me first by my mentor when i started my career as a developer.

It happened to me all to often that i saw good and well architected projects being concepted and going live but then somehow the code base after a time gets worse and worse. And in most cases noone polluted the code base on purpose.

There are many factors that can contribute to software rot, but most are maybe cultural, organizational or psychological reasons.

What can we do? How can we avoid thats software gets rotten, although we maybe don’t get the time to maintain them.

I like the broken window example, which i stumbled upon in my first lecture of the pragmatic programmer years ago.

In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict .

A broken window.

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.

The “Broken Window Theory” has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

Don’t live with broken windows!

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

You may be thinking that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you’d better plan on getting a dumpster, or moving to another neighborhood. Don’t let entropy win.

Definition of done

Code is considered to be done, when it is…


  • all functional and non-functional requirements are satisfied – it does what it does
  • no known errors are contained – one i a million is next tuesday
  • decisions are commented, code is commented – create emphatic code


  • any code is pair-programmed or reviewed – better safe than sorry
  • it is designed using tdd – design for your customers
  • no refactorings or rearrangements are needed – later means never


  • code analysis is passed with zero defects – don’t get lost in perfection
  • well-known best practices are the code’s foundation – character is important
  • accepted coding standards are met – good looks are important as well


  • works on all relevant platforms and browsers – we are all equal
  • merged branches pass continues development – avoid it works on my machine
  • any code is checked into version control – la push, baby

inspired by