With the use of computers now almost universal in business life many solicitors in general practice will be encountering computer litigation for the first time.

The number of disputes about computers is increasing rapidly but these cases present special difficulties for the litigator.

In the archetypal computer dispute, the clients are a small to medium-sized business.

They have been persuaded by an enthusiastic salesman to procure a new computer system.

The bulk of the cost goes on computer hardware and standard 'off the shelf' software.

However, the standard software does not exactly meet the clients' needs.

The salesman has assured them that this is no problem.

Some modifications will be made to the standard package, adding, say, 10% to the total price.

On this basis, the clients happily go ahead.

The hardware and the standard software are duly delivered.

There follows a period of protracted discussions about the modifications.

Various editions of revised software are delivered but they never seem quite right.

The clients complain that their data is being corrupted.

Weeks turn into months and still they are not getting any real use out of the new computer.

Finally, the clients lose patience and terminate the contract.If the supplier has not been paid he or she will be the plaintiff, with the customer making a substantial counterclaim .

If the supplier has been paid the customer will be suing.

In either case, the customer will probably want his or her money back rather than damages for breach of contract.

The main issues will concern the supplier's performance.A useful analogy can be made with a building case.

Both involve disputes about quality and time of performance, both involve complex facts and are heavily dependent on expert evidence.

But the analogy soon breaks down and the differences have important implications for litigators.Simple hardware defects can be dismissed from the discussion.

A faulty printed circuit board or disk drive can cause serious problems but the cause is usually easy to diagnose and the cure is straightforward: the offending part is simply replaced.

The customer will be protected by the warranty and/or a maintenance agreement and if necessary can assert his or her rights under the Sale of Goods Act 1979.

The same applies to 'damaged' software.

As computer disks have no intrinsic value, the supplier will not hesitate to provide a free replacement.

The real difficulty arises with computer systems which do not perform as expected, or do not perform at all, because of the way the software is written.Three basic types of problem can be identified, although these may well occur in combination: first, the software works as the author intended but not as the client wants.

For example, a particular process which the client wishes to perform is either not possible or can only be performed in a cumbersome and inconvenient way.

Another common complaint is that the system is not fast enough.Secondly, the components of the system work satisfactorily in isolation but not in combination, ie they are 'incompatible'.

This is a very common problem.

Major or minor incompatibilities can affect any computer system.

Some such problems are well known.

Others can only be resolved by replacing components of the system until mutual compatibility is achieved.The third basic type of problem is that software is defective, ie it does not work as expected, or does not work at all, because of some error or omission by the author.

This can either be because it contains a fault (a 'bug'), or because it is not finished, or both.

The fault or omission may very well be minuscule.

A simple misplaced comma in the text (the 'source code') of a program could totally disable the program or, more insidiously, cause it to operate in an unexpected way.

In one sense the fault is trivial: the computer is like a car which has run out of petrol.

As soon as the fault is diagnosed, it can be rectified at negligible cost.But how long does it take to diagnose the fault? Anyone who has unknowingly run out of petrol will know that it can take some time to realise what the problem is.

In a computer system the problems of diagnosis can be immense.

An expert trying to identify a fault in a complex program written by someone else, and without access to the notes and explanations of the author, could spend days, weeks, or months investigating.

On the other hand, the author might cure the problem within minutes.

The same applies to an incomplete program.

The author may have only a few days' work left to finish the program.

For a stranger, without 'documentation' for the software, the task of analysing the structure of the system in order to complete it may be so great that it would be easier to start again.The first two categories of problem are primarily concerned with fitness for purpose obligations.

If the contract requires the software supplier to provide a particular feature or to work with particular hardware then he or she is clearly liable if the requirement is not satisfied.

Conversely (and assuming reasonable skill and care has been employed) he or she will not be liable if the contract does not expressly or impliedly provide for these matters.

What may be less clear is that the third category of case tends also to be determined by fitness for purpose obligations.

Continuing the building analogy, one might identify the first two categories as design defects and the third category as workmanship defects.

If it can be proved that the 'workmanship' of the supplier falls below the standard reasonably to be expected of him or her then the analogy holds good.However, in practice it may be virtually impossible to prove this.

One of the most striking features of computer cases is the fact that computer software can be wholly useless without this indicating any fault or want of skill on the part of the author.

If the program is unfinished then it is to be expected that it will not function at all until it has been completed in every detail.

If the program contains a trivial error, such as the misplaced comma described above, then, once again, it is to be expected that its function will be grossly impaired.

