The Perils of Turning Pro

 
 
By Peter Coffee  |  Posted 2006-02-21 Email Print this article Print
 
 
 
 
 
 
 

Opinion: If practice makes perfect, does imperfect make malpractice?

When I got the invitation to keynote this months Software Security Summit in San Diego, I proposed "Mediocrity Is Malpractice" as a title for my remarks. I was thinking of this as a general statement about rising expectations. As it got to be time to prepare the talk, however, I realized that I should take it as literally true and explore the implications of developers being viewed as (mal)practitioners.

Its not original to talk about developers possibly being regulated by the professional engineer certification system thats administered by various state agencies.
Im not certain that such developer certification is a good idea; Im definitely not expecting it any time soon. With or without such formalities, though, I suggest that developers meet key tests of being a "professional": specialized skills that many people cant realistically hope to acquire, a specialized vocabulary thats not accessible to the untrained and the kind of work that can be competently judged only by a professional peer.

You dont need to speak of malpractice in a field such as plumbing, because a layman knows a leaky pipe when he sees one—but it takes a top-flight coder to go through a nontrivial program and quickly spot the kind of flaw thats potentially dangerous.
Its therefore necessary for developers to be a self-scrutinizing community—one that can say with credibility not only when something wrong has been done but also when due care has not been taken.

Acts of omission matter. Malpractice is not limited only to fraud, deceit or other acts of commission, but it also includes culpable failure to know or to do. The classic example is a lawyer who fails to file suit before a statute of limitations deadline has expired: The client cant be expected to bird-dog his attorney on such matters. Crucially, theres also ample precedent for the idea that failure to know and comply with applicable laws and regulations is, by definition, a negligent act of omission. Faced with a growing number of laws and regulations affecting software development and use, software practitioners must therefore work that much harder to avoid such errors.

When law meets up with technology, one of the most important sparks that fly from that collision is the idea of strict liability. Say you rent a car from a discount used-car outlet and one of the cars tires is conspicuously flat when you pick up the vehicle. You drive it anyway and have a blowout that leads to an accident. The rental agency can then claim your knowing assumption of risk, plus contributory negligence, and thereby reduce its exposure.

In contrast, if I rent you a rocket ship, and it crashes on a city, I cant reasonably claim that you should have magnafluxed the turbine rotors before you took off—or even that you should have known better than to fly it over an inhabited area. Rockets are a relatively obscure and inherently dangerous technology, and the system works best if those who introduce that technology into the community are held strictly liable for the consequences.

Software is still a lot closer to rocket science than it is to Rent-A-Wreck—and the model of software as a service involves more software developers becoming providers to clients who dont know and cant be presumed to understand the inherent risks of what theyre getting into. For example, while planning my drive to the Software Security Summit, I looked up the destination on Google Maps and found a diagonal band of blank squares across the middle of the map. Two days later, those blanks had been filled in—but imagine some automated system that relied on that service, suddenly finding itself in terra incognita. Its a good reason to call something "beta," dont you think?

For advice on how to secure your network and applications, as well as the latest security news, visit Ziff Davis Internets Security IT Hub. And when you think of yourself as a possible target of a lawsuit for malpractice, you dont leave comments in source code that say things such as "Dont even look at the mess below"—an actual example from a gallery of comments that Ive seen and the kind of thing that you wouldnt want a plaintiffs attorney to find.

Professionalism doesnt mean just doing your best; it means knowing and being prepared for how good others expect you to be.

Peter Coffee can be reached at peter_coffee@ziffdavis.com. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.
 
 
 
 
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























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel