Code Review: An Agile Process

Some Agile practitioners consider peer code review an unwelcome legacy that persists from the dark ages of waterfall development. As a result, they vehemently reject its inclusion in Agile projects. This paper demonstrates both how code reviews reinforce the key tenets that underlie Agile development philosophies, and also how code reviews can be conducted in a manner that aligns perfectly with Agile processes.

What Makes Peer Code Review Agile?

Some Agile practitioners consider peer code review an unwelcome legacy that persists from the dark ages of waterfall development. As a result, they vehemently reject its inclusion in Agile projects. This paper demonstrates both how code reviews reinforce the key tenets that underlie Agile development philosophies, and also how code reviews can be conducted in a manner that aligns perfectly with Agile processes. The fundamental principles of Agile development are discussed at length on the Agile Manifesto web site. The essential Agile Manifesto tenets value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Although Agile followers acknowledge that the concepts on the right have value, they value the concepts on the left more. The premise is to adapt to changes in requirements, respond to user needs faster, streamline processes, decrease development iterations, and enable higher productivity. All this enhances business value by making development more transparent and getting software to the market faster.

So how can code review support Agile processes?

Consistently, research shows that code review produces software with fewer defects, which aligns with the emphasis on working software. What could be more interactive than software developers collaborating about the code and making real-time improvements? As you’ll learn in this paper, code review fully supports Agile tenets by promoting the development of working software, collaboration and interaction among teams, continuous attention to technical excellence and the ability to respond to change – all while maintaining a high level of quality.

Consider three, well-known Agile shops: Apple, Google, and Microsoft. Like most successful companies that attest to being Agile, they enjoy high product adoption and loyal customers. Unlike Microsoft, Apple and Google are sticklers for code review, and their product quality reflects this added effort. Apple in particular delivers major upgrades and fixes to the market at an impressive pace. Both companies closely tie code review to their development culture; they “bake” code reviews into Agile sprints and iterations to identify potential defects earlier in their cycles. At these companies, code is never “checked-in” before it is reviewed. So why do so many software development teams resist adopting code review when industry titans attest to its success?

Moving Beyond the “Code Review” Stigma

Historically, the process for conducting code review has been pretty “anti-Agile.” As originally conceived by Michael Fagan in 1976, code inspections1 were a heavyweight code review process that led to an entire generation of software developers who believed that meetings were required to review code. Lots of meetings. Boring meetings that emphasized processes and tools over individuals and interactions.

The result is that today, heavyweight processes and meetings are regarded unfavorably by Agile devotees. This stigma tainted the entire concept of code review, causing code reviews to be perceived as an impediment by Agile project teams. Although this “guilt by association” has eroded over time, misconceptions still linger.

The biggest misconception is that you need a meeting to do code review. Although Fagan mandated meetings for his inspections, Lawrence Votta of AT&T Bell Labs was unconvinced that meetings were required. His study2 showed that when developers read the code to identify defects before the meeting, actually having the meeting only increased the total defects found by 4% (and consumed several hours of valuable time per meeting participant).

1M.E., Fagan (1976). “Design and code inspections to reduce errors in program development.” IBM Systems Journal 15(3):182–211. 2Lawrence G. Votta (1993).” Does every inspection need a meeting?” ACM SIGSoft Software Engineering Notes, 18(5):107-114.

Recent studies confirm that code review can be effective without meetings. Jason Cohen, founder of SmartBear Software®, conducted a study at Cisco Systems® which demonstrated that a lightweight peer code review approach was not only as effective as a heavyweight code inspection process, but also more time-efficient by a factor of 7.

Yet even Agile devotees who recognize that meetings are not required have misconceptions about code review. They say, “We only use the latest techniques here; code review is from the past and provides no value,” or “All the unit tests pass, so why do we need to do code reviews?” If you take away the meetings and the heavyweight process, but leave the interaction, responsiveness, and dedication to continuous improvement, then code review is very much an Agile practice.

The Economics of Peer Code Review

While we can make claims about the value of code reviews, we can illuminate these points with specific examples and quantitative evidence. Note that all of the companies profiled on the following pages employed CodeCollaborator as the solution of choice.

