Keep a Perspective on Code Risks

 
 
By Peter Coffee  |  Posted 2006-09-11 Email Print this article Print
 
 
 
 
 
 
 

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

Im now in the process of reviewing Parasofts Jtest 8.0, released today as the latest update to a Java code testing tool that Ive 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 tools 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. Its 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.

Youll find a discussion of challenges involved in managing decentralized development teams in an interview in next weeks eWEEK, in the Developer Solutions special section: If you dont 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 whos 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 its 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, its 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.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel