Review Your Code

The other day one of my little boys was sick at home, so as I had to spend the day with him. I decided to write a presentation document - using OpenOffice Impress - describing the technical details of an iteration release of one of our products. The idea was that we produce some much code, for so many different products that, first we don't remember what we did or how we solved the problems a month later and second, people who were not sitting in on the coding session don't have a good idea of how the code works. I thought an Impress presentation would allow us all to quickly review what we did on a release, and the developers who did the code could give insight to the implementation strategies.

We have not really had a review meeting (but this will happen), but I found the process of writing the code review presentation to be very informative for me. First, I am the worst when it comes to forgetting what I did two weeks ago (I am the burnt out coder after all). Second when we isolate code sections for a simple presentation, we see inconsistencies and omissions that are not appearent when you are busy hacking code. In one section of the presentations I talk about the major interfaces that we implemented. I show a UML class diagram of the interface on the left with a description on the right. That's it... one interface per slide. Under this presentation you notice things about the interface design the you don't when it is all mungied-up with other classes and interfaces.

In the end, on one hand I could see that some interface members may have been asymetrically or inconsistently implemented, but on the other hand we don't add things to interfaces lightly and everything is the subject to quite a bit of debate. Also we have a strict rule about not adding stuff we don't need. Currently the interfaces work (warts and all) and that is the most important thing. I am happy with the review and I am happy with the structure of the interfaces. I find the time spent writing the review was not wasted.