email article printer friendly more resources

Maintain a Healthy-Software Lifestyle
Poor software quality can cause your programs to come to an untimely end. Don't fear the reaper. Learn how to survive
by Klaus-P. Berg

July 20, 2004

Everybody has to go sometime. That is true in life, and, unfortunately, is also true with much of our software. Looking at our software programs today—it doesn't matter what company we work for—many of them are just one bug away from a date with the Grim Reaper. So, how can we keep our programs alive? A good place to start is using software quality assurance (SQA). But don't think we can be sure of a perennial victory. It's an everlasting battle.

The Good, the Bad, and the Ugly
The "art of war" requires us to know as much as we can about the enemy. In our case, the enemy is poor software quality. Therefore, let's start our preparations by looking at some quality attributes, followed by an examination of the causes that turn good software bad.

Classic software quality characteristics cover functional and nonfunctional aspects as defined, for example, in ISO standard 9126 (Figure 1). Each of these characteristics is further refined by quality attributes. Quality characteristics and attributes can be related to quality metrics. They allow for quantitative measurements to judge how good or bad our software is. But beware of a metric hype or misplaced trust. Applied inappropriately, or misinterpreted, metrics can lead to fatal errors of judgment about software quality.

Of course, there are many more quality definitions in the academic and industrial realms but they lack consensus and formalism. Therefore, quality is also a subjective term even, or especially, when based on metrics that always must be interpreted by experts. Nevertheless, despite the problem of specifying what quality exactly is, I think we all have an immanent feeling about what is good, bad, or ugly software.

Good software has a good functional and internal design. Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements. Good internal design is indicated by code whose overall structure is clear, understandable, easily modifiable, and maintainable. Products that are based on good design and code are robust and reliable, and work reasonably bug free with sufficient performance. They have error and exception handling, use a status logging capability, and have been thoroughly tested (such as with embedded unit tests based on the well-known JUnit framework).

Having considered some characteristics of good code, design, and architecture, let's illustrate how bad design and architecture can materialize.

Figure 2 shows a complex and very unclear design after visualization with a static code analyzer. I hope you will agree with me that maintenance and change management will be hard in this case. Although software is easy to change compared to hardware, Figure 3 lets you imagine what can sometimes happen if we attempt to make a change. What is worse, we may see only the tip of the iceberg and everything may seem fine. Therefore, we have to dig beneath the surface for problems. Good code, design, and architecture have a lot to do with elegance. Quite often, elegance equates to "simplicity." To quote Albert Einstein: "Things should be as simple as possible, but not any simpler." This quote could easily refer to software architecture, design, and code. It's this minimalistic view that generally yields the best results.