August 6, 2003
(Computerworld)
The software industry's constant moaning about poor quality is tiresome. I've heard almost every excuse there is for bad software: offshore outsourcing, feature-creep, skyrocketing complexity. The prevalent excuse is that bad software is a fact of life, like the tides and the phases of the moon.
How wrong this view is! Bad software is not something we have to live with. We must stop focusing on poor product quality and start fixing bad manufacturing processes. That's right, I said the "M" word: manufacturing. Software is no different from other manufactured products. Cars, toasters, coffeepots and computers all come off assembly lines. If at the end of the line a defect is found, it serves no purpose to fix that defect item by item. The assembly line itself must be examined and fixed. Software is no different. Software defects must also be prevented, not simply detected.
We've had plenty of time to learn how to deal with defects from the automotive industry. It was the Japanese who first learned the lesson of the error-free assembly line. The Germans and the Swedes quickly followed suit. Later, the Americans began producing better quality cars and trucks. What did the automotive industry discover? The process of error prevention.
Defining Error Prevention
Let's examine what this means. Five specific procedures can be followed to prevent manufacturing errors:
 |
  |
|
Dr. Adam Kolawa co-founded Parasoft Corp., a privately held company with more than 10,000 clients worldwide. Co-author of Bulletproofing Web Applications (Hungry Minds, 2001), he has contributed to and written commentary pieces and technical articles for various leading publications. |
Error prevention is very different from error detection. Error detection is the process of finding and fixing errors after an application is built; the flawed process that generated those errors is left uncorrected. In the seat example, error detection would have simply tightened the seat bolts at the end of the assembly line. This action may have ensured that the bolts were installed properly, but it would have left the root of the problem embedded in the manufacturing process. The problem would never go away because the root cause wasn't corrected.
Error detection is how the software industry currently deals with bugs, by treating the symptom (bugs) and not the disease (the development process). Given that detection doesn't cure the root cause of errors, we must ask—with indignation—Why isn't our industry taking advantage of error prevention? Why isn't it behaving like other industries when it comes to preventing errors? These are vital questions, since software is in almost everything we touch and use.
Whenever I ask such questions, someone points out that quality improvement initiatives within the software industry directly address error prevention; ISO 9001, SEI-CMM and Six Sigma are the best-known examples of such initiatives. Although valuable, such measures don't directly address error prevention; they attempt only to regulate processes with the intention of preventing errors. Without automation, quality initiatives fall short of their goal because they can't implement practices that actually enforce and support their written procedures.
Automating Error Prevention
For the software industry, the only true way to make high-quality applications is through the concept of automated error prevention (AEP). This concept consists of the same five steps listed above for error prevention, plus automation. Wedding error prevention and automation is a difficult task, and many have failed in the attempt.
So how can it be done? First, define and implement proven techniques that help stop errors during application development. Practices such as coding standards, unit tests, integration tests, load testing, connectivity verification, monitoring and others can be placed in the software development life cycle and automated. As illustrated in the life-cycle graphic below, this provides an AEP "seal" around the four core phases of software development. AEP is full life-cycle error prevention.
Figure 1: The Software Development Life Cycle
Errors found anywhere in the development process can be correlated with a procedure that came before it; all that's needed is to modify the upstream procedure and prevent the error from recurring. This is shown in the life-cycle graphic by the feedback loop (indicated by the dashed arrow). In this way, information gained from individual practices can be used to intelligently improve the process and prevent future errors.
When such procedures are automated, they can remain in place indefinitely, returning benefits daily to the software development life cycle. The AEP concept fits into any development process, including traditional waterfall and iterative methods as well as recent trends such as extreme programming. More important, AEP is exactly what quality improvement initiatives such as ISO 9001, SEI-CMM and Six Sigma are trying to implement. AEP should be integrated into any quality initiative—it's the only proven method for enforcing quality improvement measures that relies upon written procedures.
Implementing AEP
After identifying the error prevention techniques that need automating, the next step is to address key issues that allow these practices to be successfully implemented. One important issue is group behavior. Experience has taught us that these practices must be embedded in the software development groups that will use them. This means that everyone in the development group must understand his role—be it developer, architect or project manager—and how to adhere to that role given the practices in place. For example, understanding who creates coding standards, where these standards are stored, who uses them and when they're used is necessary for the group to successfully adopt automated coding standards. Most important, defining group behavior ensures that the practices adopted remain ingrained and don't deteriorate over time.
Another key issue in AEP is the ability to improve the process. This is accomplished through feedback loops, like the one shown above. Let me give you an example of how this works. Let's say you're developing an N-tier system. To establish what types of traffic that system can manage, you need to perform load testing. Unfortunately, you discover that loads overwhelm the system. The reason for this is that the middleware is leaking connections to the database.
Normally, you would simply fix this bug, but that won't prevent similar errors from occurring. In AEP, you want to also correct the root cause of this error to prevent further leaks. The root cause is that when a connection is opened, it isn't closed. So how can you prevent this? Assuming that the failing middleware is written in Java, you need a way to ensure that each class opening a method has a finalize() method that closes the connection or the finally block. Coding standards are a great way to achieve this—simply create a rule that checks for this pairing, to ensure that each method opened is also closed. By creating this rule, you have moved upstream from the load-testing error and established a coding rule that mandates that no connections should be left open. This loop is illustrated in the life-cycle graphic by the dashed arrow.
The next step is to implement this change automatically. A coding standards scanning tool could be used to ensure that this rule is enforced across the development group. This is true AEP implementation. Not only do you change the practice to ensure that errors aren't repeated, but you also automate the procedure and use its results to measure how well that change is being followed across the development group. This makes it possible to determine if your change is effective, or if further changes need implementing somewhere else in the process.
The process described here is rather elaborate and difficult to perform. It requires experience and patience to implement correctly. As you gain experience in AEP, you'll find that implementing preventative methods becomes easier to accomplish. Fortunately, there are prepackaged coding standards that can help you reduce the initial work required to implement AEP. These prepackaged rules are the most effective and easy way to begin using AEP practices. Rather than traverse the feedback loop for each error found, it's more effective to simply adopt a set of prepackaged coding standards and drop them onto your code. This allows you to leverage the hard work of industry experts who spent countless hours analyzing a lot of code to come up with rules that prevent a host of error types, without having to discover them for yourself during testing.
A Final Word
The software industry must mature. There can be no maturation without effective error prevention and improvement of processes. We have no other options—we must do it. If we don't, our industry will pay dearly for it, much as the U.S. automotive industry did in the 1960s and '70s, when it lost nearly half of its market to foreign competitors that knew how to prevent errors and make better quality products.