It’s quiz time – stop and think for a moment. What constitutes the biggest waste of time in your software development cycle? When I first pondered this question, my mind immediately went to one topic: code reviews. Or perhaps I should rephrase the question – what’s the most often ignored component of your software development cycle? It’s not uncommon for development teams to simply ignore code reviews altogether!

With a skeptical chuckle I began my search for development tools relating to code reviews. Among all the information relating to code repositories and agile methodology information, I discovered a fresh, new approach to code reviews.

The trouble with code reviews

I open my mail – “Subject: code review tomorrow.” Ugghh – a shiver rolls down my spine. My mind immediately shifts to how many of my tasks aren’t going to get done this week now. And sitting in a room for one to two hours when I only really have feedback on about 20 percent of the code feels like a waste of time.

I don’t think I’m alone in this sentiment. But that’s not to say code reviews are useless – quite the contrary if done effectively and efficiently. Some considerations to optimize the effectiveness of code reviews include:

• Pick the right amount of code being reviewed. Too many lines of code and it’s difficult to expect the reviewers to spend the time required to have good feedback. Too few lines of code and it takes too many meetings to get through all the code.
• Providing ample time for the reviewers. Reviewers usually write code too. The value of the feedback is limited if the reviewer simply doesn’t have time to do a decent job reviewing the code within the time allotted.
• Don’t waste time during the meeting. Running effective code reviews can be difficult. Often reviews devolve into the code owner going through dozens of files line by line explaining what the code does. Sometimes issues get brought up for the first time in the code review by the owner, which doesn’t give the reviewers adequate time to think through options and determine the best solution for the application.

One overall problem is that code reviews require reviewers to multi-task. Multi-tasking can introduce inefficiencies, especially when the multi-tasking requires the developer to stop their development, review code, then be somewhere at a fixed time to listen and comment on the code. However, it is possible to add some efficiency back in.

A new approach

The many difficulties and inefficiencies with code reviews requires a significant re-think of the process. Klocwork has applied a collaborative social media paradigm to the code review process, then integrated this new paradigm within popular integrated development environments. The product is called “Cahoots” and the paradigm promises to streamline code reviews, maximize efficiency, and eliminate wasted time.

How it works

What does it mean to “socialize” the code review process? If you’re familiar with how social media works (who isn’t these days?), it’s a community of individuals that interact by posting opinions and information while also commenting on others’ spaces.

Developers are constantly writing code under time pressures and typically do their best to implement clean and efficient algorithms within the time constraints. Multiple times during code development, a developer thinks, “I know George has experience with this kind of algorithm” or “this isn’t the best algorithm, but I’ll come back to it later.” Unfortunately, the best of intentions often ends in no action as the developers move on to the next important implementation task.

Let’s apply a social media paradigm to code development. The implementer’s source files represent their “message board.” While writing the code, any questions or issues that arise can be annotated without leaving the environment. The implementer may already do this by adding comments in the code that point out possible problem areas or areas that need refactoring or optimization later. But the problem with comments is they have no proactive properties – they sit in the code and the implementer must keep notes and/or remember the areas they annotated.

Bringing these annotations to life at the same time the code is being written has some powerful benefits. If these annotations behave more like social media broadcasts by the implementer, followers can become immediately aware of these thoughts and respond more quickly and on their own timeline. This maximizes the opportunity for a reviewer to study the code, ask specific questions, or provide additional options. This kind of environment reduces a large group code review task into many small request/response tasks that can be responded to as time allows. The system can also keep track of these comments, tasks, and responses and not pass the implementation phase of the project until all of the annotations are cleared.

Cahoots nuts and bolts

The Cahoots environment can be used from within a variety of popular Integrated Development Environments (IDEs) or by using a command line tool. The tool can be used with any text-based file and has syntax highlighting and special options for C, C++, C#, Python, XML, Java, and other popular programming languages. The tool doesn’t require the implementer to switch back and forth between their code and some logging/notes tool, which saves time and makes adoption much easier.

The user interface is intuitive and allows implementers to launch a review and get everyone participating. Adding re-viewers and tags directs the right people to specific areas of the code to lower the learning curve for everyone and get re-viewers with the right expertise spending quality review time on the right code (Figure 1).

 

 

The tool also integrates with bug tracking systems, email servers, and websites.

Reporting, status, and metrics

It can be difficult to measure the effectiveness or coverage of a code review. Sure, you know what files are covered – but where was the time spent? What files were glossed over? The Cahoots system enables anyone to filter review information based on code revision, actions, and comment/response annotations by creating full text and keyword searches. This way each reviewer can efficiently identify specific areas where their expertise is required. Changes in the code can be looked at in-line or side-by-side. The drag-and-drop reports show the effectiveness and frequency of code reviews for each developer. Project leaders can quickly identify if there are people who need help managing their reviews and people who are making frequent use of the code review tool.

The reports also enable searching of reviews, how long they are taking, and if any reviews are stuck. Reporting tools help developers keep track of what they are finished with and what they need to do next (Figure 2 on following page).

 

 

Roles

The Cahoots environment defines multiple roles within the environment – the originator/developer, the reviewer, or a moderator. The developer is the person implementing the initial code. At any point (perhaps they’ve created the overall stubbed out solution, or maybe they are implementing specific classes or algorithms) the developer can select the “Create Cahoots Code Review” and begin the process. Reviewers can be added within the code review creation window and code can be tagged based on project and feature. Each role can see all file changes and comments can be added in the code from the Cahoots code reviewer window. The reviewer role can “create action” that recommends something be changed, refer the developer to external resources, or actually change the implementation if desired.

Agile development synergy

For those that advocate things like Agile development and pair programming, perhaps the initial thought might be “this takes away from the collaborative nature of face-to-face interaction.” And it does remove an element of this. Perhaps the optimal strategy is to do a mix of both strategies.

For example, let’s say I’m implementing user story XYZ within our agile development process that breaks down into five tasks. In general, it would be natural to assume code reviews on each task at a minimum. There might be specific code block development where expertise is needed outside a formal code review. These areas can be quickly annotated and feedback can be given without disturbing the process and wasting the overall team’s time. Doing small partial commits and performing team member pre- and post-commit reviews might be another time to use the Cahoots environment. Cahoots is also valuable to identify areas of the code that generate “why is the code like this?” kinds of comments. Those kinds of comments naturally identify areas of the code where a team code review meeting could have significant value. Using this kind of paradigm, then knowing when to launch a code review meeting can be invaluable to maximizing the benefit and efficiency of code reviews.

Improving code reviews

Code reviews can be a sore spot for many development organizations for a variety of reasons. Applying a social media interaction paradigm within the IDE can be a solution that maximizes team member efficiency and effectiveness. And just maybe it alleviates some of the dread associated with being a participant in the code review process.

Informational links

• http://download.klocwork.com/resources/cahoots/videos/ide-code-reviews
• http://download.klocwork.com/resources/cahoots/videos/command-line-code-reviews
• http://download.klocwork.com/resources/cahoots/videos/participate-in-a-review

For more information, contact Curt at [email protected].