The Rain and The Shade

November 7, 2011

The Broken Window (Maintaining coding best practices in organizations)

Filed under: Code Quality,General Software Archiecture,Project Management — ovaisakhter @ 1:47 pm

Recently I attended a seminar by Roy Osherove about good practices in unit tests. Although all the seminar was full of information and useful ideas. I particularly liked the concept called Broken Window Theory. Idea is that if a diversion from the normality or pattern is made at one place, it will be replicated to all multiple places in the code. Other developer looking at the code will feel that it is fine to do something like this.

The question is how to avoid the broken windows in the code of a team or a software development company where a lot of people are developing code and there are very few to review it.

I am a big supporter of code analysis tools, and have been advocating them in my organization. We have been using FXCop and lately we having been using ReSharper.

For FxCop I like to have a basic set of rules that should be followed by all the projects. What we try to achieve with this is that all the code going out of the development shop has certain basic standard. Once a new project starts the architect looks into the standard rules and see what additional rules should be added to the rule set for this project. A combination of these rules then becomes the standard rule set for that project.

Standard operating procedure for developers is not to check-in before all the errors and warnings have been removed. FxCop helps a lot achieving this goal with the annoying warnings. We cannot use check-in policies as we use multiple source control tools. “Treat Warnings as Errors” is always on in the project properties. The code analysis is also done on the build servers after every check-in. In case of Resharper we use the out of the box refactoring scheme, the SOP is to follow all the suggestions.

All the static code analysis tools provide the facility to exclude a portion of the code from being being evaluated for a particular rule. And some times it is justifiable to exclude a certain rule. This is very convenient for the developers to do that even if there is not enough justification. The question here becomes on how to avoid the broken window effect when we make such exclusions.

In this case we like to follow the practice that I like to call “Justify and publish”. As a developer you are allowed to deviate from a rule if and only if you

  • 1) Writes a comment with the code with a reason of deviation.
  • 2) Publish this deviation to the project development wiki

this way the developers do not go on sabotaging the patterns at will. If some one else sees the diversion he can see that this was deliberate and for some reason and he will not replicate this every where. Publishing the information on the development wiki architects and other developers get a chance to wet the diversion and may suggest a better approach to solve the issue. Yet there is no time wasted for the developer.

1 Comment »

  1. With havin so much content do you ever run into any issues of
    plagorism or copyright infringement? My blog has a
    lot of unique content I’ve either authored myself or outsourced but it looks like a lot of it is popping it up all over the internet without my authorization. Do you know any solutions to help prevent content from being ripped off? I’d certainly appreciate it.

    Comment by windows server — January 9, 2013 @ 6:32 am | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: