Agile teams have a focus of interest- to continuously improve product quality.  In pursuit of this end result, teams often develop and agree upon engineering process changes. And when assessing potential process changes, stricter coding standards usually make the cut. Development teams are asked to abide by a certain set of guidelines in the code they generate, refactor, or maintain.  In practice, sometimes these guidelines end up improving product quality as desired, but sometimes these guidelines have no affect on quality at all. Or worse, sometimes these guidelines add only non-beneficial incremental overhead to the development process.

While most software engineers would agree that coding standards make sense in a group programming environment, the success or failure of these standards is a function of which standards are adopted.  While popular coding standards of the day or team members previous work experiences guide this decision making process, another alternative is for customer-reported defects to guide the process.  When a root cause analysis is performed on the customer defects incurred by a software development team over time, a few prominent causes are bound to occur again and again. These causes can usually be avoided through process changes, and in particular, through coding standard changes.

Customer-Reported Defects

Looking internally at our customer-reported defects over time, we certainly discovered some recurring technical themes.  For example, there were many defects that were associated with the programmer selecting recursion over iteration in cases where the problem depth was potentially unbounded.  The result was a sleeping time-bomb for stack overflow.

Another example, there were many performance-related defects involving the selection of an inappropriate container abstraction, given the expected data access patterns and performance requirements of the problem at hand.  (Your mileage may vary, but you get the idea.)  If the same group of people is evolving a code base over time, it is likely that over time, similar mistakes will be.

Agile software development puts the accountability for product quality squarely on the shoulders of the team.  Accordingly, self-managed software teams should be continuously evaluating possible improvements to the team’s behaviors, and coding standards is a great place to start.  If you want to avoid the pitfalls of choosing the wrong standards, take a closer look at your customer-reported defects.