Maintaining Quality in an Agile World With Static Code Analysis

W. Noah Kruswicki, Quality Assurance Analyst

Most developers are not granted the luxury of developing new code for new projects. Unfortunately for most developers, they are saddled with old code bases that have ideas from 20 or more years ago. To put that in perspective, large-scale commercial development has only been around since the early 1980s, so living with coding decisions made 20 years ago is like being stuck with the person you were as a teenager.

Modifying legacy code can be as difficult an experience as telling your teenage self what’s best. In order to make changes easier, an understanding of the entire code base is essential. When working in an environment with a great deal of legacy code, it’s often difficult to find time to get a full understanding of the code base; in an agile environment, it’s even more difficult. Static code analysis reduces the learning curve by taking a holistic look at the code and spotting errors that may arise by introducing new code.

How did we get here?

Code has several quality stages before it goes into production. Traditionally developers would create code, which would be accompanied by a unit test. Assuming the unit tests pass, the developers would give the code to the quality assurance department for testing. When bugs were found, QA would send the code back to the developers for modification. This cycle would continue until the QA department agreed the code was ready for production, at which point, it would often go through another round of testing in a staging environment.

When agile started moving into development shops, the traditional model was quickly seen as incompatible. In an effort to move more quickly, the onus of quality was moved from QA to development, and QA professionals became quality mentors. This model works great for products that are not very large in size and have very limited complexity; in the real world, this is rare.

As the complexity and size increased, developers were faced with a choice: spend less time developing and more time getting a complete picture of the code base, or gamble a bit with quality.

What we can do

Enter static code analysis. Static code analysis is the process of examining code without running a program. This often means checking for errors like empty blocks of code, file streams that never got closed, and null pointer exceptions. Many developers have probably seen a form of this when developing in their favorite IDE; the little squiggly lines of shame that show up when you have made a mistake. This, however, takes a narrow look at your code base, and as such, provides a very limited view of potential coding problems.

Static code analysis tools often go beyond this limited view, to get a more holistic view, thus providing a greater sense of potential issues. For instance, static code analysis may catch code that will never run. This kind of analysis might not be caught by an IDE or compiler.

As complexity and lines of code grow, the ability for a human to do a code review and really grasp what impact these code changes or additions have on the code base, becomes next to impossible. While static code analysis does not replace a human code review and code understanding, it does lessen the burden put on the developer. In an agile world with shorter sprints, this allows developers to focus on code, without having to take shortcuts on quality.

---

W. Noah Kruswicki is a Quality Assurance Analyst with Accusoft, with nearly five years of quality experience. Noah graduated from Lakeland University in Sheboygan, WI with a Bachelor’s degree in Computer Science.