In a typical computer dispute, relations between the parties will have broken down at this 'nearly but not quite finished' stage.

At this point the analogy with building cases breaks down.

A new house which is 95% completed has very substantial value.

A computer program which is 95% completed is worthless to the customer.

From the client's point of view there has been a total failure of consideration.

From the supplier's point of view, he or she, has done almost everything required and only a small amount of work remains to fulfil the contract perfectly.

In Eurodynamic Systems plc v General Automation Ltd QBD (unreported, 6 September 1988) Steyn J found that: 'The expert evidence convincingly showed that it is regarded as acceptable practice to supply computer programs (including system software) that contain errors and bugs.

The basis of the practice is that, pursuant to his support obligation (free or chargeable as the case may be), the supplier will correct errors and bugs that prevent the product from being properly used.

Not every bug or error in a computer program can therefore be categorised as a breach of contract.' In practice, it may be very difficult to prove a case based on failure to exercise reasonable skill and care.

The customer's best chance of success lies in proving a failure to meet a performance obligation.

Ideally, the parties will have contracted for the achievement of some objective benchmark within a specified time.

However, the dispute has probably arisen because of the absence of any such express benchmark.

The lawyer's job is to identify the performance which was required.

If the supplier has failed to meet a fitness for purpose requirement then he or she is liable, even though it is not possible to prove any lack of skill.This immediately raises an issue which has been the subject of much academic discussion.

Is a contract for the supply of computer software governed by the Sale of Goods Act 1979 or is it a contract for services governed by the Supply of Goods and Services Act 1982? (See, for example, 'Software as goods: nullum simile est idem', Scott (1987) Computer Law and Practice 133.) Contracts for the sale of goods always contain implied terms as to fitness for purpose except to the extent that they can lawfully be excluded (see s.14 of the 1979 Act).

On the othe r hand, contracts for work and materials normally only require the supplier to use reasonable skill and care (see s.13 of the 1982 Act).

In the sort of dispute discussed here it is unlikely that the transaction can be treated as a simple sale of goods.

Practitioners should therefore be very wary of using Sale of Goods Act remedies, in particular the remedy of rejection.

The clients will probably want to return the computer system and get their money back.

It is very unlikely that they will have a simple right to reject the system.

The client's right to return to the status quo ante will depend on proving that the supplier has either not provided any performance at all or has performed so badly that he or she can be taken to have repudiated the contract.A solicitor advising the customer should be careful to avoid putting the client in the position where he or she is subsequently held to have repudiated.

For the reasons discussed above, the fact that the system is useless does not necessarily mean the customer is exonerated from further performance.

The solicitor should seek to establish some certainty by negotiating a last chance for the supplier to complete his or her performance.

It will be important to have a clear agreement as to the criteria to be met as well as the date by which they are to be met.If the dispute proceeds to litigation, expert evidence will certainly be necessary.

The practitioner will face special difficulties in getting such evidence.

In the first place, it will be difficult to find someone who is both expert in the relevant area and capable of giving authoritative opinion evidence in court.

Recommendations can be obtained from professional bodies such as the British Computer Society and the Association of Professional Computer Consultants.

A number of accountancy firms also offer services in this area.

Having found an expert it is very important to give him or her careful guidance.

Unlike a doctor or a chartered surveyor, one cannot expect the expert witness in a computer case immediately to identify the legally significant issues.

This is a task for a lawyer, and is not straightforward.

It is easy to spend vast sums on a comprehensive report which does nothing to resolve the contractual dispute between the parties.

A better approach is to establish a dialogue with the expert.

The expert will need to form some preliminary views as to what has gone wrong and try to explain this to the lawyer.

The lawyer will then have to put the facts into the framework of a contractual dispute, and highlight technical issues for further investigation by the expert and so on.

If the case is substantial enough to be in the High Court serious consideration should be given to having it heard by an official referee.

In any event, it will be highly desirable to have official referee type directions.

The scope for misunderstandings in this type of case is so great that it is essential that the experts should have without prejudice discussions to try to narrow their differences.

Reports and statements should be exchanged well before the trial.The solicitor who has been brought in at the contract stage should ensure that the parties have clear and verifiable goals to achieve.

If the solicitor is brought in at the stage where a dispute has emerged but the parties are still talking, he or she should try to negotiate a verifiable completion target rather than gamble on which party will subsequently be held to be in repudiatory breach of contract.

If the solicitor only comes in after relations have broken down irretrievably he o r she should find a good expert and liaise with him or her closely in investigating whether the (implied) performance obligations in the contract have been met.