When I suggested to our process improvement group that engineers should be performing spontaneous reviews, I meant that we should let them decide when to review their code, who should review it, and not try to manage the process. I figured that any sort of review was better than none, and the less threatening the review process, the more often it would be actually performed.

There are some other practices which need to go into play for a spontaneous review to be successful, however. Without them, people will be spending most of their time on finding structural and syntactical problems, and not finding problems in the implementation of a particular feature, which is the intended focus of a code review. For example, one needs to establish coding standards and one needs an automated tool to look for well known procedural errors. The new code should also have been validated against procedural unit tests. More how we implemented these practices in a future blog.

I took a look at an idea of a personal code review. The idea is that why should someone else be spending time finding errors the author could find with a brief proof reading. I discovered the personal software process (PSP) approach, and even tried it. Our group realized that for a personal review to be effective required a lot of personal discipline, and that an effective program was both out of our reach, and not realistic to expect to be followed. I just couldn't imagine our engineers keeping a personal notebook of known problems and reviewing their code objectively.

What if engineers invited each other to their computer screen and read over the code together? Although this may find defects, a tool is required to find the changes, and shared time is required from both engineers, which both may not have. Also, only a limited number of engineers, two, could participate in the review. Some other problems came up, and this path was not pursued. This is not to say it was discouraged, as such reviews were probably already happening, but it was not the basis of a development process.

I'd already looked at a web based open source tool earlier that year, I reviewed a tool called Codestriker. At the time, there wasn't much interest in such a tool, because the type of reviews we were thinking of then were for large feature implementations in a formal review process, the same process I stated in my previous blog that wasn't being followed. This criticism was important to understand the perception of code reviews, and spontaneous reviews are not suitable for large scale changes. The type of code review we were now focusing on were incremental changes, even if within the scope of a larger coding sprint. A formal review was certainly good for a code walk-through, but not for locating defects within an incremental change.

Codestriker may be a good web based code review tool, and if nothing else were available, we probably would have tried it for or spontaneous review process. Another commercial web based tool also became available at the same time. Our corporation already had a server installed and ready to use, so we tried it.

What a revolution! Our trial lasted one month, and already other groups wanted to start using it. We were seeing at least ten reviews a week on a five member team. Without even looking at what was being review, ten reviews a week of any depth was better than five a year that no one wanted to prepare for. The feedback was that defects were being found. I think the secret of the tool's success is that the author decides when to create a review, and who will be the reviewer. The reviewers can read and give feedback in the tool looking at the code changes, and on their own time. All the comments are saved, and the author closes the review when enough is enough.

We've been working with web based spontaneous reviews for about a year now, not just for C++ and Java projects, but also our Perl based system test development. It is suitable for any text based language.

Stay tuned for my next software improvement story.