3 Toward a formal inspection [personal experience]

My current project develops and supports a home-grown scheduling application. The project follows "iterative process" for the software development. The project consists of a team of 16 developers, which includes release developers and maintenances. The team is very integrated. A developer can be either part of release development team or maintenance team depending on the release schedule. We don?t have dedicated expert testers. We depend totally on unit test (called IT testing) and functional test (performed by liaisons) to ensure the quality of the software. The software features have grown from release to release. Each release has a development cycle of 3 months. Given the delivery constraint, the project?s code is exposed to the possibility of high coupling, loose cohesion and structural corruption. This is a known drawback of iterative process. It happens when practitioners do not have proper and effective plans for refactoring.

The team agrees that this potentially affects the quality of the software and increase the maintenance costs. The team considers exploring code review techniques to address this concern. However, due to lack of experience we do not how to do inspections. To get it starting, the maintenance team of four developers includes code reviews in the bug fix process.

The maintenance team started with walk-through. Each developer presented his fixes to the team during a 2-hour review session, and resolved any errors detected by the review after the session. The developer re-presented his works in the follow-up session depending on the severity of the changes. This simple review process significantly improved the quality of the code and minimized potential side-effect of maintenance fixes. Code standard and style are enforced. Runtime exceptions (e.g. NullPointerException, ClassCastException) were detected and corrected. The team started with a simple checklist which included: checking for compliance to the code standard and style, detecting runtime exception, and analyzing exception handling. Defects and problems found during the code review were analyzed to determine its causes and effects. The review checklist was updated to prevent defects from reoccurring. As implication of the code review, developers spent more time and efforts during fixing to analyze a defect. Developers used flowcharts to present their analysis, and assess risks associated with their fixes. Developers also looked for opportunity for code refactoring.

After implementing for about a year, the team faced new challenge. Developers became familiar with coding convention and style. Their works met the team?s standard requirements. Participants in the review had minor things to suggest. The review session turned to less interesting, besides sharing information about bug fixes. To booster the effectiveness and efficiency, the team added more features to the process adopted from a more formal software inspection. However, it was still a baby-step. A bug fix was required to be signed off by one or more developers depending on the size of the fix. Developers were assigned to be a sign-off for a fix one week before the review session. The sign developers were expected to perform an in-depth inspection of the fix, and present questions or suggestions to the owner before the review session. The main purpose was to have someone look into other fixes more seriously. This was very beneficial to the quality of the fix, minimizing its risk of injecting new unknown defects.

Currently, the code review process of our team is somewhat formal. An inspection checklist was crated. Each developer follows the checklist to review peers' code. The review session is 2 hours every Wednesday and Thursday. Defects and problems found in the review session are analyzed to find the root cause and how to prevent them from reoccurring. The checklist is updated accordingly if necessary. The team tries to keep the check list simple, precise and intuitive, even though it has been modified and growing. We are moving forward to improve the review process, and extend the review coverage beyond maintenance team.

4 Discussion & what learned

4.1 Lesson learned

What I learn from the literature reviews and the interview is that a software inspection provides more benefits than costs to an organization. Benefits increase and costs decrease when the organization gains more and more experiences in practicing a software inspection process. Inspection costs are largely due to ineffectiveness in preparing, conducting and monitoring an inspection. This is caused by lack of experiences, management inattention, and management commitments. Other factors contributing to an ineffective inspection process include: organizational culture, maturity level, size of project, and resource availability.

However, I think any organization can adopt an inspection to its software process regardless size and maturity of projects. Inspection costs can be reduced by such factors as: training, a realistic scope, proper preparation, effective performance of inspection meeting, monitoring, and evaluation.

An organization which is new to the inspection process can start with a basic process "code walk through" and then gradually moves toward more formal inspection process, as needed. The purpose is to get developers involved in the inspection process. When they are comfortable with sharing their code with peers, a project team can move to improve the quality of the code. To avoid frustration and resistances from developers to the inspection process, the inspection can focus on bug fix and maintenance works which do not involve a large amount of code. The organization needs to create an inspection process and coding standards to meet its own needs. The next section 4.2 proposes a process which can help a project to integrate an inspection process to a software development process.

4.2 Process Road Map toward a formal inspection process

A process for integrating an inspection is discussed as follow:

Stage 1: get start with "Hello World"

• Involve all project members to create standards, styles and coding conventions used for the project or organization
• Involve all member to create an inspection checklist (the simple and short), focusing on standards, styles and coding conventions.
• Start with a simple code review (walkthrough)
• Confine the scope to bug fix and maintenance works.
• Conduct an review session of two hours every week
• Maintenance team leads the code review
• Include at least 4 developers in the maintenance team
• As entry criteria, code fix is checked in to a control version system (e.g. CVS), and problem descriptions or requirements are written and available
• Inspection is not used as an exit criteria for development work

Stage 2: involve new developers

• Include one or two developers from other teams in the code review session
• Analyze defects or problems found during the review, and determine how to prevent them in future
• Update the inspection check list as needed
• Assign a developer to review bug fixes before the meeting. This person is expected to review the fixes thoroughly.

Stage 3: expand inspection scope

• Expend inspection to include larger code (with less than 2000 line of codes) which is not bug fix or maintenance works.
• Use the techniques (checklist-driven, use-case driven, and abstraction-driven) discussed in section 2.3.2 for code reading
• Not every code for non-bug fixes needs to be inspected
• Provide training to developers in the current inspection process, and in a formal inspection process.

Stage 4: formal inspection

• Adopt a formal inspection process in section 2.3.
>

My experience revealed that moving from one stage to another may take a year or longer. It requires management support and motivations. My current team is moving toward stage 2 after practicing a code review for bug fixes about more than a year. My previous small team in IBM stayed in stage 1. One main reason is cost effectiveness of the process.