One of the things I pushed for after I got back to project management and development is code review. Poor coding has bit me countless times so I’ve decided to proactively fight it. Projects where code smell often leads to firefighting. Firefighting is costly and personally, I just hate it. Desperately trying to save a project where you could’ve done something from the beginning is the worst feeling.

Code review can help you mitigate this problem. Code review is controversial because some developers don’t believe in its benefits. It takes too much effort but with very little (visible) effect on the project. Additionally, it can be really daunting. Review results typically spell huge code change and endless regression testing. However, I think with proper implementation, it can provide compelling benefits to a team. In just a few months of implementation, I’ve witnessed dramatic improvement in our development cycle. We are more confident with our code. Bugs are solved in a straightforward manner. Modifications are treated and implemented same way initial features were implemented, no hacks, no magic. Here’s how we do it:

  • Build guidelines and conventions for your team — code reviews are pointless if you do not establish ground rules.  For every technology stack, come up with a set of rules. For example, web applications involve several technologies. Create one for each stack and make sure every team member agrees with it. Put them in your intranet CMS or wiki for easy access. This makes the whole process objective: they stick to whatever was agreed on.
  • Do it quick, do it often — often, code reviews are exercised just a few times in a project cycle. Worst, it is performed at the end of the cycle. This is very problematic because by that time any code modification will most likely break a lot of things. The best thing is to do it as often as possible, as short as possible. This divides the whole endeavour into tiny little chunks and makes the effort tolerable. For example, it’s a lot easier to review code on a per task basis than per module or per application basis. By doing this, code review should not take more than 15 minutes.
  • Pick a review point — depending on how often you want to do it, picking the perfect timing for code review is critical. In our team, we encourage to commit codes as often as possible. Reviewers are notified whenever a developer commits (we use Slack!) so they can react instantly. They can choose to review it later but they should not let it go to the next day.
  • Involve everyone –— conventions and guidelines practically make everyone a candidate to be a reviewer. When everyone is involved, it creates team discussion. It opens up engagement. This is one of the best thing you can do to a team as you put them in a certain cadence. This increases productivity.
  • Pick a tool — so what happens next once you get the team fully on  board with the code review process? How do you monitor their progress? How do you give reviewers power over the process? How do you convert them into metrics? Pick a tool. Fortunately, most repo-hosting sites come with it and should be suffice for any code review processes. In our case, the ability to view and comment down to the code level is the most important feature. Developer notification comes close second. Importance of features may vary from organisations to organisations so I would suggest to check them out first. If you record KPIs for your team, the tool should give quantified result of the code review.

A lot has been written about the benefits of code review so I will not touch them here. In case you (or your boss) need convincing, here’s a good rundown of its benefits.