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.
The Rain and The Shade 
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.