How Does Code Review Align With Agile?

For developers to be open to the notion of adopting code review in Agile environments, they must first accept the premise that code review can be agile. Delving into principles that underlie the Agile Manifesto provides specific evidence that code review is Agile.

Working software is the primary measure of progress. Software developers make mistakes. Some mistakes are detected automatically by unit tests, static analysis tools, etc. Just as professional writers rely on human editors and spell-check software to identify mistakes, developers benefit from having other developers examine their code.

During iterations, developers devote a lot of time discussing requirements with stakeholders and talk about the emerging design and architecture with other software developers. That’s true even when they tend to work in isolation to actually write the code (giving developers a reputation as introverts, at the very least). We know and accept that flaws are uncovered during discussions of requirements, architecture, and design. The same principle applies to the writing of the code. Code reviews not only uncover flaws, but they also offer another key benefit prized by Agilists – the feedback is kept close to the point of creation and happens sooner – before the code gets into the hands of either QA or customers.

Agile processes promote sustainable development. Project sponsors, developers, and users should be able to maintain a constant pace indefinitely. That’s a tall order. To meet this objective, Agile teams frequently practice collective code ownership. The goal here is to invite team members to get familiar with and understand the code base.

Collective code ownership fuels sustainable development in many ways, because it:

• Transforms team member focus from “specialist” to “generalist” in certain domains.
• Helps to eliminate delays that result when team members are out sick or on vacation.
• Helps to establish common coding standards.
• Fosters a common “look and feel” to the code base.
• Ensures that everyone is generating detailed documentation.

Continuous attention to technical excellence and good design enhances agility. All software developers have egos, and most are naturally curious people who enjoy learning new things. In anticipation of code reviews, developers tend to write better code, because they know that their reputation is on the line. No one wants to be thought of as the weak link in the chain.

An Agile Corollary: A developer who reviews another’s code can learn new tricks and techniques; a key step in mastering any craft is to benefit from the experience of others.

The Agile Case for Code Review: Find Bugs Early and Often

The Agile methodology is grounded in a desire to deliver working software in the most efficient manner possible. As Agilists work to achieve this goal, they generally accept that recognizing and eradicating bugs closer to the point of inception promotes software quality. But have these developers considered the economic impact of doing so?

A SmartBear customer set out to test exactly how much money they would have saved if the company had peer review in a certain three-month, 10,000-line project with 10 developers. The business tracked how many bugs were found by QA and customers in the subsequent six months. Then they went back and had another group of developer’s peer-review the code in question. Using metrics from previous releases of the development project, the company knew the average cost of fixing a defect at each phase of development, so they could measure directly how much money they would have saved if code review was used from the start.

The result: Code review would have saved more than half the cost of fixing bugs. Plus they would have found 162 additional bugs.

Why is the effect of code review so dramatic? A lack of collaboration in the development phase may be the culprit. With requirements and design, you always have meetings and invite input from customers, managers, developers, and QA to synthesize a result. You do this because mistakes in requirements or architecture are expensive and can lead to lost sales. You then debate the relative priorities, difficulty, and long-term merits of your choices and techniques.

Saving more than $200k: A real-world case study

Actually writing the source code, however, is a solitary activity. Since developers tend to create code in quiet places, collaboration is limited to occasional whiteboard drawings and a few shared interfaces. No one catches the obvious bugs; no one is making sure the documentation matches the code. Peer code review puts the collaborative element back into this phase of the software development process.

Consider: No book is commercially published without review by professional editors. Scan the acknowledgments in any book, and you find reviewers who helped “remove defects.” The correction and review process is a requirement to produce a high-quality work. (And even then, what author hasn’t found five more errors after perusing the first edition?)

Do we think it’s any different in software development? How can we expect developers to write pages of detailed code (and prose) without mistakes? We shouldn’t.

If “review” improves the quality of novels and software design, it also improves the quality of code. Peer code review adds a much- needed collaborative element to the development phase of the software development process.

Types of Lightweight Code Review

Lightweight code review provides the right mix of code review process with Agile practice, allowing effective and efficient code reviews without the overwhelming time investments and the burdens that result. There are four different approaches to lightweight code review. As with so much in the Agile world, each team must decide for itself which approach works best for them.

