I was working in a large multi-national networking company, where in my particular group, code reviews were conducted over email, in a similar manner to what is done on the Linux kernel mailing list. People submitted proposed changes in an email to a group address, nominated a particular reviewer, who then sent their comments back as a reply with their comments inline.

For the purposes of reviewing small changes, this process seemed to work quite well. Our group then received a series of seminars in regards to performing effective code inspections, which was a highly formalised process involving significant preparation time, sit-down meetings and formal roles, such as author, reviewer, and recorder. This sounded highly promising, but the huge amount of up-front work tended to turn people off the process. When the process was used, we found a number of defects that most likely would have been missed in an informal email review, and would have surfaced later as a defect discovered at a customer site.

Later, I joined a startup company, where a lot of new code was being written. We also used email initially for the purposes of code reviewing, however this had a number of limitations. As before, I found I constantly had to refer to the existing source code files to understand the context of the changes. In addition, I found that once more than one person was performing a review of a proposed change, it became cumbersome to merge their comments together. Also, the reviewers were unaware of their colleague's comments until they sent their email, which could result in duplicate work.

Codestriker was born to fill this gap back in December 2001, when version 1.0 was released on SourceForge. Because it was a quick-and-dirty concept, I wrote a simple single-file CGI Perl script, which accepted a text file which constituted the review (usually the output from cvs diff -uN), sent notification emails to the reviewers indicating they had a review to do. The reviewers saw a page displaying the text file, where each line had a hyperlink allowing them to add a comment to it. Any comments submitted were sent by email to the author and the reviewers. The list of comments already made were also displayed at the bottom of the page, and a line which already had a comment had a red hyperlink. No database was involved, data was recorded using simple files. The most important thing was the process was still light-weight enough that nobody was put off by a slightly more structured process.

Eventually, the single-file script kept growing to include the coloured display of diff files, and integration with CVS so that changes could be more readily understood within the context of the whole file. More and more features became available, including the use of a database for persistence, and Codestriker eventually became the modularised Perl web application that it is today.

The last few releases of Codestriker have made it acceptable for use in both light-weight review processes, and for formal inspection processes.