If you’re not doing static code analysis (aka static analysis), now is the time to start. Delivering code faster has dubious value if the quality degrades as development cycles shrink.

On the other hand, if you’re not doing static code analysis, you’re not alone. Despite the mature age of the tool category, not a lot of developers are using it — still. In fact, Theresa Lanowitz, Voke founder and CEO of market research, believes, based on a past survey, that only 15% of developers are using static analyzers today.

“If you’re working on something that deals with compliance and regulation, you’re probably using static analysis solutions,” said Lanowitz. “Aside from the highly regulated areas, static analysis is not broadly used.”

There are several reasons why developers aren’t using the tools. For one thing, they’re already using a lot of tools, and the list continues to grow. For example, developers at professional services firm Avanade use six different tools during the coding process.

“That’s a lot of tools. They all do different things, so they’re all important, but if you have to run six tools every time you do a build, that’s a lot of overhead to run,” said Jasen Schmidt, director of solutions architecture at Avanade.

Schmidt is a big proponent of static code analysis tools for several reasons — quality, enforcing corporate standards and security. They also allow him to spend more time on higher-level issues than he’d have the luxury of doing without the tools.

Meanwhile, developers everywhere are feeling the pressure to produce, so the last thing they want to do is slow down their processes. However, delivering code faster does not mean delivering better quality code faster. Static code analysis tools help developers avoid nasty surprises in production that are far more time-consuming and expensive to fix than errors found earlier in the SDLC. In fact, following are five ways static code analyzers can save your bacon.

#1: Get early feedback
Static code analysis provides insights into code errors. While the tools won’t catch every defect and they’re not a replacement for other tools such as dynamic code analysis, they are a staple that more developers could be using to improve their code quality.

“One element of shift left is code analysis. As far as the implementation is concerned, that is the key step,” said Joachim Herschmann, research director at Gartner. “When I feel I’ve finished a small piece of functionality, I want to get feedback about a number of things: Am I documenting what I’m doing? Am I following standards? I want to find anything that could cause a security vulnerability or the code to crash.”

Granted, there are different kinds of static code analysis tools, some of which are specific to security, specific languages or particular types of errors, while others span multiple languages and code quality issues. In fact, organizations may run several different kinds of static code analysis tools, to take advantage of their respective strengths.

“You have to look at it in the context of what you’re doing,” said Herschmann. “If you’re consistently using quality metrics like cyclomatic complexity, it will give you an indication of whether they’re going up or down. I may have added a significant chunk of open-source code or made a fairly substantial code change that has resulted in more or less complex code. Without a static code analysis tool, it’s more of a gut feel I have as a serious developer, but that’s not the same as having an accurate report or measurement about how my code change has affected overall code quality.”

#2: Advance best practices
Most static code analysis tools are rulesdriven, so it’s important to make sure the rules align with what the organization is trying to achieve. For example, in some highly-regulated environments, the rules help ensure safety compliance.

“There are a number examples of where there are fairly rigorous coding standards, so you want to make sure your developers are adhering to the standards for audit reasons,” said Herschmann.

However, rules aren’t always driven by regulations. They’re also driven by corporate standards and security standards.

“Sometimes you have a mix of senior and junior developers. [Static code analysis] allows the junior developers to work independently without guardrails while making sure they’re developing along the lines of the team’s expectations,” said Avanade’s Schmidt. “That’s the set of rules that no one actually teaches you or there are no documents saying you must write your code this way. The tool will kind of teach them as they go.”

As the junior developers learn what the static code analysis rules are over time, it helps them as they blossom into more senior positions. The downside can be over-dependence, though, when developers get so caught up in what the tool is saying, they’re not thinking critically about why the error message came up in the first place.

“They also may not ask whether the tool wasn’t right in the first place or if the rule wasn’t applicable,” said Schmidt. “[However,] as a development lead, knowing that your team is running those tools allows you to focus on reviewing your team’s code from a logic and functionality perspective instead of focusing on some of the more basic code standards, rules and error checking type practices.”

“Static” does not imply that the rules the tools enforced are static, however. The rules need to be maintained to ensure they reflect the general code quality the organization wants to enforce. New laws, regulations, or even a merger or acquisition can necessitate change.

“In the past I was able to [adhere to rules] without the use of tools, but it’s going to be less and less likely I can do this going forward, because things are accelerating,” said Gartner’s Herschmann. “Now I have much quicker iteration cycles. At the same time, scale and complexity increases. Just think about how the industry is shifting from the monolithic applications to something that is more microservices-oriented, so now I have pieces developed by different developers, perhaps in different languages.”

