Welcome to Michael Paterson & Associates

This site looks simple because you don't have a Web Standards compliant Web Browser. You can't see the site design, but all of our content is still available. Please enjoy your stay and consider upgrading your browser to view our full site design.

Contracted Computer Programming: 5 Steps to Take to Avoid Misery

Call us on (08) 9443 5383
if you would like assistance

by Michael Paterson

Do you use computers in your business? Do you need someone to write a computer program to help make your business more efficient?

In this technology/information age, computers programs can be very effective business tools: streamlining work processes, increasing productivity and making your business more efficient. Most businesses are not in the program-writing business and engage computer experts to write programs for their businesses. Unfortunately, not all programs are expertly designed or written, and can leave you without the program you thought you were getting. Following these 5 steps can prevent a lot of heart-ache.

1. Writing the Specification

Only you know your business and what you want to do to improve it. A lot of problems occur because the programmer does not fully appreciate what is required of the program.

Step one is write down in as much detail as possible, exactly what you want the program to do and how:

  1. the results you want - be it is invoices, orders, written reports, financial reports, documents;
  2. the information needed to generate the results - where it comes from, what form it comes in, who collects it, how it gets into the system; and
  3. how you expect the program to benefit you business - less time to record and process information, more useful reports, reports not available before.

The specification should be written in consultation with the programmer to ensure that:

  1. what you want is possible for what you are prepared to pay; and
  2. the programmer properly understands what you want.

Putting the specification in writing is a great way of clarifying things in your own mind, as well, because you cannot write it down without thinking clearly and logically about the problem at hand.

2. Performance Criteria/Testing

Having written down what is required, the next step is to write down the tests and the results which will demonstrate that the program does what you want it to do. If the program passes the tests, it will be deemed to be satisfactory, so make sure they are very, very comprehensive. Again, this should be carried out in consultation with the programmer.

3. Ownership

Many business people are surprised to learn that they do not own the program that they have paid to have written for them! Instead, they merely get a licence to use the program for the purpose contemplated by the deal and the programmer is free to sell other licences to the business’s competitors. This is because, without an agreement to the contrary, the Copyright Act 1968 (the "Act") makes the author of the program the owner of the copyright in it.

Before the program is written, put down in writing who is to own the copyright. If it is not in writing and the copyright is to be owned by you, not the programmer (and I suggest you seek this wherever possible) writing is required under the Act to perfect the transfer of ownership.

This also applies to the specification and the performance criteria, so ensure these are also yours, not the programmer’s and that the programmer requires your permission to use them elsewhere.

4. Price and Payment

Step 4 is to write what you have to pay and when. Wherever possible, do not pay people by the hour because this is how costs start exceeding budget badly. Tie payment into performance by the programmer, eg:

  1. a small initial deposit;
  2. a small amount on completion of the specification and performance criteria;
  3. small amounts during the development; and
  4. the bulk after the program passes the performance tests.

Keeping most of the payment until the end is the best lever to ensure the programmer performs the job on time and to the required standard.

5. Default

Problems do occur, even if the previous 4 steps are followed. You and the programmer need to know where you stand if things go wrong.

Firstly, write down a list the objective tests that will demonstrate that programmer is in default: not completed within time, does not pass the performance tests within certain time limits, does not work all the time. The tests need to be objective so that there can be no dispute that the programmer is in default. It is not enough that you are unhappy with the program.

Secondly, write a list of the remedies that you are entitled to have if the programmer is in default, e.g. refund of money, compensation for time wasted and inability to use the program.

The programmer is entitled to limit liability to re-doing the programming work or paying the cost of fixing the program. Resist such attempts by the programmer to limit liability on the basis that programmers should put their money where their mouth is.


You will notice that all the steps involve writing. At the end of the process you will have a written contract. All you need to do is put your name and the programmer’s name on the document. Where the programmer trades under a company, try to make the actual programmer a party to the contract effectively guaranteeing the performance of the contract by the company. This way you will not be left with an action against a worthless company if the programmer does default.