Tackling the Problems
To tackle the problems, the technical manager responsible for the department commissioned the development of an in-house training program directly aimed at improving the quality of the code the team produced. The training was based on the book Code Complete by Steve McConnell (a highly recommended read for those doing development-related work), which lays out the techniques, strategies, and practices used to create high-quality code.[9] As such, the book directly addresses the higher-order thinking skills needed in order to become an "expert" developer.
The training material was created by translating the strategies in the book directly into code fragments that were meaningful within the context of the organization. Each key idea from the book was communicated as part of the training, and real code from the organization's code base was used to demonstrate how code could be structured in different ways to improve readability, reduce the amount of code needed in order to achieve a given result, and improve overall quality. The restructured code fragments (as well as the steps taken to do the restructuring) were built into a set of four half-day workshops that were conducted over the space of a few months.
The program is interesting because the organization maintained a set of metrics that allowed the effect of the training to be measured. Comparing the one-year period prior to the training with the one-year period following training yielded the following results:
- The amount of effort the department spent fixing code defects that had made it through to production dropped by 52% (and even then, much of the effort in the year after training was absorbed in fixing defects due to problems whose origins predated the training).
- Productivity improved by 30% (measured in average source lines of code written per person).
In addition, two specific projects (one completed prior to training and one done after training) were compared in detail (both contained approximately the same amount of code and were of similar functional complexity). The first project suffered eight production failures in the six months after production release, while the second had no such failures. The percentage of newly created code found to be in overly complex routines (measured using cyclomatic complexity)[10] dropped from 36% to less than 3%. In plain English, the code was simpler and that in turn would imply reduced maintenance costs in subsequent years and lower initial defect rates.
In part, the program was successful because it directly contrasted good and bad practice. By providing clear visual parallels, the contrasts made people directly consider the advantages and disadvantages of different approaches. As such, the program was directly structured around the analyzing and evaluating levels of Bloom's Taxonomy.
9. McConnell, Steve. Code Complete, Microsoft Press, 1993.
10. "Cyclomatic complexity" see Wikipedia: http://en.wikipedia.org/wiki/Cyclomatic_complexity.
|
Introduction
