There is always talk about improving application quality. In many instances, a large quality program gets initiated that either takes a lot of resources and time or introduces change that is too challenging for the organization (or project team) to handle. It is usually better to start on a smaller scale. Focusing on improving application quality in the programming phase, a couple of suggests are: 1) initiate Peer Reviews (e.g., code reviews) and/or 2) initiate Pair Programming. While Peer Review is more widely known and used in the software development industry, Pair Programming offers more problem solving possibilities. Both are known to reduce defects and improve quality. The key is to introduce a small initiative like peer review or pair programming ensuring you are building the practice for success.
Peer Review
Implementing a peer review is analogous to adding additional sets of eyes to your work. A peer review provides the owner of the item under review with the added insight of other individuals also wanting a better software deliverable. Peer reviews can help both reduce defects and improve quality. The first place to start is to define and document the peer review practice you plan to use. To ensure you are building a peer review practice for success and have more perceived value, consider the following:
Working in a Closed Loop
There is a danger that peer reviews get seen as a nice exercise but with no validation that corrections get made. It becomes essential that the peer review has a closed loop process where the important defects identified get reported and tracked through closure. Using the code review as an example, there may be a number of defects found and they should be classified in a way that the critical defects (e.g., those considered severity 1 or 2) can be identified amongst all defects. Those critical defects should then be documented and tracked to ensure that the defects are corrected. This ensures the time spent on the code review has a positive conclusion.
Finding Peers
When you think of a peer in your profession, who do you think of? Within the context of a peer review, the peer should be someone who is within two levels of experience above or two levels of experience below. Including folks too junior can make the peer review a waste of time and including folks too senior can be overwhelming and intimidating. Also, including your boss or a person who has perceived position over you can be threatening. Therefore, consider who your peers really are and include them.
Identifying Standards
Identifying and conforming to a common set of standards help the peer review practice move from a subjective review to a more objective one. As an example, if coding standards are defined for a code review practice, then the standards can form the basis for the evaluation of code modules under review. Otherwise the code review can turn into a "my method for coding is better than yours". An effective way of keeping an eye on the
standards is to create a defect checklist that includes the standards (coding standards,
style standards, etc). Also ensure coding standards training is provided. Implementing coding standards helps objectify the code review leading to reduced defects in the current release. It also makes it easier to debug defects found downstream when common standards are applied.
Documented Requirements & Defects
Along with standards, it is important to have the requirements or defects available that
form the basis on why a particular code artifact is being created, changed, or fixed. Having this information can help your peers evaluate the change you are making in relation to the reason for the change. Again, this helps both provide background on the item under review and further objectify the peer review.
Pair Programming
Implementing pair programming is analogous to always having someone who is looking over your shoulder and looking out for your best interests. The approach to paired programming is when two developers work side-by-side taking turns on the same artifact or deliverable, one working on the code (and other items like design elements) at a single computer, while the second is constantly reviewing the other's work (e.g., like a continuous peer review). The first place to start is to define and document the pair programming practice you plan to use and share this information with the paired teams so they understand how to work together. To ensure you are building a pair programming practice for success and have more perceived value, consider the following:
Finding Peers
Similar to a peer review, when you are implementing a pair programming approach, it is
About the author
Mario Moreira is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “Adapting Configuration Management for Agile Teams” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “Software Configuration Management Implementation Roadmap.” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at http://cmforagile.blogspot.com/ . You may reach Mario by email at Mario.Moreira@cmcrossroads.com.
