eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.