Advertisment

Eliminating Software Bugs

author-image
PCQ Bureau
New Update

1962: NASA's sends its Mariner I to Mars, as a part of its first interplanetary mission. The rocket is destroyed within a few minutes of the launch.

Advertisment

Reason: The velocity calculation in the code had “R” (raw velocity) instead of “R-bar” (smooth velocity). Even though the programmer had religiously implemented the spec, he missed putting a hyphen on top of the R used for the velocity calculation. It's termed as the most expensive hyphen in history!

1999: Mars Climate Orbiter reached Mars, but was lost after it entered the atmosphere.

Reason: The Jet Propulsion Laboratory and Lockheed Martin Astronautics were located in different places and used different units. As a result, the ground software used 'metric units' (Newton seconds) instead of 'English units' (pounds-seconds).

Advertisment

The above two are perhaps the most expensive mistakes that have occurred due to errors in software de-bugging. But de-bugging errors aren't limited to high-end space research labs alone. Every year, they cost most software organizations dearly. Although over time, software coding and de-bugging techniques have evolved considerably, mistakes continue to happen and cause havoc. For instance, take the following simple code from an image processing application:

if ((scale !=0.0) || (scale !=1.0))

imageSize /= scale;

Click on the image to enlarge

Advertisment

The SRS for the above says that “if the scale value is not equal to 0.0 or 1.0, then resize the image by that scaling factor.” The mistake here is that the boolean expression here should be Or instead of AND. A simple mistake like this would never cause the code to function. Similarly, there can be thousands of other mistakes that can be found in the source code, covering which is beyond the scope of this article. The point to ponder is what to do about it? With new tools for software development and shorter SDLCs, it's important to do software testing and de-bugging from the beginning itself than later.

Advertisment

Software testing isn't enough

Testing programs that have been created is not sufficient to remove bugs. According to Dijkstra, author of a book on software programming, “program testing can be used to show the presence of defects, but never their absence.” So just because the testing doesn't find any defects doesn't mean that they're not there. Unfortunately, the industry has an over-reliance on software testing, with almost half the development cost going towards it. It's important to understand that there are many difficulties in relying on software testing. For one, it's considerably difficult to test complex software, and the RoI on testing goes down over time. The question therefore is, how do you handle all the software bugs if software testing isn't the answer?

Handling software bugs

Advertisment

For one, don't rely on testing and manual analysis, which is a reactive approach. Instead, use a more proactive approach. A few things you can do are as follows:

Use tool driven automation: Use static analysis tool driven automation to find bugs. It can be used at different stages like requirements, design, coding, etc. There's been considerable progress in static analysis automation.

Advertisment

Finding requirement bugs: For instance, creating a formal specification of requirements can significantly reduce bugs. You can use the “Z” specification language for doing this. Similarly, analysis of semi-formal and diagrammatic approach can also help find bugs early. For instance, doing a static analysis of use-case diagrams can really help.

Finding design bugs: There are various tools for doing a static analysis of design diagrams. An open source tool called ArgoUML has a feature called design critiques for doing this. Likewise, a commercial package called SDMetrics has a design rule checker just for this job.

Finding coding bugs: There are lots of tools for finding coding bugs, right from Java PathFinder, SPIN, PREFast, ESC/Java, Goanna, FindBugs, etc. These tools can be used for things ranging from abstract interpretation, model checking, theorem proving, data flow analysis, type analysis, and program querying.

Advertisment