As applications grow increasingly complex, more and more organizations are turning to static code analysis tools to ensure that code meets uniform expectations around security, reliability, performance, and maintainability.
Many evaluators take a common approach to selecting a static code analysis tool for their group or organization: they run each tool on the same code, compare the results, then choose the static code analysis tool that reports the most violations out-of-the-box.
This isn’t really a static code analysis product evaluation; it’s a bake-off. And the winner is not necessarily the best static code analysis tool for establishing a sustainable, scalable static analysis process within the team or organization. In fact, many of the key factors that make the difference between successful static analysis adoption and yet another failed initiative are commonly overlooked during these bake-offs.
Here are some steps for selecting a static code analysis tool that your team will actually use: one that suits your current situation and will grow with you as your needs evolve.
Assess Your Static Analysis Needs
Before you start searching for a static code analysis tool that meets your needs, you need to take a brutally honest look at where your organization stands today and where you hope static code analysis will take it.
Things to Consider:
What specific pains are you hoping to address with static code analysis? For example, do you want to eliminate specific performance or stability issues that have been troubling you? Reduce the length and number of QA cycles? Make code more reusable and easier to extend? Satisfy regulatory compliance expectations?
Is your development process stable, repeatable, and streamlined enough to provide a strong foundation for static code analysis? Are there weaknesses you should address first such as a lack of a fully-automated build process?
If you tried static code analysis before, why did it fail? What can be done to prevent the same obstacle from stopping you this time?If you tried static code analysis before, why did it fail? What can be done to prevent the same obstacle from stopping you this time? Organization structure: How is your development organization structured? Will there be a fixed set of quality policies organization-wide and/or more specific rule sets to suit the needs of specific projects and teams?
How will static code analysis efforts vary across your current projects? What new projects are anticipated in the foreseeable future and how will static code analysis apply?
Where do you want your organization to be in terms of static code analysis 2-3 years from now? 10 years from now?