Brian On Software

I first heard of the Broken Windows theory while reading Malcom Gladwell’s The Tipping Point.  In a nutshell, the theory goes like this:

If a window is broken and left unrepaired, people walking by will conclude that no one cares and no one is in charge.  Soon, more windows will be broken, and the sense of anarchy will spread from the building to the street on which it faces, sending a signal that anything goes.

I couldn’t help myself thinking how this theory fits well with the current state of software development.  When a software project first begins, it is void of any imperfection for no one began to write a single line of code for it.  Then as the team forms and the tasks are being assigned and executed, the team members start to breath life into the software.  That software could have a very different life depending on various factors of the team in charge of developing it, such as the team members’ experience, skills, knowledge, professionalism and passion for the craft. 

From my days of consulting and working as a team member, I more than often see a lack of responsibility from the individual team member for the most important organ of the software: the source code.  Once the source code has started to rot, it doesn’t matter how colorful or beautiful your design documents are or how detailed your development plan is…your software has a cancer and it will die unless you do something about it.  The typical scenario of the Broken Windows theory in software development goes like this: Robert, a programmer, is working on a subroutine for the Shipping module.  While at it, he notices that the NotifySupplier method is lacking a couple of guard clauses and the comments don’t reflect the code at all.  Since he wasn’t the one to write that code, he ignores it and continues working on his work item.  Will he remember to ask the developer who wrote the NotifySupplier method that it is in need of some fixing?  Who knows.  One meeting here, one phone call there, and chances are that Robert will forget about it.  Upon that time, the software has started to confirm the theory.  It now has a broken window.  What’s even more dangerous is that this theory can cascade all over the core of the software if its internals show a high degree of coupling with many components.  A good analogy would be like a tree burning in a forest.  It doesn’t take much time for the fire to spread to the other trees.  The outcome of this is simple: chaos.  The remedy is also simple: you.  What are you going to do about it?  Are you going to run from it or are you going to take corrective actions to prevent the cancer to spread all over the system?

Another potential risky situation that may arise from the Broken Window theory in software development is that if you don’t take care of fixing the broken code as soon as humanly possible, your junior developers and interns (if you have any) will have the impression that all this is normal in our industry.  The result of this is that as they continue to build and ship software in the future, those junior developers and interns will have shipped products with broken windows in them.  The theory can also backfire on your organization as the developers, sooner or later, realize that the organization isn’t mature enough and might decide to work somewhere else that will provide them the proper environment to appreciate the craft of building software and pay attention to the smallest details.   Here are a few examples of what I consider a broken window in the code and that should get fixed as soon as possible:

• Missing unit tests
• Comments out-of-sync with the target code
• A method, class or module that should be refactored
• A complex piece of code that could be replaced with a design pattern to better express its intent
• A broken build
• Etc.

There are also some solutions to prevent this theory to hinder the software project:

• Performing code reviews at least once a week
• Encouraging pair programming, as four eyes are better than two
• Putting in place automated tools that will break the build when rules are broken (FxCop, NDepend, NCover, etc.)
• Having the programmer check in her modifications in a private build such that if it succeeds then the modifications are merged to the repository.  Have a look at Team City for it does that very well.
• Providing intelligent tools to your developers so that they can work more effectively with the codebase.  A tool like ReSharper quickly comes into mind.
• Instilling an atmosphere that considers quality as the most important instrument to drive the organization to success.

But the tools and processes aren’t the heart of the solution.  What will either make or break the software is the attitude of every single individual affected to the project.  To encourage the growth and maturity of this attitude, developers should educate themselves on the trends of software development.  Developers should constantly thrive to do as much as possible to become more valuable software professionals.  

Though he doesn’t talk about this theory explicitly in his book, Agile Principles, Patterns, and Practices in C#, Robert C. Martin does reflect on the basis of the Broken Windows theory and also does provide a remedy to fight this problem in software.  According to him, and I agree with his statement, it’s all about having an attitude of being professional:

The attitude that agile developers have toward the design of the software is the same attitude that surgeons have toward sterile procedure.  Sterile procedure is what makes surgery possible.  Without it, the risk of infection would be far too high to tolerate.  Agile developers feel the same way about their designs.  The risk of letting even the tiniest bit of rot begin is too high to tolerate.

The design must remain clean.  And since the source code is the most important expression of the design, it too must remain clean.  Professionalism dictates that we, as software developers, cannot tolerate code rot.

Remember: Only YOU can prevent broken windows in your software project from spreading like cancer.  You have access to a grand vast of online resources and tools to help you fix those broken windows before it’s too late.  Do you have the attitude to do as such?