A Review: How to Make Software Peer Reviews Work
During software check, a quality of a respective product is inspected within the system development cycle. Kala Ranganathan’s article How to Make Software Peer Reviews Work provides a handful of constructive explanations and suggestions on how to advance formal software peer reviews and arrive at your preferred outcome. She bases her conclusions on the real-time statistical information and recent case studies in the field. According to them, a review system can reduce errors up to 10 times during each testing stage, which results in a significant reduction in testing costs.
As a norm, a peer review is conducted by a small team of professionals, who examine given software for defects, based on a set of objectives. The team aims at finding, logging, and categorizing each defect, followed by resolution. Apart from managers, who are excluded from participation, each participant is assigned a unique role of moderator, author, presenter, recorder, or reviewer.
Based on her considerable experiences as a software consultant, Kala Ranganathan pertinently seeks an answer, why formal reviews often fail in the real world corporate environments. First of all, the whole testing process is so difficult and unproductive that it can inevitably lead to a dismal failure. Secondly, there are the so called “hidden problems” present in a number of these environments. Hidden issues are the real enemies that stay behind the participants’ distress. The author mentions the following reasons: pressure and stress, and company hidden agendas.
Further on, Kala Ranganathan provides useful guidelines for a thriving peer review outcome. Flexibility is the key, when conducting reviews and expecting a positive end result. It is often desirable to break a day up into mini-reviews, use enough time for breaks, or hold the sessions off-site. In case you find yourself seriously behind a schedule, be wise and stop the review and reschedule it. Noteworthy to remember, the payoff is the biggest during the early stages, therefore, it is a hundred times cheaper to fix a bug in the requirements phase than to do so during maintenance.
