Programmers like challenges. Programming can be all about solving logical puzzles and meeting sometimes quite considerable mental challenges. In a lot of cases, however, programmers do not seem to realise that there are a considerable number of people out there, buying their products, who do not enjoy their computer being a challenge. Software should not be designed as a challenge.

In a similar way the ‘remedy' to the problem with the Porsche fuel injection system (to open the bonnet and fiddle about) shows that the designers are expecting the users to behave like they do. Designers of cars like opening the bonnet and fiddling about inside, just as programmers like ‘getting inside' operating system and tinkering around. Drivers and users do not, and it is unreasonable to expect them to.

Most users are not programmers, but the converse is not true. Programmers are users, and therefore may come to the mistaken belief that what they find acceptable and pleasurable to use will be okay for any user.

Landauer gives a collection of statistics about what sort of people find computers easy to use; they are young, highly educated, logical thinking and middle class. In fact, exactly the sort of people who become programmers. Landauer's statistics suggest that programmers design software for themselves.

Both Cooper and Landauer place the blame for useless and unusable software firmly with the programmers who develop it. But they are at pains to point out that this is not because programmers are stupid and unthinking, but precisely the opposite. It is difficult for a programmer to ‘think their way into' a user who does not understand (and does not want to understand) something like a hierarchical file structure, which is completely second nature to a programmer.

What both Cooper and Landauer suggest are ways of structuring, amending and augmenting what programmers do, so that users are better considered.

As with any other design process there should be an unwritten contract between developers and users. Note that this is different than between the more explicit and legally binding contract between developer and customer. Users need not be customers, in many cases software is bought for users by the companies from whom they work. This puts an extra player in the loop.

Usually a customer buys a product and uses it. If they do not like it they exert economic pressure on the developers by not buying any more of their products or demanding their money back. In commercial settings this loop is extended. Purchasing departments buy software and give (or lease) it to their employees. Those users do not have a direct channel of feedback to the developers and therefore usability may not become a crucial criteria for developers. In any case purchasing departments may not like having their choice of product criticised. It is probable that for every one person who complains to a purchasing department about the products they have bought there will a technical whizz kid who can make perfectly good use of the product, and so what is the complainant's problem? Unfortunately anecdotal evidence shows that for every complainer and every whizz kid there are fifty or so under-their-breath grumblers who get on with using the system, without explicitly complaining, but without explicitly enjoying it either.

The free market is amoral and in this unit we are outlining reasons why software development may push the amorality of the free market into immorality. What is needed therefore is special emphasis by developers, because they in effect control the market, to push their products back into the bounds of ethical and reasonable treatment of users.

Other professions have strict codes and guidelines determining their relationship with and treatment of the public. Software developers lack such ethical codes, mostly because of the immaturity of the field, but as we are discovering their are several subtle barriers to moving software development towards such codes, as well as an ignorance that there is a problem in the first place.

Many countries stipulate health and safety requirements for the workplace. Such requirements have been developed from the study of ‘ergonomics' which looks at physical aspects of design. Offices must contain chairs that can be adjusted to suit the sitter and computer monitors must be adjustable to suit the viewer. Several other physical measurements such as desk elevation, and articles such as foot rests for people whose feet may not reach the floor are legally required.

If ergonomics were begun to be studied during the second world war, then it took about 30 years for their conclusions to filter into legal requirements. By the same measure HCI requirements should now be beginning to filter into law too. Indeed EC Directive 90/270/EEC requires that employers when designing, selecting, commissioning or modifying software should ensure that:

This directive has been incorporated into law for member countries in the European Community, although in its current form it is unlikely that anyone would actually be able to successfully bring an action against an employer for transgressing the directive.

In the next section we shall look at safety critical systems, the failure of which can be very dramatic. When such systems fail peoples health and welfare can be seriously affected and therefore they can have much more of a solid basis for recourse to law.

It is interesting to note the difference between the extremes of the American approach to litigation, which seems to be to litigate as much and as often as possible, and the British approach which is to avoid recourse to law as much as possible. We will later look at the Paddington rail crash of 5th October 1999. Subsequent to the rail crash it was announced that no legal proceedings would be taken against any of the parties that may be believed to be responsible for the crash. This caused resigned grumbles in the British press, but utter astonishment to Americans (several of whom were involved in the crash). The threat of legal proceedings mean that people may not wish to give full evidence to the Public Enquiry into the crash for fear of perjuring themselves. The British priority is (nominally) to find out why accidents occur and put in place procedures to prevent them happening again. The American priority is find out why accidents happen and punish those responsible.

The British approach seems, in the abstract, to be more sensible and level headed, but in reality does not actually seem to work. The Paddington train crash was preceded by the Southall crash for which there was no legal action, a public enquiry and recommendations, very few of which were actually taken up. If the recommendations of the Southall enquiry had been in place, the Paddington train crash would probably not have happened.