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.


November 1, 2011

The war game (Effectively starting up an offshore project)

Filed under: Project Management — ovaisakhter @ 2:51 pm

I have been working in an offshore software development for past 11 years. Out of these I was stationed at an offshore development center in Islamabad about 8 years. Later on I shifted to my company’s onshore office in Denmark. Later down the road I moved to Talented Earth Organization(TEO) my current employer.

TEO has a sales office in Denmark and a offshore development center in Islamabad, Pakistan. In TEO we try to follow a combination of onshore and offshore. To bootstrap the development process for a customer/project we offer Architecture and project management services onshore. So usually it is myself and a colleague (project manager) start the project from Denmark. We have a common joke that our purpose is make ourselves useless as soon as possible. So as soon as the channels are established between the client and development team we move to a more of “need to use” or  steering committee role.

During all the years we have been working we always felt the challenge of effectively starting a software project. A number of times it happens that the project is in the analysis phase and the team is in place. The team can be included in the analysis phase but I think that that not all of the team members will be useful for analysis secondly in the offshore scenario it is a bit time consuming when the idea for the project is still being developed.

Technically speaking there are a number of things that should be in place before the development can start.

  • Do all of the team members have the correct development environment.
  • Is the source control in place with all the user roles and rights
  • Are all the third party components in place.
  • Database servers are there with developers having proper access. and so on so forth

The team dynamics is another important factor in the project success. The project manager needs to gauge the team members so that he knows how to interact effectively with team members. Team members need to learn about other team members their weaknesses their strengths, their likes, dislikes, coding and development styles. A handshake of all the technical resources is extremely important for the over all success of the project.     

I remember a project where the client was still fighting with the evolution of his idea, and we in onshore office were trying to help him in this fight,(To help a client during requirement analysis phase is to help him keep the scope limited.) We were having some meetings with the team in offshore so they had a high level idea of what is needed to be done. My project manager and I were having this these discussions that the team in offshore center doesn’t have much to do. From the initial technical discussions we had very good idea that which technologies will be using in the project and we wanted all of the team to do some hands on these technologies. There was a tough deadline on the project. “There will be war once the actual development is started” I once said to the project manager. Thinking about this sentence we got the idea of a War game, a short project to prepare the team for the actual project.

A 5 day mini project (the war game) was planned.

Here are the ground rule for this War Game

  • All the processes followed in the normal project will be followed (it is a war game Smile).
  • We created an one page feature list based on the current understanding. The team will be provided with this feature list.
  • We will have an one hour meeting for requirement elaboration.
  • We will not discuss the requirements again the team will develop what ever they can envision based on this one pager, the discussion and their previous knowledge about the project. Hence removing the delaying factors in the project.
  • The feature list made was a bit more than what you will expect the team can deliver. This will can result in two results
  • To add a bit of spice we agreed that the team will present the outcome of this activity to rest of the company.

So the  war game began and after 5 days we were delighted to see the result. We had properly working use cases. The best part was that the team enjoyed it a lot as they were able to show their creative side and work without boundaries.

When this demo was shown to the customer he was extremely happy in fact he asked us to make it online so that he can show this to his stake holders. Now customer had a reference point to talk about that this thing I like this I do not and so on and so forth.

After the first experience we have used in couple of other projects and all the time the results have been better expected.

In the end I must say that the war game provides your team a momentum and this is very important to keep this momentum going. That is why I would suggest that project managers to schedule the post war game activities carefully so that this momentum and team synergy is properly consumed.

Blog at