Timing Agile Code Reviews

The beauty of code reviews is that they not only can be timed to add the most value to your existing process, but they also scale easily in Agile environments to accommodate changing requirements and software quality benchmarks.

Effective code reviews can be invaluable to the Scrum methodology. In some Scrum teams, developers invest a target percentage of their overall capacity performing code reviews. In such environments, team members are encouraged to burn out their allotted hours for code reviews before the end of each sprint. They also apply best practices around defining tasks that are granular enough so that the code requiring review is in manageable chunks and does not overwhelm the review process.

Many team leaders attest to improvements to the overall Agile development experience as well as the productivity of Scrum teams when they designate code review as a requirement before a story can be marked complete. Such development organizations have succeeded in incorporating code review into their Agile processes and thus, reap the resulting benefit: higher quality software.

In reality, although higher quality software is certainly a tenable goal, actual metrics are needed to prove the impact of code reviews on software quality. At first blush, allocating time to gather metrics may seem anti-Agile. The question is, how can this endeavor be “agilized”?

Useful Metrics to Assess Agile Reviews

Say the word “metrics” and many Agile practitioners balk. In no way are we recommending that your Agile team implement a cumbersome metrics gathering process. What we do suggest is you choose metrics that are pretty easy to collect to gain useful insight into the value of code reviews.

Keep in mind two things:

• These metrics values are for illustrative purposes only. They vary based on the type of code you are developing. By obtaining and saving baseline data, you can see how code review adds value to your development efforts over time.
• Code review tools can save you substantial time and automate the collection of these metrics, analyze ratios, and generate related defect logs.

To make decisions and comparative analyses, analytical metrics can provide useful data across many reviews in a group by author, by group, by reviewer, or by set of files.

*”Defects” refers to anything that the developer wants changed in the code, e.g. a bug in the algoritihim, re-formatting of a comment, correcting a typo, etc.

**This is where contention can develop. A higher defect density means the code reviewers did a great job! It does not mean that the underlying source code is bad or that the developer coded improperly.

Overcoming Resistance

By now, we hope you understand how code review can be adapted to Agile environments and the sustainable business value it brings. Promoting adoption within the development organization is the next step.

Overcoming developer resistance to code review adoption can present real issues. Consider a key Agile Principle: The best architectures, requirements, and design emerge from self-organizing teams. It is the coming together of team members that breeds success; those who don’t believe in the process or the tool do not participate in the journey.

It should be no surprise, therefore, that when peer code review is mandated by someone outside the team, its chance of success is compromised. Further, when team members do not want code review to succeed, it will fail. The biggest reason for this is the contentious environments that ensue where code review results are used to measure the caliber of the developer rather than the quality of the code. Attempting to make developers appear at fault is an inappropriate application of code review results and reflects poorly on management that chooses to wield it in this manner.

Another stimulus of contentious review is when developers feel interrogated by those trying to understand why certain assumptions or decisions were made. For example, when a reviewer might ask, “Why did you use that API?” A less threatening way to elicit the same information might be to ask, “What was the idea behind choosing this API?” You will find tone to be a profound influence as developers adopt and accept the process of code reviews.

Even when team members support code review, they may still resist adoption. In these situations the key to success is to start slowly. This means not pursuing endeavors such as: “Starting today, 100% of all code written must be peer reviewed.” Instead, to get the best return from code reviews based on time invested, try restricting code reviews to only a limited portion of the source code.

Some examples:

• Have developers select the “Top 10 Scariest Source Files.” Only review changes to those files.
• Review changes made only to the stable branch of the source code.
• Target and review unit tests. Specify that only when unit tests are complete and passing, that the results validate that the underlying implementation is correct.

Broaden the amount of code that gets reviewed after a team has experience with code review and recognizes its value over time.

The beauty of lightweight code review is that everyone can win. Organizations that follow these guidelines will:

• Improve software quality by managing bug remediation closer to the point of inception
• Sustain business value by better aligning budgets with development effort and cycles
• Find that developers who experience the benefits of code review and are not threatened by its use will embrace it.