all bits considered data to information to knowledge


Reviewing code for fun and profit

Everybody would agree that a review is a good idea – code review, design review, performance rev…let’s stop right there 🙂

Yet there aren’t many as universally hated team activities as code review. A programmer is solitary animal – XP methodology notwithstanding – and generally does not like explaining his/her code to the group. Now, this does not apply to truly agile engaged team where people are fully aware of each other strengths and weaknesses, trust each other do do the best job possible, and do not get defensive at critique. The rest – read: most of the teams – do have these problems, to some degree.

As I see it, the defensiveness could have several plausible explanations, and none of them flattering:

  • incompetence – the programmer knows or suspects he’s not up to the team’s standards, and does not want this fact to be discovered by his peers and managers
  • arrogance – the programmer believes that team is not “qualified” to review his code; usually comes with primadonna syndrome
  • laziness – the programmer is getting paid to “produce code, not to discuss it”;  implies equavalency of good and bad code(design)
  • lack of reviewing skills – the programmer was never educated on the value of the code review (or the education did not sink in), much less in reviewing methods

NB: The list is far from being complete – feel free to add your own entries.

All of these could – and should – be addressed rather sooner than later if team is to succeed. The first two dwell mostly in project management domain, while fallacy of the last two could be rectified with proper education and process automation.

I will talk about automating the review process in upcoming blogs.