Crashes Deserve a Closer Look

 
 
By Peter Coffee  |  Posted 2004-09-27 Email Print this article Print
 
 
 
 
 
 
 

More than two decades of knowing better should translate to tools and statistics for Web services.

We speak routinely of software crashing, but we dont give those events nearly the level of scrutiny that we give to real-world crashes. An airplane crash triggers a painstaking investigation. When software fails, the user is told to hope that it works the next time. Is this any way to run an airline? This jarring difference in "crash" response has mostly been ignored. I do remember a comment, late in the 1980s, by one advocate of advanced software development environments: He compared C and C++ developers trying to diagnose a software failure to arson investigators roaming through the charred and smoking debris in search of a recognizable fragment of the match. Even at that time, there were superior counterexamples such as the Lisp machine—but relentless price pressures in the workstation market, not to mention the growing capability of PCs, drove developers down a path of false economy toward lower-cost tools that did much lower-quality work.
One gallows humorist at Microsoft actually named a tool CRASH— for Comparative Reliability Analysis of Software and Hardware—and promised developers, among other things, the ability to calculate "a final score other than pass or fail." Frankly, I dont understand that proposition at all: It seems to me that software either meets its specification, including a level of reliability sufficient to the intended task, or it does not.
Whats between "pass" and "fail"? Would you ship a product rated "tolerate"? Perhaps its reasonable, though, to take a different view of mass-market software, with consumers already having some intuitive understanding of the "get what you pay for" difference between, for example, a Toyota and a Lexus. Even so, from what I can see, it appears that the real difference is not that a Lexus is more reliable, but rather that with the Lexus, youve paid in advance for a higher level of hand-holding when something does go wrong. Thanks, but Ill keep driving my apparently crash-proof Sienna, and Ill keep choosing software thats reliable over software that offers extra bells and whistles.

In the realm of software, the move to a service-based architecture offers developers a more granular opportunity to vote for their own preferred trade-off between doing more and failing less. Improved tools are emerging for developers. Late last week, for example, I saw the most recent version of Mindreefs SOAPscope, and found the newly released Version 4 update making important improvements to support developers throughout a Web services life cycle.
In the long run, a UDDI (Universal Description, Discovery and Integration) repository may offer a Web service aggregator several choices of services that meet an applications needs. One has to wonder if repository metadata will soon include statistically based ratings of service availability, accuracy and other metrics of performance history for that particular Web service offering. If Consumer Reports can gather and publish reliability histories for automobiles, will someone build testbed applications that invoke various common Web services from different providers and systematically record their response? Its getting cheaper to gather data, in this as in every other realm. The IEEE, for example, announced last week its first standard for automobile "black box" recorders to give post-crash data to accident investigators, such as that available following aircraft accidents. Web services should enjoy no less. Tell me what you want to know after the crash at peter_coffee@ziffdavis.com. To read more Peter Coffee, subscribe to eWEEK magazine. Check out eWEEK.coms Web Services Center for the latest news, reviews and analysis in Web services.
 
 
 
 
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