Software Development Shift

 
 
By Peter Coffee  |  Posted 2007-02-05 Email Print this article Print
 
 
 
 
 
 
 

Opinion: Evolution requires a fundamental cultural change.

Its ironic that software developers create the most complex artifacts of enterprise infrastructure while having the benefit of so little infrastructure themselves. Changing that paradigm—to make the construction of a development infrastructure the norm when establishing an application development center—is more than a matter of acquiring and installing automated project management and testing tools. Its also a cultural process, without which even the most elaborate development tools are at best mere decoration, at worst a cumbersome distraction.

It might seem absurd to say that the process of writing software has not fundamentally changed in a quarter century or more. Beginning with the arrival of Borlands Turbo Pascal in 1983, or even with the appearance of Smalltalk environments in the early 1980s or LISP machines in the 1970s, programmers have enjoyed a progressive tightening of the loop of tasks thats often summarized as "edit, compile, debug."

A process that once involved punching cards, running jobs and leafing through bulky diagnostic printouts has become for most developers a far more rapid and integrated process that takes place in a single electronic environment. Are these integrated environments not a major step toward a powerful "developer infrastructure"?

Id argue that integrated environments, on their own, are to software development what automobiles are to the tangled and congested streets of Boston. Yes, the level of comfort has gone up—and when things are going smoothly, they go much more quickly than before—but "complex systems usually operate in failure mode," as noted by John Gall in his seminal 1978 satire "Systemantics." A software development team of more than trivial size is certainly a complex system, and when developers encounter confusion or error, their modern environments may be as powerless to solve the problem as a Formula 1 racing car would be to get through a downtown traffic jam any more quickly than an able-bodied pedestrian.

The continued use of the term "debug" is evidence that the fundamental process has not evolved—at a time when its becoming overwhelmingly clear that the challenges faced by developers are evolving at growing speed. Software is not a natural material, found in the wild and inherently requiring purification or concentration to make it useful. Every so-called "bug" was produced by exactly the same process as the rest of the code that makes up an application, meaning that every act of debugging represents doing work—then doing more work to undo it.

Never an attractive proposition, the model of debugging becomes entirely unworkable when software increasingly can go live to its users as quickly as it can be written—and when an application may be a composite of both local code and third-party remote services. Were not talking about hacking a statue out of a block of marble and walking around it again and again to make it right by repeated refinement. Were talking about a process that should produce nothing that isnt correct, so that all new code adds function rather than offering its users a dangerous mix of improved function offset by lessened reliability.

Advocates of fundamental process change are attacking the cultural implications of debugging with labels such as "Automated Software Defect Prevention"—the foundation of the forthcoming textbook "Automated Defect Prevention: Best Practices in Software Management," by Dorota M. Huizinga and Adam Kolawa, due for publication in August by John Wiley & Sons. The authors offer a platform of six principles, which Ill abbreviate as establishing infrastructure; applying best practices; customizing those practices to the project; measuring and tracking project status; automating repetitive tasks; and making incremental implementation of these techniques.

Without automation, this approach is technically impractical; without an incremental approach, this approach is culturally impractical.

Kolawa backs up his doctrine with deliverables in his role as co-founder and CEO of Parasoft, of Monrovia, Calif. That companys Jan. 29 release of SOAtest 5.0 makes major improvements to a product that eWEEK Labs found to be "a useful contribution … to process transparency and certification" in a review of Version 4.5 last May.

Walking through the 5.0 release in a session with Parasoft engineers last month, a week before its release, the Labs found especially interesting its new aids to defining and reproducibly testing quality of service as well as functional correctness measures. But Kolawa and Huizinga between them can only point the way to the door, with Kolawa further easing entry with his companys tools and its demonstrated success in using them. Walking through that door is a management choice, and developers are ill-served if their managers fail to do so.

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