Technology is always making our lives easier. In fact a lot of the time we completely forget what it was that technology is doing for us. I believe that one of these areas is software quality assurance (QA). Tools such as code formatters, Checkstyle, EMMA, jUnit, Jester, Cruise Control, all assist in the quality assurance process; but are these tools (plus others not listed) good enough to no longer warrant manual QA?

There are many ways to skin a cat, and the same principle applies to building software applications. It’s just lucky we have an automatic tool for always identifying the best design/solution? Wait a minute, no we don’t. But surely design doesn’t matter, as long as the software works right? Wrong, design is a fundamental step in the software life cycle and if done poorly/inconsistently can lead longer development times and maintenance nightmares (and a slew of other problems).

A valuable technique for solving this problem and many others are good old manual (gasp) code reviews. Code reviews can be as quick as five minutes or as long as an hour (depends on the code). The advantages of code reviews are that they help to identify:

  • Deviations from the design/architecture
  • Software bugs
  • Quality of test cases
  • Overly complex code
  • Adequate code commenting
  • Deviations from the coding standards that are not automatically detectable
  • Requirement tracing

Above all else, code reviews provide education and promote communication within the team. This ensures that all members are on the same page. Code review checklists are not hard to make and there are many templates available on the net. I find the best checklists are the short ones made specifically for the project. The downside to performing code reviews is obviously the ‘fourth dimension’ – time. But do the benefits out weigh the cost?

I think so.

There is a great article on the importance of code reviews here.

One comment

  1. Great piece Nick. In my opinion, testing _and_ reviews are pretty much the twin pillars of ‘external’ software quality – ie, the quality of the software as perceived by your users. This explains why they’ve been around for so long – from old waterfall methodologies through to XP (which also demands continual refactoring, which improves the ‘internal quality’ of your code as perceived by developers) Indeed, with regards to XP, as far as I can tell pair-programming seems like one long code review🙂 Of course, we don’t all have the luxury of working on XP projects, but this doesn’t mean that regular code reviews won’t be of benefit.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s