September, 2009
Well, we are coming to the end of our second week of daily code reviews and I thought I’d share some of my thoughts and general experiences.
First off, lessons learned. I realized very quickly the first week that despite my diligently creating a table of who was reviewing who - I failed to take into account people that were out of the office or on site with customers. The rearrangement wasn’t difficult, it would just be nice to think of those things ahead of time. The other piece that I realized quickly is that there are days where you don’t actually write any code or you are legitimately tied up in other things that don’t allow you to be reviewed. In this area, I think the team has been fantastic in rolling with the punches. I didn’t want these code reviews to be an annoying hoop that you have to jump through and that means if it doesn’t work out on a certain day, that is your call to make. I even found myself not participating at least one day a week.
The benefits so far? I’ve loved hearing reviews going on in the background of the office. It seems like all sorts of things are getting discussed that nobody ever talked about before. I actually really enjoy being a code reviewer and the best part about our system is that I get to see all the cool things that everyone else is up to. Reviewing Sean this week brought up some interesting discussions about things like what happens when you throw an exception from a finally block (hint: nothing good) and I liked his replacable user interaction service so much that I stole the code for a project I’m working on. We have some very talented and creative developers working here and the daily reviews are such a great chance to see what kinds of neat things everyone has created to solve their respective problems. Since we are all creating very similar mobile applications in the enterprise space, there is often great crossover and a good idea that Cliff has can be immediately relavant to what I’m working on and vice versa. With out the excuse of a code review, you may never know what the other developers on another project are up to. The other big benefit I’m seeing is that the daily reviews are acting as grease in the wheels of communication. In a very grass roots way we are solidifying our processes and best practices. We are working towards standardizing on simple things like naming conventions, project structures, release practices, versioning, installer technologies etc… These things aren’t being created by me sittting behind Word for a week creating something that immediately becomes a dead document, but instead are being born and refined out of our daily communication and current best understanding of how to develop exceptional software.
