It's Not Part of the Development Process
In the eyes of Stevi Deter, a lead software engineer at Mantis Technology Group, a primary barrier to adoption is that these tools aren't part of the ordinary software development lifecycle (SDLC). Says Deter, "Unlike, say, Test Driven Development, there is no 'Security Driven Development' concept that teaches processes to include security concerns as an integral part of the development process. Instead, it seems to be viewed as a later step in the SDLC, one that can be skipped."
Safelight's Cheyne acknowledges that adding a new tool can cause concern about breaking an existing process. "It can be risky to change it until you fully understand the benefits and have the time and resources to work it into the existing process," he says.
"It is hard to quantify what benefits the tools will deliver, but the cost is up-front and highly visible."
The tools also require that the practitioner know what to do with what the tool tells her. For example, explains Alice Kærast, code administrator at Qvox.org, security testing tools aren't very useful unless the developer understands and can deal with the results. "They only ever give obscure vulnerabilities which nobody will exploit and they miss real vulnerabilities that can be exploited," she says. Kærast is comfortable with her (open source) code and believes it's written securely.
Developer and database guy Dave Poole is also dubious about results. "It is hard to quantify what benefits the tools will deliver, but the cost is up-front and highly visible," he says. "I started looking at database stress test tools but was hampered by cost, poor documentation, obscure user interfaces, and ultimately time."
Or, as Denis Sinegubko, founder and developer of Unmask Parasites admits directly, "I don't know how to use them effectively and don't have time to learn."
It's not just a matter of asking software to do a better job than you're doing yourself. If you don't see a need for, say, refactoring, you surely won't buy software to assist with it. Keith Barrows, lead architect at RivWorks, uses refactoring tools personally, but he knows a lot of developers who don't know how to refactor. That makes for messy apps, he says. Similarly, few of Oldfield's teams use refactoring tools. "Many seem just to let the code ossify despite attempts to introduce them to better ways of thinking," he says.
They Might Be Useful, But They're Too Expensive
Another perception is that the tools cost too much for the developer's budget, or (going back to tool quality) they don't offer enough bang for the buck.
Stevi Deter summarized this attitude succinctly: "[Security testing tools] are expensive, so even as a developer focused on continually improving my skills, I find it hard to learn about them on my own. Contract prices don't include these tools, so it's hard to justify the outlay to my employer."
Because specialist tools cost a lot of money, says database guy Dave Poole, few small companies have the budget or time to invest in them. "I had to deliver an e-commerce site written in PHP with Notepad.exe!" he exclaims. "Once you step into the big league, decent tools start to give the ROI but they do require an outlay both in financial terms and in staff training terms."
The "high prices" may be a matter of perception more than actuality, even though the economy has reduced IT budgets. Cenzic's Khera says his company can overcome many myths by showing them how to use a SaaS solution at a very low price.
It's Hard to Convince Management They're Necessary
In some cases, the barrier is not developer reluctance, but finding employers who'll cough up the money to pay for software quality improvement tools. That can be a Catch 22, since a developer may not know what the software can do until she uses it herself, making it hard to ask for the budget allocation.
David Stevenson's company uses only free tools, other than the Microsoft development suite. Buying tools requires the costs to be justified, he says. "Unless you are familiar with the tool (and have a free version to train yourself on) you will not know what benefits and cost justifications the tool will provide, so that you can (attempt to) justify spending on a tool."
For some, tool adoption reflects overall corporate attitudes and, alas, company politics. According to Geoffrey Feldman, a consultant with 30 years of experience, companies exist on a continuum with "Document and analyze everything before writing any code" at one end and "Get 'er done" on the other – and the "Get 'er done" school doesn't use tools unless contractually required. "At the extreme end, if their customer pays for it, it's done," Feldman says. These companies also have "people lovers:" managers who gain importance based on the number of people under their command. "Many of these tools are labor saving devices," Feldman points out, "And thus they eat into the justification for [managing] lots of people."
So, why aren't you using these tools? The bottom line is that they are perceived (rightly or wrongly) as expensive, unnecessary, mystifying or inaccessible, and hard to learn. That's quite a challenge for those of us who care desperately about code quality, and for those who want to create tools to improve it.
All may not be lost, though. For some tool categories, adoption may just be a matter of time.
Safelight's Cheyne points to debuggers as a good example. For a period of time after modern debuggers first became available, developers continued to debug code manually, such as adding break points and printing to the screen. "Not everybody was immediately aware that debuggers existed, they were comfortable with the way they had been doing things, and the debugger wasn't always bundled in with the compiler and used to cost extra money," Cheyne remembers. But adoption followed quickly after developers got a taste of the new tools. "Today, no enterprise developer would dream of debugging the old-fashioned way," Cheyne adds. "It's extremely inefficient and costs far more in developer hours than the cost of the tools. The tools that truly improve ROI will always be adopted in the long run."
Follow ITworld on Twitter: @IT_world