Can There Ever Be Too Many QA Tools?

 
 
By Peter Coffee  |  Posted 2002-03-04 Email Print this article Print
 
 
 
 
 
 
 

Peter Coffee: eXcellence Awards highlight the importance of tools that promote quality workmanship.

With the formal presentation of our eWEEK eXcellence Awards taking place in Boston this week, Id like to call your attention to some of the outstanding entries that didnt receive Finalist or Winner honors—but that still deserve your consideration. If I could have expanded the excellence category list along only one dimension, I would have added more categories for different aspects of IT quality assurance. Overall, I like the way that this category wound up with such an eclectic collection of finalists: the category winner, a Hewlett-Packard help desk management system, plus co-finalist products for software testing from Rational and for network performance analysis from WildPackets.
Its good to consider such diverse technologies under the single umbrella goal of making our IT investments deliver as much as they can: Our IT budgets should be framed in terms of why we buy things, not in terms of their low-level functions. We have a budget for buying a car, not one budget for tires and another for headlights and horns.
Even so, I wish I could have had the luxury of three separate categories of user support, infrastructure support and application support so that we could have brought three times as many quality assurance products into the spotlight. Specifically, I would have liked to find a way to honor MKS Inc.s Code Integrity, one of those breakthrough products that might actually motivate a development organization to do something that it doesnt currently do at all—rather than merely buying a different tool to keep doing what its always done, if perhaps incrementally better. The new task that I have in mind is the assessment of quality trends within a development shop, applying the same formal measurement to learning and improvement among developers that we routinely apply to networks and databases. It seems so obvious: We do this in other aspects of our lives all the time. Whether Im coaching my fourth-grade sons basketball team on their free throws or working with my sixth-grade son on a tricky violin passage, I say the same thing: "Do it more than once, and notice what makes it better." We do application development over and over again, but do we systematically notice and reinforce what works better? While deprecating what doesnt? I also would have liked to find a way to honor Sitraka Inc.s JProbe Suite, a set of Java development aids that is one of my personal exemplars of the good things that Javas design integrity makes possible. This point requires elaboration.
When people complain about some of the restrictions in Java, Ive sometimes been at a loss to explain why the language seems to fit my brain better than so many of the others that Ive been paid, at one time or another, to use. Java, after all, is the only language Ive liked enough to recommend by writing a book-length tutorial. But Java originator James Gosling, during a conversation last month, put an important part of the difference in terms that I think you may find persuasive. "The Java Virtual Machine supports a lot of different languages," James observed, when I brought up the multilingual emphasis of Microsofts .Net efforts that Ive discussed in previous weeks. As Ive previously noted myself, the JVM is targeted by compilers for Ada, Rexx and even Visual Basic. "But we dont say that were willing to support all languages," James continued. "That has to do with issues of what you can prove, from a security point of view." For example, James observed that support for some languages "drives you to support unrestricted pointer operations. The security story goes right out the window; the reliability story is trashed as well." (IBMs developerWorks site offers a great deal of additional material on related subjects.) I look forward to sharing the rest of my conversation with James Gosling in the March 18th issue of eWEEK—and to hearing from you in the meantime about what works for you, and what doesnt. E-mail eWEEK Technology Editor Peter Coffee
 
 
 
 
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