Static code analysis helps enforce best practices across the developers building microservices.

“Having tools like this helps to make sure those things are being done in a standard way at a micro level because if you have a developer writing microservice, he’ll own it front to back,” said Avanade’s Schmidt. “You want to make sure he’s not deviating from your corporate standards for security, coding style and that stuff. And if he leaves, it’s easier for someone else to pick it up because he’s been using best practices.”

#3: Save time and money
Static code analysis takes time, but it’s time well-spent. The amount of time depends on the number of tools used, the tools themselves and what developers allow into production. However, the time the tools save in the long run is well worth the time invested during development.

“Once people put static analysis in their processes and in their toolboxes they can rid themselves of race conditions, stack overflows and other defects that rear their ugly heads in production,” said Voke’s Lanowitz. “If you don’t prevent those defects in the first place and go into production, you can’t figure it out because you can’t recreate the problem. With automated testing, you’re not going to see every path in the code execute. With static code analysis you can see everything and then determine where those defects are.”

Static code analyzers also help reduce the burden of code reviews.

“When you have a lot of teams, code reviews can be quite a substantial time effort. If you’ve got a team of 40 people and you have to review every single person’s code for style, logic, security, all of these things static code analysis tools check, and you kept layering those on, [it would be overwhelming],” said Avanade’s Schmidt. “The amount of time I have to spend reviewing those aspects of people’s code greatly goes away which allows me to focus on whether we’re building the right logic for our business and customers.” He’s also able to ensure that developers are focusing on quality and telemetry that might have been overlooked.

Meanwhile, static code analysis also helps facilitate more effective DevOps by emphasizing quality processes early in the lifecycle.

“The recommendation is make static code analysis part of your CI process. You want to stop corrupt code from deploying, so you want to stop it as early as possible,” said Gartner’s Herschmann. “If you’re just starting out, figure out how to use it. A common path is to start with Sonarqube, which is open source. Look for differences in how you’re doing at a basic level. Then, add more dedicated tools like Coverity, Parasoft, or other options and go to a level deeper.”

While the continuous process of learning and improvement dovetails nicely with Agile and DevOps mindsets, developers may nevertheless resist changing their processes, especially when it appears the enhanced process will slow the delivery of code.

“If you’re saying you want to release software faster, you should be doing things to make that happen and some of those things require process changes,” said Voke’s Lanowitz. “ While static code analysis is going to take a little bit of time, it’s better than having that catastrophic defect in production that you can’t reproduce and costs you untold amounts of dollars in terms of downtime, customer loyalty and having to implement a crisis management strategy.”

Developers moving quickly in the absence of static code analyzers may find themselves making the same errors time and again that result in the same defects in production.

#4: Improve code security
Security is on everyone’s mind from boards of directors to front-line developers. Since just about everything runs on software these days, it’s important to analyze code for potential vulnerabilities from different perspectives. Hence the need for multiple tools, including static code analyzers.

“It’s not a catch-all for everything. There are limits to it and a lot depends on what kind of tools you’re using and how you’re using them,” said Herschmann. “ Usually we see organizations using several tools [such as] Sonarqube for basic sanity checks and more dedicated tools like Veracode or CheckMarx that do security checks. The bottom line is I want get an additional safety net.”

Avanade uses static code analysis for security purposes. In fact, it’s part of the check-in process.

“We doing this on current projects I’m working on. You check in your code, it scans for any security vulnerabilities, and it checks for credentials stored in code that a developer might have accidently put in there,” said Avanade’s Schmidt. “It’s not a replacement for developers [understanding] security practices or preventing bad code, but it does check for the low-hanging fruit security items. It’s there to make sure you’re passing the sniff test.”

Apparently, Gartner is getting more calls from CIOs or application portfolio managers because they lack insight into the quality issues and risks their applications represent. Static code analysis plays a part there.

“Think about a large organization that has thousands of applications. I’ve had calls where the person says, ‘We don’t really know what’s going on there,” said Hershmann. “What is our risk? How much code do we have? Who is making the changes? Are there significant changes in code quality from Supplier 1 versus Supplier 2?”

In those cases, the data generated by static code analyzers comes into play. That data is merged with data from HR and other sources to provide insights into who wrote the code, where else it might have come from, how code quality is changing over time, and other details portfolio managers want to understand.

