Opinion: Software testing tools are part of a balanced approach to IT assurance.

I'm now in the process of reviewing Parasoft's Jtest 8.0, released today as the latest update to a Java code testing tool that I've tracked now through several versions. Notable improvements in Version 8 include the addition of new capability to trace code behavior through complex applications, as well as integration of code review processes into the test tool's own environment.

Looking at any code quality tool raises issues that apply to all such tools and to the processes in which those tools are used. I looked at some of these a year ago in connection with development outsourcing. It's increasingly important, as I noted then, for code quality tools to go beyond detecting problems and become actual aids to developer team collaboration and problem solution.

You'll find a discussion of challenges involved in managing decentralized development teams in an interview in next week's eWEEK, in the Developer Solutions special section: If you don't get that as part of your eWEEK every Monday, it will also be available on eWEEK.com. I spoke for that Q&A story with Jack Blount, a seasoned development manager who's worked with dispersed teams in multiple time zones at companies ranging from small startups to IBM.

One of the key issues that Blount identified is that developers are being brought much closer to the firing line of applications' alignment with business needs. When developers express resistance to agile development methods, Blount opined, they may really be reacting to the sense of greater exposure to—and accountability for—the speed and criticality of changes in requirements. Many developers, he suggested, enjoy the sense of productivity that comes from meeting a specification, even if it's traditional for developers to complain about excessive documentation getting in the way of writing code. When developers find themselves closer to the heat of the fire of responding to the need rather than satisfying the specification, he said, it's bound to create some anxiety.

Thinking about development risk creates unavoidable resonance with other risk discussions taking place on the fifth anniversary of the 9/11 attacks on the World Trade Center and the Pentagon. A somewhat irreverent commentary on the 9/11 anniversary tabulates the number of deaths that actually occurred in the United States from various causes during the 11-year period from 1995 through 2005: As best can be determined, 52,000 people died while walking down the street during that period, compared with 3,147 who died from terrorist acts.

My point in bringing up these figures, with apologies to anyone who had a personal connection with the tragedy of 9/11, is that risks need to be kept in perspective. A huge amount of attention and money gets spent on protecting IT systems from ingenious and malicious attacks. If the goal, though, is to earn a good return on IT investment with high availability of strategic applications that solve relevant problems in a way that creates competitive advantage, the seemingly mundane tasks of writing accurate and reasonable requirements and of rapidly converging on code that reliably meets them should perhaps be higher on the enterprise development agenda.

Tell me what sets your development threat level to Red at peter_coffee@ziffdavis.com.

Click here for an archive of Peter Coffee's columns.

This article was originally published on eWEEK.com.

Discuss Keep a Perspective on Code Risks   >>> Be the FIRST to comment on this article!

>>> More Add Ons Articles          >>> More By Peter Coffee