The Broken Windows Principle

The broken windows theory is a criminological theory of the norm-setting and signaling effect of urban disorder and vandalism on additional crime and anti-social behavior. The theory states that maintaining and monitoring urban environments in a well-ordered condition may stop further vandalism and escalation into more serious crime. (source)

In other words, if broken a window isn’t promptly fixed, the message conveyed by the owners of the building is that they don’t care. Consequently, vandalism will continue and chances are that a second window will also be broken. Eventually all the windows will be broken and the building will probably be abandoned.

Surprisingly this also applies to software! Think about projects you’ve worked on and try to recall if these projects were easy to maintain. In some cases they may have contained loads of duplicate code. In other projects you may have noticed that lots of code was commented out. Think back to how this affected the way worked with the code base. Did you eventually stop caring?

Overtime code quality degrades and it becomes fragile. Developers lose confidence and are afraid to make changes to the code base. At this point you’re standing against a wall, your having trouble delivering quality software to your customers. Furthermore, staff turnover is probably at an all time high.

Recovering from a situation like this isn’t an easy task, but its possible!

The first thing that usually needs to happen, is to actively care for the code base. Rewriting the software as a new project will probably fail. The business needs to keep pushing new features to its customers and the new project will race to catch up. Unfortunately this is a race that the rewrite project rarely wins.

In order to regain control over your code base you will need to work from the inside out.
To do this you can:

  • remove dead code
  • remove commented code
  • standardize the coding style
  • get rid of global variables
  • break apart god objects
  • refactor code in order identify and encapsulate responsibilities
  • bring the current features under test, this will help document and validate what already exists
  • use Test Driven Development when you need to fix a bug
  • use Test Driven Development to implement new features
  • use Continuous Integration to identify broken builds and failing tests.

As the quality of your code base rises, your developers will regain confidence. Consequently reducing the number of bugs that make their way to your end users.

Working towards a more maintainable code base isn’t easy. You should consider tools like ReSharper to help with refactoring and NDepend to help identify and correct design issues.

In summary, if you care about your code base, you must set the example for your peers. Following your lead, they will be driven to keep the code base clean. Remember that building a perfect solution from the start is next to impossible. Therefore, it’s important to continuously adjust and refactor the code base as the project evolves.

Writing clean code is the first step towards gaining your end user’s confidence.

Trackbacks and Pingbacks:

  1. Temporary is The New Permanent | Alexandre Brisebois - January 6, 2014

    […] previously touched on this subject when I wrote about the Broken Window Principle in June 2013 and I recently came across a few blog posts that also covered this topic. One of these […]

    Like

  2. The Broken Windows Principle: My point of start for Refactoring | Louis Turmel Blogs - April 2, 2014

    […] broken windows principle, is a lot documented by my friend, Alexandre Brisebois. This principle establishes the link between […]

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.