Code Review in SCRUM? #xp #agile #mathematics

Recently I was asked by a client to make some estimations regarding a review of a code review for a programming project. The aim of the project is to refactor the existing code for efficiency, check the security and add new functionality. Having done code reviews in the past I had an idea on how it should be done, and little idea on how to quantify the work into an estimate.

How a code review estimate is done now?

Using the research done by Cisco Systems^[1][2] I came up with an algorithm to help with the estimate, in the algorithm l is the number of lines of code and t is the average time spend 60-90 minutes – it should probably be closer to 60 than 90 minutes – for each of the blocks of 300-400 lines of code b to be reviewed. And a reviewer can be expected to find 70-90% of defects in the reviewed material. This algorithm naturally ignores that the real algorithm it is a polynomial equation and almost certainly a NP problem. This linear equation is merely a guideline which makes it possible to better estimate the amount of time spend on the code review.

Read more articles on Agile, SCRUM or XP…

This means that for a project with 12 kloc – 1000 line of code – the equation would yield an answer of 30 hours (t^‘) for the review. Naturally the Cisco Systems study also states that a code reviewer must rest between reviews, otherwise the review would exceed the number of lines and time. Although the research didn’t produce a clear amount of time that should be spend on the review, it is clear that this should be a significant amount to encourage continuing effectiveness of the reviewer. From a time management perspective I would advise spending at least 1/3t or 1/2t in a task which doesn’t involve reviewing code. Meaning that review time should be multiplied by 1.333_R or 1.5.

How it is done in SCRUM?

In SCRUM the code reviews are more often done in conjunction with the development, although the practice of reviewing is the same the code is reviewed as User Stories are delivered. This means that the code is reviewed shortly after it is produced, meaning that the developer who wrote it has a better memory of what he did and why he did it. A review cycle should probably take about 1.333_R of the time of writing the code.

Continued refactoring of code by developers done in SCRUM teams allows for more review of code to be done outside of review cycles.

How it is done in XP?

XP is code reviewing and code testing on crack, Pair-Programming, Pair-Negotiation, Test Driven Development and Continuous Integration allow code reviews to be performed at as the development is happening. Additional external code reviews will still pick up issues, although the defect density will likely be lower than in traditional development methodologies.

Other best practices

The XP and SCRUM methodologies to review don’t negate the fact that coders should continue to annotate all difficult to understand code and should allow for code readability over optimization in all but the most extreme circumstances. And naturally check lists should be make to ensure that any cases which can not be expressed in automated tests are covered – such as certain memory management aspects. Lastly finding a defect is fantastic and should be awarded, every defect found should be treated as a magnificent step to creating truly excellent software.

Any developer whose code was found to contain a defect should know that statically 1 kloc contains between 15 – 50 defects^[3], also known as the defect density, it is to be expected that code contains errors, programming is an NP problem.

1. Best Practices for Peer Code Review
2. Best Kept Secrets of Peer Code Review
3. Bugs per lines of code