• Project Manager Opportunities
• Network Engineer - (Cisco...
• Support Analyst
• ACCOUNT MANAGER
• C#ASP.NET Developers

Ethics: A tale of trains, planes - and software

Mike Bowern, Information Age

17/08/2007 15:11:48

At the 14th International Conference on Software Engineering, held in Melbourne in 1992, Nancy Leveson gave a keynote address called "High-Pressure Steam Engines and Computer Software".

Professor Leveson's field is safety-critical software, and she compared the development of steam technology in the UK and the USA in the 19th century with that of computers and software in the 20th century.

Both steam and computer technologies have transformed the societies and economies of which they are a part.

The basic steam engine of James Watt and Matthew Boulton was a significant initiator of the Industrial Revolution in the early 19th century: their engines used low-pressure steam (5 to 15 psi), which meant they were inefficient and uneconomical, but were safe because they worked below atmospheric pressure.

Through the 19th century there were many advances in steam technology, including the adoption of high-pressure engines, with a corresponding increase in accidents and explosions, many fatal. Other technological developments were made to try to overcome these problems, with varying success.

Attempts to introduce regulatory measures, including the licensing of engineers, were fought and/or ignored, because they were seen as restrictions on business and progress. The explosions and deaths continued, and it was not until the early 20th century that standards and regulations were adopted and enforced in the UK and USA, and exploding engines became a rarity.

The thrust of Nancy Leveson's address was that she did not want to see the development of safety-critical software follow the same path as that of high pressure steam engines. She provided a detailed analysis of the steam engines' problems and compared them to the development and operation of safety-critical software.

The paper included discussion about the education, professionalism and regulation of software engineers, and the need for software standards in safety-critical systems.

Although the address was give 15 years ago, I believe that it is worth considering again, and not just for software in safety-critical systems.

A second industry that provides a comparison with software industry is aviation. In 2003 we commemorated the centenary of the Wright brothers' first controlled, powered flight in a heavier-than-air machine. By 1953 that first famous flight had developed into a mighty industry with advanced manufacture of commercial aircraft, and airline businesses providing services across the world.

International air travel was becoming commonplace; for example Qantas began flying to San Francisco and Vancouver in October 1953.

There were standards and procedures in place to manage and control the quality of the aircraft in production and operation. We knew how to build airports and runways, and we had systems for things like radar and air traffic control.

Sadly there were accidents and disasters. For example two de Havilland Comets, one of the most beautiful aircraft ever built, tragically crashed in that year. But there were also systems in place to find out what happened, and to prevent these tragedies happening again. Aircraft were taken out of service until the cause of the problem was known.

Engineers studied the wreckage of crashed aircraft to find out what went wrong; tests were made, other airlines checked their aircraft, and the suspect type of aircraft did not fly again until it was safe to do so. The aviation industry was regulated.

About this time, just over 50 years ago, the computer industry was taking off. We had gone past the prediction by the chairman of IBM that the world would only need 12 computers to do all of the calculations needed, and IBM had released what it claimed to be the first commercially successful general purpose computer, the IBM 701.

At that time Australia also had a computer, built by what is now CSIRO, operating successfully and doing useful work.

Now let's jump forward another 50 years to today. Computers are everywhere -- not just the computers and other electronic machinery we have at work, but in the electronics in our mobile phones, our hi-fi equipment, our cars, cameras, fridges; everywhere.

The hardware of today is generally pretty good. We know how to build electronic devices which are reliable, and quite easy to repair if something does go wrong.

But these devices cannot do anything without that vital ingredient, software. Someone once said "modern society runs on oil and software, and we think we know how to replace the oil".

So, given the great dependence we place on software in our lives, we would expect that it would be reliable, not prone to error, to breakdown, to freeze-up. But that is not so in many cases.

Part of the problem is that we do not use sound engineering practices in the development of much of our software. There are some qualified software engineers in Australia and new engineers graduate from a number of Australian universities each year.

However, we do not have a well established specific system of regulation of software engineers in place. By regulation I mean required standards of training and education of practitioners, some form of licensing and penalties for serious non-compliance.

Nor do we have schemes for software product certification where necessary, or a process of recall for the products that are defective.

Now some people might say that regulation in the aviation industry is essential because of the risk to human life, but we do not need to regulate software products. But what about the software which is used in medical diagnosis equipment; automated dosing systems - e.g. computer-controlled IV drips; CAT scanners and X-ray machines; and equipment that automatically gives doses of radiation to cancer sufferers?

Surely we would expect that the software for these, and other critical systems was always developed by qualified software engineers.

In addition to the risks and losses caused by faulty software in these critical systems, we also have major losses in productivity and the need for rework, on a daily basis, through using poor-quality software in our businesses.

The Trade Practices Act requires that products are of merchantable quality - that is, they are fit for the purpose for which they were bought. Have you ever read the End User License Agreement that you accept each time you load a new piece of software on your work or home computer? If you have, you would see that there is no warranty on the product, no form of guarantee of freedom from viruses, or even a guarantee that the software will work.

The licence disclaims any right to merchantability. Would you ever buy any other product important to your business or lifestyle with a warranty like that?

The ACCC is the government body that administers the Trade Practices Act. It is quite certain that the ACCC uses software products with end-user licences like these. I wonder how it can accept the terms and conditions of these licences within the requirements of the Act that it administers.

In 2004 the ACS published a policy statement on Software Quality Accreditation. It recommends a multi-faceted approach to software quality assurance; covering improved processes for software development, appropriate product standards and testing, and the need for trained professional ICT practitioners, subject to the rigours of a professional association.

While the ACS continues to press the need for professional behaviour by its members, there is little evidence of adherence to the policy of process improvement and product standards.

It took about 100 years to establish sound regulation on high-pressure steam engines, to provide adequate protection for the operators and passengers of steam driven vehicles and equipment.

It took fewer than 50 years to provide similar standards and regulation in the aviation industry. Sadly the industry that produces safety-critical and business-critical software still seems to be following the steam engine model.

Mike Bowern is an engineer and the chairman of ELSIC. Nancy Leveson's paper, and other material on safety-critical systems, can be found on her website: http://sunnyday.mit.edu/. The policy statement on Software Quality Accreditation is available in the members' area of the ACS Web site.