Steve Wozniak, the co-founder of Apple has been quoted as saying in relation to the Toyota Prius "I can repeat it over and over again - safely. This is software. It is not a bad accelerator pedal."

The average motor car today contains approximately ten million lines of software code At the end of this decade the average is expected to be three hundred million lines. Given that your new car will soon - if it does not already - have its front wheels steered by electronic components (steer-by-wire) it would be reassuring to know that there are no errors in the software. But if there was such a car without software errors, you probably couldn't afford it.

Some of the highest integrity software code has been written by NASA and a company by the name of Altran Praxis. Everyone knows who NASA is. Altran Praxis is known for using formal computing tools for the development of safety critical software, such as that used in nuclear plants and launch systems for military missiles. Neither claims its software to be error free. NASA's software is estimated to average ten errors for every thousand lines of code. Altran Praxis simply refers to its software as "ultra low defect". General commercial software is estimated to average fifty errors per one thousand lines.

Ultra low error code requires developers with far above average skills. Even then it is an exercise in diminishing returns; also, every fix risks creating new errors. The development cycle time increases exponentially in line with the degree of integrity required. At a point cost becomes overwhelming.

A commercial software developer cannot normally sustain the cost of building ultra low error software. Time to market is also critical; at some point the need for the product will be overtaken by a competitor, a change in technology or a shift in business requirements. Un-affordability and irrelevance loom large. So a decision must be made as to which errors are acceptable. It is better to ship a product with known errors and a known quality level than to ship uncertain quality with unknown errors. It is better to ship a product with relatively innocuous known errors than to risk introducing worse errors through fixes.

Yet customers (and their lawyers) often insist on contract terms referring to "no material errors", "no known errors", "all errors fixed" and sometimes even "error free". Not only is it unrealistic but the "one size fits all errors" approach is potentially a disservice to both parties. It introduces the risk of exponential costs and development cycle increases without in any way correctly classifying what matters.

Whether an error should be fixed may be assessed with regard to four factors : severity (when the error occurs and how bad the impact is); frequency (how often does the error occur); cost (what is the cost be of correcting the error); and risk (what is the risk of creating other errors associated with fixing the error).

Each factor is then assigned a weighting. The total of all factors is measured against a scale which determines whether it should be fixed or not. The scale is defined with reference to the purpose of the software. A severe but very rare error in cellphone software which has a high fix cost and risk should result in a "do not fix" result. The same error profile in commercial airline "fly-by-wire" software must give a "to be fixed" score.

The result is a practical, flexible approach to determining whether a particular error should be fixed or ignored. The software provider is not unduly burdened with the obligation (probably never ending) of correcting errors which have little practical relevance at significant cost while the customer avoids the risks (and potential costs) associated with the unnecessary correction of errors or the correction of errors which may result in significant additional problems. Ultimately, the objective should be to achieve an acceptable standard of integrity having regard to the purpose of the software, as opposed to an idealised outcome.

As for that car that you may thinking about buying in the next few years, think about the 300 million lines of code. In lawyer-speak (Arial 11 font, 1.5 spacing) that's near enough eight million A4 pages. Would your lawyer undertake to deliver that with a guarantee of no errors?

Written by: Clem Daniel, Director, TMT, Cliffe Dekker Hofmeyr