Wednesday, November 21, 2007

Effective Code Reviews... the next steps.

I've been giving a lot of thought as to how to move closer toward pair programming within our development organization. Code reviews today are somewhat effective but tend to take a back seat when the pressure is on to make schedules to release code. e.g. The urgent always wins over the important. (Stephen Covey)

So developers and managers under pressure will delaying code reviews until after the release. That's just a stall tactic as sometimes that occurs and sometimes it doesn't. Either way, it's POINTLESS! The further in time you are away from when the code was written the more chance you have of making a breaking change. (ignoring unit test coverage and unit test quality)

Most code reviews reveal code that can be improved but is not incorrect. These types of changes should never be made on released code! Sometimes it's even worse in that the code requires design changes that we glossed over during the design phase but we obvious design concerns now that the code is complete.

Perhaps the best approach to shortening the time between when the code is written to when the code is reviewed is to enforce check-in policies. This would require at least another developer to review code changes before it could be committed to the source code repository.

I have noticed that TFS contains a field to indicate that the code was reviewed. I imagine a combination of shelving and using this flag with policies in place could begin to move code reviews more into the daily coding work flow rather than waiting until there is no time at the end of the schedule.

Another possibility to get closer to pair programming is to all developers be requires to spend one hour each day reviewing (hence pairing) on another developers work for the day.

I just don't think the culture shift to pair programming is going to be something that is ever dropped into an existing organization. We need to find methods to introduce it in small doses in order to succeed.

As Einstein once said, "Insanity is doing the same thing over and over again and expecting different results."