Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Vikas Hazrati on Mar 07, 2008
In an interesting article on Design and Code reviews Kirk Knoernschild mentions that such reviews promise to improve software quality, ensure compliance with standards, and serve as a valuable teaching tool for developers. However, the way they are performed affects their value. In some organizations they might really add value to the software lifecycle whereas in others a review might just be a part of the bureaucracy.
He mentions some of the worst review practices as
Witch hunt reviews - Causing the developers who wrote the code to feel threatened and attacked.
Curly brace reviews - Emphasizing just on structure and indentation instead of serious issues.
Blind reviews - Reviewers have never looked at the code before and come to the review meeting unprepared.
Exclusionary reviews - Reviewing only a sample of the code and leaving out other important pieces.
Tree killer review - Waiting until the codebase becomes so large such that neither a complete review is possible nor effective.
Token review - Doing the review as a formality just because the management intends to get it done.
World review – Conducting the review infront of a huge audience, many of whom are not related to the project, there by intimidating the developers.
Kirk seems to mention that in order to do effective reviews; the team should try to automate the review process as much as possible and gather metrics. The team should try to incorporate feedback mechanisms in their existing development environment so that the developers are alerted about the red flags before they are ready to check in code.
He mentions some tools which help in bringing greater objectivity and focus to the review process, like
Kirk further mentions an interesting way to do reviews, called the 20% review
The idea behind the 20% review is simple: once 20% of development is complete, a review should be held. Some teams might find it beneficial to hold the 20% review each iteration. That's certainly effective, but I've found that if teams do a good job using metrics for a continuous review, holding the 20% review for each major system function is sufficient.
The 20% review should focus on initial design and code cleanliness. The metrics discussed above offer wonderful insight into the evolution and growth of the code while the size is still relatively manageable.
He concludes by emphasizing that using metrics to help drive reviews brings greater objectivity and focus to the review process.The greater the automation the easier it would be to arrive at those metrics and thus do an effective review. The review should also be held early enough so that the developers can utilize the learnings early on and the effectiveness of the review is not compromised.
Agile Development: A Manager's Roadmap for Success
Right Collaboration Architecture Drives Business Transformation
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
FYI, You have some bad links in your article
Seb
The proper link is:
www.agilejournal.com/articles/the-agile-develop...
Dave Rooney
Mayford Technologies
Thanks for your tact! Actually all the links were broken due to a formatting error.
Fixed! Apologies for the inconvenience.
...so why not do them in real-time? It's called Pair Programming! :)
Dave Rooney
Mayford Technologies
Dave I totally agree with your statement. The problem is that in many companies, though they follow agile, pair programming has not really caught up as a result there is a need to do peer/formal code reviews later.
I know a team of around 80 people split into smaller scrum teams who are not pair programming but they do want to wrote great code and do want all the team members to learn from the reviews.
Vikas Hazrati
vikashazrati.wordpress.com
Why do you use PDF icon for links at the bottom of your article? I saw this on other articles and other places on your web site too.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
6 comments
Watch Thread Reply