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.


August 11, 2011

My name is Ovais and ICodeInCSharp , IDoPhotography,IWriteBlogs

Filed under: C# Coding,General Software Archiecture,Modeling — ovaisakhter @ 2:11 pm


I am a big fan of interfaces in a object oriented language like C#. I have been using dependency injection (IoC) in most of my previous projects and using DI your model contains many interfaces. I always try to spend some time in naming my model elements be it the name of interfaces, classes, methods or even the variables. When I look at code by other people one thing I usually notice is how they are naming their model elements.

Some days back I was looking into NServiceBus the things I noticed while doing that other than shear brilliance was the way different interfaces were named. for example IHandleMessages or IContainSagaData. This was a bit different way of naming then what I usually use as normally I would use something like IMessageHandler. I thought this is an interesting way of naming something like a class is saving my Name is MessageHandler and I Handle Messages. Sounds more natural more understandable.

I thought I should give this way of naming a try. In one of my projects, I tried to use similar naming.

The first place I need to create Interfaces are the repositories. So I started with names like IStoreData (instead of IRepository sounds boring doesn’t it?), IStoreDataInSql and went on and making names like IStoreStatistics.

Next place was the application controller where normally the interfaces for the services are named as IStatisticsService or IConfigurationService etc the names now became a bit different i.e. ILogStatistics, IManageSiteSurveryConfiguration, INotifyToExecuteAction INotifyWhenSiteSurveyConfigurationChanges.

Thought it was fun way of naming interfaces in some cases it become as stagnant as the old approach like IProvideThis and IHandleThat but in some cases the names become very interesting like INotifyWhenSiteSurveyConfigurationChanges and INotifyToExecuteAction.

July 14, 2011

Let Google do it

Filed under: General Software Archiecture — ovaisakhter @ 10:59 am

One question I always ask from my tech savvy friends “What is the best way to search MSDN(Microsoft Developers Network) website” and most of the time I get the answer I am looking for i.e. “Search it with Google” and this is true I have almost never been able to find any thing on MSDN using search provided on MSDN. I usually do it on Google for it.

Let say I am looking for something related to Microsoft development tools and Facebook, I will go to Google, will start writing “MSDN” and then “Facebook” and it will give me an option search suggestion like “MSDN facebook sdk” and if you search the first link will be the correct link life does not gets any better. Try doing this on MSDN (or on Bing for that matter Smile).

I think that if you do not have a special need to implement a Full-text search then don’t  even bother, Google will be doing a much better job then you anyway. You may want to spend the time saved from search implementation in making your site more Search Engine Friendly.

Blog at