Developer Product Briefs

Applying Automated Error Prevention

Software is integral to many mission-critical environments where code errors can be devastating. Take a look at an error-prevention solution that's seen success in other industries.

• By Adam Kolawa
• 11/17/2006

Applying Automated Error Prevention
The time is ripe for the software industry to apply the AEP concept that other industries have used for increased productivity and cost reduction.
by Adam Kolawa

November 17, 2006

In today's world, where IT has become an essential part of the enterprise and software controls everything from automobiles to airplanes to pacemakers, software defects are no longer just an annoyance. Organizations that release or deploy software with functionality or security flaws now risk spoiled reputations, reduced market share, and costly lawsuits. Outages in critical business systems could cost companies millions of dollars per hour, and even one glitch in software embedded in medical or military/aerospace systems could cost lives.

Frighteningly, there are now more opportunities than ever for development teams to make mistakes that introduce these devastating defects into the software. Today's enterprise systems are typically extremely complex, multitier systems—often a precarious combination of new technologies and old, such as legacy systems wrapped as Web applications or services, and then integrated with newer systems through a service-oriented architecture (SOA). At each layer there are different opportunities for something to go wrong, and a simple mistake in one component can ripple throughout the system, causing far-reaching, difficult-to-diagnose problems.

Moreover, the development process itself has also grown more complicated, opening even more opportunities for the introduction of defects. For example, communication barriers introduced by offshore outsourcing and distributed development make it more difficult than ever to ensure that the software meets the customer's expectations. The increasing complexity of enterprise systems has resulted in hot wired build processes that may work in one context, but which cannot be modified, extended, or moved to environments without a significant chance of introducing problems—or breaking the build altogether.

Modifying the development process to reduce opportunities for mistakes—for instance, by setting downstream traps to prevent the root cause of problems whose symptoms manifest themselves upstream—would dramatically reduce the amount of late-cycle debugging that is responsible for most project setbacks. However, most development teams try to achieve quality by attempting to identify and remove all of the application's defects at the end of the development process.

The Complexity Obstacle
This bug-finding approach is not only resource intensive, but it is also largely ineffective. To have any chance of exposing all of the defects that may be nested throughout the application, the team would need to identify every single path through the application, and then rigorously test each and every one. Moreover, any error found would be difficult, costly, and time consuming to fix, considering that the effort, cost, and time required to fix each bug increases exponentially as the development process progresses.

If error prevention is so much more effective than relying solely on end-of-process testing, why is it practiced so rarely in the software industry? Because it's so difficult is the answer. Just determining how to prevent a single defect can be a complex process: it requires someone who truly understands the code to abstract a general root cause from a specific symptom, figure out how to prevent the root cause, and then determine how to implement a preventive practice in the development process.

Another obstacle is ensuring that the preventive practices are applied during the development process. Teams that are already working in constant crunch mode to deliver the expected functionality on deadline typically lack the resources or desire to learn and perform new best practices—especially those that require time-consuming and/or tedious tasks without offering the instant gratification of finding "real bugs." Moreover, unless managers have visibility into the team's application of the prescribed preventive practices, they are likely to overlook opportunities to prevent minor, emerging issues from growing into major setbacks.

Using automated error prevention (AEP), modern development teams can overcome these obstacles and implement a practical, sustainable approach to defect prevention. The concept of AEP advocates the fullest possible automation of this process:

1. Detect an error.
2. Isolate the cause of the error.
3. Locate the point in the process that created the error.
4. Implement practices to prevent the error from reoccurring.
5. Monitor for improvements.

This process is based on principles developed by W. Edwards Deming, a businessman who revolutionized the manufacturing industry in the 1930s. Deming found that the key to reducing cost and improving quality in heavy industry production lines was to stop chasing defects one by one, and instead prevent defects by improving the production line process that permitted each defect to be introduced. Deming's teachings are well known, and are reflected in many initiatives in the software industry, such as ISO, CMM, and CMMI.

The introduction of automation is essential to making error prevention a sustainable strategy for the software industry. When key error prevention practices are automated, organizations can ensure that these practices are enforced thoroughly and precisely, with minimal disruption to existing processes and projects.

When implemented across an entire team, AEP can significantly improve software quality, improve team productivity, and reduce time to market/deployment. AEP can be applied to any type of process or project, and it satisfies many different needs, including the need to improve productivity, the need to gain ISO certification, the need to boost CMM levels, the need to ensure the quality of outsourced code, and so on.

An AEP Example
Let's look at an example of the AEP concept in action. Suppose you are developing an n-tier system, which includes a client, middleware written in Java, and a database. Assume that load testing revealed that the system stops working under a heavy load. After detailed analysis, you discover a resource leak from open connections to the database. Normally, you would simply modify the code to close the connection. However, if you were to approach this situation from the perspective of AEP, you would also try to determine how to prevent the error from recurring.

After isolating the problem as an open connection, you would determine that the error was introduced into the process because a developer wrote code to open, but not close, a connection. You might then try to stop this error from recurring by implementing a practice that ensures that code written to open a connection is always accompanied by code to close that connection.

One way to implement this practice is to establish a Java coding standard requiring that each class that opens a connection must have a finalize() method and use the finally block to close the connection. If code follows this rule, the error won't reoccur, but how will you enforce this rule? You could try to enforce the practice by having the team conduct code reviews. However, this approach is inefficient because the team would need to manually review and analyze all of the code to determine whether all of the connections were closed.

A more efficient strategy is to integrate into your process a product that automatically checks coding standards, and then have that product analyze your code and automatically identify violations of this coding standard. This approach is the idea behind the AEP concept. You found an error during load testing, and then you isolated the error's source as a resource leak from an open connection in the Java middleware. You found that the Java code was missing a finally block and finalize() method, defined a coding standard to specify how code should be written in the future, and automated the process to ensure that this standard is followed in practice. In this way, an entire class of performance problems can be prevented.

AEP is a very effective way to reduce errors, increase productivity, and improve product quality. Other industries have used this same concept to achieve substantial productivity gains and reduce production costs. For the software industry, the same results are possible. What are we waiting for?

About the Author
Adam Kolawa, Ph.D., is the cofounder and CEO of Parasoft Corporation, a leading provider of automated error prevention (AEP) software solutions. Adam's years of experience with various software development processes has resulted in his unique insight into the high-tech industry and the uncanny ability to successfully identify technology trends. He has orchestrated the development of several successful commercial software products to meet growing industry needs to improve software quality. Adam is coauthor of Bulletproofing Web Applications (Hungry Minds 2001), has contributed to and written over 100 commentary pieces and technical articles for industry publications, and has authored numerous scientific papers on physics and parallel processing. Adam holds a Ph.D. in theoretical physics from the California Institute of Technology and has been granted ten patents for his recent inventions. In 2001 Adam was awarded the Los Angeles Ernst & Young's Entrepreneur of the Year Award in the software category.