Code reviews should be built into every project timeline. What I find most of the time is that they are overlooked, excluded in lieu of functional testing only, or worst of all, performed by the wrong person. This is shame because a code review can significantly enhance a team's chance of delivering a quality piece of software that the customer will actually use.

There are several ways of conducting an effective code review, some very laize faire and some very hands-on. The key is combining the power of review tools with an architect's personal and professional experience to yield the most effective review possible without taking inordinate amounts of time away from the project itself.

The following are three tips I'd like to offer to help you get the most out of your code reviews.

1. Do Reviews Early, Do Reviews Often
The first three weeks of a project are the most crucial. It is during this early time that the foundational parts of the application are being developed. This will be the first and best opportunity for issues in this vital part of your application to be identified and fixed inexpensively. Every day that goes by without identifying a critical defect in the code will cost you exponentially down the road in lost time and money.

The first key to a successful code review is to start reviewing the first day of the project. Look at code written by all the members of the development team and make sure that they are heading in the right direction. Some important things to look for in these early reviews include:

• Are they correctly implementing classes, interfaces and layers per the system design?
• Are they leveraging any reusable utility components in your organization?
• Are they using established naming conventions, either industry or organization specific?
• Are they implementing proper exception handling, i.e. not swallowing exceptions?
• Are they properly closing database connections, streams, etc.?
• Is there any redundant code that can be consolidated?
• Are they properly addressing tier requirements for the system?

With a focus on these specific items, I recommend that you do daily code reviews for the first three weeks of the project, providing feedback to the team the same day. By identifying these fundamental structural issues before thousands of more lines of code are written on top of them allow your team to address them while they are still easy and inexpensive to fix.

This process also provides the architect a great opportunity to mentor your development team. Looking at their code will be a great indicator of how experienced they are and sharing your feedback will help make them better developers down the road.

After the first three weeks of the project, you should be able to back off the daily code reviews and start doing them every couple of days instead. By this time, your team should have firm expectations what they need to do and solid direction going forward. Ideally, within a month, you should be able to move to weekly reviews with minimal risk of missing something important. Of course, every project and development team is different, so use your best judgement as to the effectiveness this approach offers at the start of each new project.

2. Tools: Trust, but Verify
Any software vendor that you talk to will tell you that their static analysis tools will catch most of the bad stuff in your code, and the only ones you should be considering should allow you customize the rules that the tool applies in its analysis.

However, analysis tools are just like any other piece of software: They're limited by the number and quality of rules provided them to do their job. Most static analysis tools I've worked with in my career provide good starting points for a more in-depth, manual review.

Think about a code analysis tool like Cliff's Notes. Cliff's Notes were meant to be a study assistant while reading a particular book, not a replacement for the book itself. However, ask any group of high school English students and I'm sure you find them enjoying the Cliff's Notes for Huckleberry Finn without a copy of the novel anywhere in site. While this will give you a high level overview of the plot and the major themes, nothing can replace the level of detail you'll only get from reading the book itself.

Also, Cliff's Notes are not always correct. I remember using Cliff's in college for some 18th century British novel I was struggling to get through (I wish I could remember wish -- it was dry as hell). I got through the novel, but depended almost solely on the Cliff's Notes to arm me with the information I needed to discuss it in class. As it turns out, we were using an alternative version of the original text and I was missing several details which made me look like an idiot in front of my classmates.

If anyone out there used FxCop before it was (arguably) improved and integrated into Visual Studio Team System, you know that tools can't always be trusted to return an accurate representation of reality. I once wrote a "Hello World" console application in C# and FxCop told me I had over 1,200 defects in my code.

The point of this is to use code analysis tools as a means of "sniffing" your code for potential problems. Look at them as sign posts to something you should investigate further. Sadly, I don't think we'll ever see a tool that will deliver the same, high-quality results as actual human eyeballs on the source code. "Trust" that the tool is pointing you in the right direction, but "verify" that there is really some fire to go with that smoke.

3. Actually Read the Code
Building on the previous section, nothing can replace actually looking at source code. This is definitely time consuming, but will yield the best results. While code analysis tools will catch naming convention violations and orphan variables, actually looking at the code will provide you the context of those issues, especially in the structural integrity of the application as a whole.

The other benefit is that it gives you more visibility to what your developers know how to do. In my first bibliography class as an undergraduate, I was fascinated to learn that literary scientists had been able to identify individual typesetters of Shakespeare's first folio by the grammatical and spelling errors they made setting type on the printing press. The same principle can be applied to reviewing developers' code. It will help you identify strengths and weakness in individuals' coding and allow you act accordingly.

Reading raw code isn't necessarily to most exciting or desirable work in the world. In fact, it can be downright tedious and tiring. However, it is the most sure way to make sure that your project is proceeding the way it should be in development, so budget time to sit and just read and understand the code being written for your project. If you do, I can guarantee you'll reap the benefits later.

Just Do It
Hopefully you'll find these tips useful in getting better quality results from your development projects. I absolutely recommend trying these techniques out on your next project, but also encourage you to try them out on your current project, even if it is well underway. You may not get all the benefits, especially from the early and often reviews, but doing some level of review is better than doing none at all.

I welcome your input, experiences and additional best practices. Please leave a comment if you have something to add to the conversation.