I Don't Need Their Functionality. Uh, Whatever It Is.
The question raised by the common "I don't need it" argument, however, is, "How do you know?"
One thing I learned from my developer conversations is that vendors don't always make it obvious how the software improves the development process. And developers have their own way of doing things or are confident that their code is adequate (whether or not the attitude is justified), so they see no driving reason to change.
The more experienced you are, the less you need these tools, in the opinion of many. For Mark Hunter, founder of FlipScript.com, the tool cost-to-value ratio is way too small, especially when factoring in the cost in his time. "For instance, why use data modeling tools when an experienced developer like myself can knock out the entire SQL script to create the database in a couple of hours, and later modify it in seconds?"
"Half of the developers in the world are below average, and you and I are depending on their code as well as on software written by the smartest programmers."
Richard Kirkcaldy is a developer at Computer Gentle, serving small businesses and non-profits. Even with larger scale deployments, he'd rather rely on his own knowledge than theoretical measurements. "It's much more helpful to know from experience that a certain database type will handle a certain number of users," he says. "If you don't know how many users a system will handle, you can ask people who have used similar setups." In other words: I can do this job better than the software.
Developer David Stevenson certainly agrees with that premise. "I just completed an XML over HTTP application, and I built my own performance measurement/load test tools from scratch," he says. "I would have to see a tool that wouldn't take an inordinate amount of time to learn, and that could do an equal job to the custom tool that I built."
Maybe Hunter, Kirkcaldy, and Stevenson are justified in their viewpoint (I assume they are), and maybe it's true for you (because as my reader you have demonstrated good taste and brilliance). But statistically, half of the developers in the world are below average, and you and I are depending on their code as well as on software written by the smartest programmers. Remember that guy on your team three years ago who was a legend in his own mind? Do you think his apps could stand to be scrutinized by a fine-tune finishing tool? Do you think he'd have admitted it?
As Larry Warnock, CEO of IT vendor Phurnace Software explains, "Most of the [sales] objections we hear are actually rooted in pride. And it's completely understandable. Developers have spent hundreds of hours creating their baby: home-grown deployment scripts. But ultimately it's tough to argue with the power of automation tools."
It's one thing to reject developer tools because they don't bring enough value to justify the time and money to acquire and install them. However, developers are not always aware of what the tools can do, at least according to vendors. Rob Cheyne, CEO of Safelight Security Advisors, says it depends on the team's skill set. A team with a performance engineering expert may already have a suite of stress test tools. But, he cautions, other teams may not know what's possible. Cheyne says, "Some of the really good security tools have only been available for a few years, and new tools come out all the time."
Vendor Mandeep Khera, CMO for security-tools company Cenzic, believes that too many developers don't recognize that they might have a Web security problem; after all, they haven't been hacked. "They think having SSL is enough. Usually it takes a lot of education and showing them actual hacks to convince them," Khera says.
The Tools Don't Deliver on Their Promises
The vendors, naturally, believe that their tools improve the software development process. (You expected otherwise?) But for some developers, it's not a matter of willingness to adopt a tool; the problem is that the tools don't deliver what they promise.
A decade ago, one developer (I'll call him Dennis) was part of an evaluation team asked to recommend one web stress testing package from the Management-deemed three finalists (all costing over $100,000). None really tested load, he says. They were far too underpowered, and what seemed like exact, discrete, measurable performance specs were mushy. "We held our nose and endorsed the best of the three," Dennis says. "The company bought one of the two losers instead, based on a sales to executive end-run."
Frank Koehl, founder and lead developer at Fwd:Vault, just doesn't believe that security testing tools, for instance, are worth the effort. "I code to eliminate the security holes, but a test is supposed to uncover ones I may have missed," Koehl says. "Because these attacks are so specific, and the tools can only be built for general purpose use, they are often useless. The ones that can get situation-specific are typically far more trouble than they're worth, because they still don't get you inside an attacker's head."
But not every developer rejects the tools. Many would be happy to use them – if only they could.