Code review roundtable

Roundtable:
Scott Newman, Webplan
Carl Orthlieb, Adobe
Francis Beaudet, Macadamian
Dan Leroux, Rational
Frederic Boulanger, Macadamian (moderator)

The roundtable format was well suited to the discussion on code reviews - insightful discussion was generated both among roundtable participants and the audience. Some of the highlights:

• At Rational Dan's team has been a sort of pilot project for code reviews. They are currently going through a team discussion to gather feedback on what worked and what didn't in implementing code reviews.
• Dan has found one of the key benefits to peer reviews at Rational is mentoring - to bring the new team members up to the level of expertise of the more senior developers. New developers on Dan's team are required to have all of their code review by
• Kevin noted that Entrust has taken a very rigorous approach to determining the return on investment for implementing code reviews. Going back several months they studied bugs that were discovered in the field, and tallied up the support costs and the cost of fixing them post-release. They found that many of these bugs could not feasibly be caught in testing and could only have been discovered in a code review. Comparing the costs of fixing the bugs post-release and conducting code reviews pre-release showed a clear ROI for implementing a code review process.
• On what motivated the panel members to implement code reviews in the first place:
  • Carl explained that at Adobe, it was risk mitigation - you don't miss a ship date at Adobe, and code reviews brings an extra level of predictability to the cycle.
  • At Rational, Dan noted that the motivation was that it was hard to get coverage on some products, and that code reviews are the only way to uncover certain defects.
  • Francis explained that at Macadamian, code reviews became a rule after working on the Wine project with Corel. As an open-source project, Wine worked under a single committer model, where patches were sent to a mailing list and were scrutinized by a project lead, who was the only person with access to commit changes to the source-code control. At first this was frustrating, but the team began to take a great deal of pride in writing code that would be accepted on the first pass
• On lessons learned:
  • On Dan's team at Rational, developers had the tendency to always go to the same person for peer reviews. It's important to make sure that the team goes to different people each time to get a fresh set of eyes looking at your code, and to make sure everyone is getting experience doing code reviews.
  • Review code often in small increments. There was a tendency to dump a 19 page review on a peer. No one can review that much code in one sitting and be thorough and effective.
  • Code reviews are a lot easier to implement on new projects, rather than trying to shoehorn into an ongoing project
  • To get buy-in from the team, implementing code reviews can't come from a decree from management. At Entrust, some of the senior, well respected developers led the charge to put code reviews in place.
  • Stay the course - if you're implementing code reviews for the first time on a new project, halfway through the project it might feel like you're making less progress. The temptation will be there to be lax on the process.
  • A positive side-effect of code reviews is you can also catch curse words and unwanted Easter eggs (some have an automated process for catching curse words in code)
  • Be careful to avoid rehashing design decisions as a result of code reviews. It was the panel's experience that sometimes a code review could result in unearthing a design decision that was finalized months prior - "if you hadn't designed this way, I wouldn't have had to write the code that way"
    

Discussion on support contracts

The roundtable was followed by a discussion on support contracts. Kevin was starting to see several requests for extending the duration of their software support obligation. For example, today Entrust provides Level 1, 2 and 3 support for a given product release for 2 years. Larger customers are showing a tendency to want to stay with older releases that are in production - "it's working, why should we upgrade?" Several customers are asking for longer support contracts and he was curious to know what other companies in the group were doing.

We found that there was no definitive standard yet. Some companies were still on a two year standard agreement, while some have moved to three and up to five. It was noted that you have to account for not only the cost of keeping older versions of software (compilers, operating systems, etc.) to support older releases, but also hardware. Most people seem to have special agreements with their larger customers who stick with older product versions that cover the extra costs.

Copyright 2002 - Ottawa Software Executive Forum - All Rights Reserved
To Comment on our Web Site - webmaster@ottawasoftware.org