Developer Tools You Don't Use – And Why You Don't Use Them

August 11, 2009, 11:14 AM — Just about every developer uses a debugger, at least occasionally. The reasons are obvious: Code inevitably has defects, and a tool can help find them.

However, other categories of software tools are used far less often. According to several years-worth of data collected by analyst firm Evans Data, a steady 20-30% of software developers stay away from some developer tools categories entirely. For example, a quarter of North American developers never use a load and stress test tool; 22% never use data modeling tools.

[ See also: Fathers of Technology: 10 Unsung Heroes and The end of bloatware: The return of programming's golden age? ]

Sometimes this makes perfect sense, based on the application or where it runs. Intranet apps rarely need a load and stress tool to determine if they can handle a Slashdot load. If you think your application might endure the occasional heavy load, you might consider hosting with a cloud-based server rather than tune for a situation that never arrives. When some developers say, "These tools aren't necessary," they have good reason for that opinion. According to the latest Evans North American Development Survey, performance tools aren't used by 29% of the developers who primarily write departmental in-house software (as compared to those who write apps the whole enterprise uses), and 44% of those departmental developers never use load and stress test tools. In contrast, 90% of independent software vendors (ISVs) use performance tools at least occasionally, and three quarters use load testing tools.

But other categories of developer tools, such as security testing and performance tuning, presumably could benefit everyone. Why don't developers adopt them? To learn the answer, I asked dozens of developers why they don't use data modeling tools, application modeling tools, load and stress test tools, security testing tools, refactoring tools, or performance tools. I also invited a few vendors to chime in, to share the most common sales objections they encounter.

The Tools Are Unnecessary or Irrelevant

A common answer to, "Why don't you…?" is "Because I don't need it."

These tools are out of scope for many projects, points out developer Quentin Neill. Recently, he built an ad-hoc tool to mine a database, merge data into a document infrastructure, and publish it to the web. That application didn't use any of those tools, he says; there was simply no need for them.

Often, tools are perceived as overkill. Developer Leonid Lastovkin explains, "I do not need a bulldozer to build a sand castle. If I am building a big sand castle – then maybe." Developers like Lastovkin must see a tangible, practical need before adopting a toolset. "Performance [tools] can be quite useful, but not until you hit a realistic bottleneck," he says. "It all depends on scalability requirements."

That sentiment is echoed by Charles Wilde, CTO at Aton International, who decides on tool relevance based on project size and type. For instance, an Agile development project with three people might skip data and application modeling tools; a short lifetime project may not justify refactoring or performance tools. "As a project manager, I must make decisions on tools based on cost/benefit. These decisions can vary widely on the specific details," says Wilde.

This assumes that developers know when the out-of-scope application status changes. Explains Brian Vosicky, consultant at Corporate Technology Solutions, most projects start small and do not take into account possible growth; customers want a quick turnaround that meets today's requirements. "But the problem is: Requirements constantly change and expand, which then exacerbates the shortsightedness in design and testing and skews the calculation of the benefit," says Vosicky.

Of about 40 teams supported by Capgemini's Paul Oldfield, a methodologist with 25 years experience, few if any of the Legacy Enhancement teams use application modeling tools, because they already know the application back to front and inside out. Other teams have different reasons. "The better [teams] manage fine with whiteboards and paper; a few individuals 'just wing it' despite evidence that they are less productive overall if they go that way."

Sure. That makes sense. If you believe that any individual developer knows what he's talking about.