QC 5: Review & Rework or Repent…

A software product is conceptualized at requirements stage, embodied in design stage and realized in development stage. During this critical stage of development, the typical work breakdown would be Coding, Unit Testing, Review and Rework. Hence, this would be a template for developing individual modules prior to their integration into the next higher level abstraction layer.

Review and Rework go hand-in-hand with Unit Testing as will be evident from the post below. Review is the process by which the developed piece of software is subjected to 360 degree scrutiny. This scrutiny is to verify if the code under investigation actually adheres to the norms decided and agreed upon during the starting phase of the project. Basically, Review provides a milestone, crossing which one can assume that the software product adheres to the group-level and module design-level objectives. However, review is not a substitute for verification and validation and both have their own mutually exclusive value-add. Review shouldn’t be employed as a substitute for any other step in Software Development.

During the review process, software code is shared along with supporting documents to a review panel. The panel is usually decided at the group level, but can ideally be left to the author and group leaders. Selection of a review panel should be intelligent and augur well for the quality of the product as well as the short and long-term goals of the project. A good review panel will consist of a judicious mix of Seniors, Peers and Juniors as compared to the author of the code. Skewing on only direction breaks the equilibrium and as with any other system, it does more damage than benefit.

There is a specific reasoning behind constituents of the review panel. Seniors provide a different perspective as compared to the authors. Having been part of the industry longer, they will have some tips and tricks of the trade up their sleeve, which is handed down during these review processes. From a knowledge perspective, peers contribute and get contributed into. The knowledge gained during one review process is immediately catered to in their own module development. This way, there is a continuous, incremental and positive change from a software quality perspective. Juniors in the team should be made part of the team due to numerous reasons. One, they feel wanted and have a good feeling that they are contributing into the project. Being part of the review discussions, a large amount of knowledge and true-world wisdom would be discussed, some of which will be absorbed by the juniors.

Review process follows a pattern which is more or less the same across projects and organizations. The typical review process is described using the flow path below:

(1) Coding has been completed; Module has been Unit Tested
(2) Review Panel Decided; 
    Initial Review Meeting is held where code under review is described

(3) Review Panel Reviews the code and comes back with Review comments

(4) Review Team meets and discusses the comments

(5) Once comments have been accepted, Rework and Unit-Test is performed

(6) Testing complete mandates another round of quick review and verification

(7) If Review Panel is satisfied about all the changes, process is closed

During the review process, aspects related to code documentation, coding guidelines are typically discussed. However, review also provides an excellent platform for discussion on optimization aspects of the module. Better ways to realize the software modules’ objectives while optimizing the processing/memory needs of the system is captured during this process. This provides a very valuable and priceless insight into the system for all the stakeholders involved, especially the juniors on the team.

Rework is typically based on the review comments. Some of the rework may involve only aesthetic/cosmetic comments which should be straight-forward. However, any module level optimization comments tend to involve a higher rate of change and can easily run into days. Any change warrants another round of unit-level verification and validation. This should be understood and imbibed by one and level and ideally, software developers should be very adamant on the same.

Unit-testing has immense value, some of which were discussed in earlier blog-posts. However, one critical point to be brought up in this scenario is the need for testing. I will quote one of my trainers (Mr. Ashok) from 6-7 years ago. Testing is not to prove that your stuff works. Testing is to disapprove that your stuff doesn’t work.  This is a whole different dimension as compared to the typical norm and should always be remembered as a mantra.

In today’s fast paced world, patience is a virtue that is fast dwindling and people live in the fast-forward age. Review as a step is prone to being skipped as an unnecessary evil. This is an extremely bad programming practice which developers don’t appreciate and understand. Confidence is always a nice attribute to have. However, verification by an impartial 3rd party only cements one’s own value system. The confidence should be towards having a fewer number of comments in scrutiny rather than not scrutinizing at all. This is one of the most commonly observed mis-placed practices, which should be abolished in the bud. Skipping review step should be at one’s own peril and in any quality oriented organization, this is never the case.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s