What Can Be Done about Software Reliability?


When an error is found in an application during development, the automated error prevention method helps you correlate that error to a specific point in the development process, and allows you to modify your processes to remove it, and more important, to prevent it from happening again. Preventing errors, rather than chasing them, dramatically improves software reliability. This way, you can stay competitive and not risk your valuable reputation on unforeseen bugs.

Ask any developer in your organization what he or she is doing at any point during the workday and most likely you'll hear the answer "debugging code"; that is, trying to make a piece of code work the way it was originally intended. Software is the only industry I know of where so much time is spent trying to figure out why something is broken and how it can be fixed. Other industries make their products right the first time; why can't the software industry do the same?

Software is a relatively new industry, less than fifty years old, and it has spent much of that time trying to figure out how to create reliable software applications with minimum errors. While much wonderful work has been done in a relatively short time, software remains the weakest link in our advanced technological society. The much touted "Software Reliability" campaigns recently espoused by industry leaders is a misnomer—no one is really trying to do anything about making software completely reliable because there is a widespread belief within the computing industry that nothing can be done. Despite recent studies that indicate that software errors cost U.S. businesses $60 billion a year, bad software is still accepted and used, largely without question, by both businesses and consumers alike.

There are many industry experts and leaders that claim to hold the answer to better software. These theories can generally be divided into two categories: process improvement and development dynamics. Process-improvement measures generally focus on human quality-control methods, that is, how to improve a behavioral process so that a procedure is performed exactly the same way each time it is performed, regardless of who is performing it. Well known process-improvement methods include ISO 9001 and SEI-CMM. While popular and effective for configuring human interactions and behaviors, quality control methods such as these leave much to be desired in the software arena. These approaches are costly to implement, they require enormous amounts of human labor to maintain and verify, and they create vast amounts of documentation to simply certify that a company follows a written procedure for writing software.

When it comes right down to it, the only notable result from development certification is lost time and money. Such processes do not guarantee that your products are error free, only that the human elements involved in the software development lifecycle are regulated in the hopes of reducing inefficiency. Your employees follow a process, but so what? Has that process really improved your software applications?

Development dynamics focus on improving development group behavior. Waterfall and iterative development were early and popular attempts to bring order to the actual process of software development. Much software created today is still developed in one of these two methods. More recent examples of development dynamics include eXtreme and Agile Programming. When using these methods, development groups "speed" up software production by shortening the development lifecycle. This is done through many numerous small application iterations that focus only on well-defined customer specifications. Approaches, such as these latter examples, address how development groups operate better when working in focused, small groups where coworker oversight and testing are integrated into the production process.

While they do keep developers focused on customer requirements and working efficiently in shortened time-to-market windows, such programming generally addresses only programmer behavior. They tend to focus on the question "Under what conditions do programmers work efficiently and quickly?" Unfortunately, error detection is still a large factor in such models. Testing is conducted to look for bugs in order to fix them, but nothing is done to alter the process that allowed those bugs to be created in the first place.

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.