“Static code analysis is one key element. The intent isn’t just to say here’s an error and here’s the resolution we recommend. The view is more we are at a rating X for this particular type of application and we’re rating it Y. Why is there a difference? It could be different suppliers or applications,” said Herschman. “The tools contribute to the overall dataset.”

#5: Shift more quality left
Shift left does not make testing and less important than it has been; however, it does enable higher quality to be built in earlier in the SDLC which saves time later. Risk, user expectations, competitiveness, and operational soundness are all being viewed through the lens of software quality, particularly as businesses undergo digital transformations.

“Static code analysis is another piece I can throw in that will help me be more proactive from a quality perspective and more efficient from a testing perspective,” said Gartner’s Herschmann.

Gartner is also receiving inquiries about non-functional requirements and non-functional testing. Specifically, its clients say they don’t want to wait weeks to get the results of a dedicated performance test, they want to get performance feedback during the CI process. While static code analysis is not a substitute for performance testing, some of the more sophisticated static code analysis tools can help developers understand where they’re introducing code that could impact performance.

Avanade’s Schmidt said he has noticed developers adding static code analysis to their build processes, because if it’s included as part of code check-in, developers don’t have to think about it as much.

“I’ve seen [static code analysis] evolve from somewhat useful to where we are today which is giving me a lot of good recommendations of how to make code better,” said Schimdt. “As developers are pushing code directly into production, static code analysis is another tool to validate the quality. If you’re trying to release on a more frequent basis, you need to be able to trust that the code you’re deploying is of higher quality.”

The point of the shift left trend is to ensure that fewer errors make their way downstream. Static code analysis is one of many tools developers can use to ensure they’re providing code that contains fewer bugs.

“Static code analysis is perfect for the shift left trend in terms of making sure you’re going to have the proper type of application to put in production, the type of source code a traditional QA person would want to test and would be able to test, said Voke’s Lanowitz. “You want to make sure the developers are doing what they can up front so when the QA team tries to do some functional or performance testing later on, the code will be in good enough shape that other tests can be run.”

The future is faster and more efficient
Some people have avoided static code analysis tools because the older versions were comparatively cumbersome. Today’s developers don’t have time to waste, and thankfully, the tools have improved greatly. They’ll continue to get faster and more efficient, and there will probably be better in-IDE experiences across the board. At the present time, developer experiences vary across IDEs.

“It’s good that [static code analysis] is coming back into vogue because people aren’t using it and they should use it,” said Voke’s Lanowitz. “The tools have gotten very good. Ten years ago, people would say the tools give you a lot of false positives.”

Meanwhile, there’s many more types of static code analysis tools that have been built to ensure that new languages and new architectures such as microservices are supported. In fact, there are so many static code analysis tools available today that reviewing even one of the lists can be a daunting experience. Right now, the tools identify errors. Perhaps in the future, more of them will tell developers how to address those errors.

“I might get a report that has thousands of warnings about errors, but it doesn’t give me a starting point that says if you fix these five things, 80% of your issues will be gone, “said Herschmann. “Not all of the tools have that [kind of] intelligence. This is where I think the expertise of specialists is still needed.” Avanade’s Schmidt would like to see static code analysis tools become part of the compile time in the IDE so developers don’t have to think about even running it.

“If you get a compile error that says you did something bad, your code analysis should be the same thing. Compile, run code analysis you know you did something bad or not and go fix it as part of that development or roundtrip process,” said Schmidt. “I don’t want to spend 25 minutes running all the static code analysis tools. The tools have to get faster and there’s some movement toward that, especially with people moving it into their build processes and check-in processes.”

Given the sheer proliferation of static code analysis tools, there will likely be consolidation among at least some of them, which would simplify choices for developers.

“Right now, we have roughly six different tools we run as part of our coding process. You have to remember that you ran all six which is why it’s important to be part of that build process,” said Schmidt. “I assume they’re going to consolidate these tools so you have a to-go, best-of-breed tool, like a security tool, and that’s a little bit different than a coding standards tool.”

Even if there is a consolidation, developers will still need to use the right tools for the right jobs. Right now, some developers think they have enough other tools so they don’t need static code analyzer. Conversely, it’s also possible to place too much faith in a single tool.

“You should implement a comprehensive quality strategy that in addition to static code analysis includes BDD, pair programming, automated testing and dynamic code analysis,” said Herchmann. “All of this should be part of this comprehensive quality strategy.”