Don’t just blame the software

On the news the other day when there was a report about a large fine levied on a company for their phone marketing campaign making several million automated calls. Over a series of headlines and interviews, the impression I came away with was that they were blaming the software.

Since the campaign lasted over two months, I would have thought that someone might have thought to investigate and possibly stop the campaign once the complaints started arriving.

But what about the software?

A telephone receiver - it is another automated spam call?
Another automated spam call?

Once upon a time, you would write a computer program to do a specific task. There might be a few things you could change each time it ran but essentially it started at the top and worked down to the bottom and then stopped. As machines developed, the complexity increased. This introduced the problem inherent with all modern software: you can never test everything! As a software engineer, I have had to track down all sorts of “intermittent” errors including:

  • The report that worked perfectly, except on the last Friday of the month.
  • The form that only seemed to fail for certain users (no, it was not a vendetta!).
  • The budget report which sometimes did not add up!
  • The plugin that worked on the test site but failed when it was put live.

In these and other cases, the issue often comes down to configuration or the particular values specified as inputs to the program. The choice of options made by the user dictates how the program runs. For example, the error in a spreadsheet may only occur if a cell A evaluates to zero and because cell B is bigger than cell C, cell D tries to divide by cell A (and this is me trying for an easy example!). Or maybe the user has specified unlimited retries and selection of all properties worth over £10K?

The error may be in the code: not capturing a divide by zero is a classic.  On other occasions, the user may have made a mistake or just does not appreciate what they have asked the program to do. Sometimes you have to be a real detective to track down the issue.

In conclusion

How a piece of software operates can be affected as much by how it is configured as by the actual code. It can also be affected by where it is installed and what else is on the machine.

Reputable suppliers/ sources will have processes and standards in place to ensure a high quality of testing. Some errors will always get through – which is why vendors issue patches. They are also generally open to users reporting errors (with as much detail as possible!).

When you are using software, you need to realise it is not infallible and check what you are doing:

  • When you use Word to create a report, you check the formatting as well as the words.
  • You sanity check the bottom line of a spreadsheet before sending out the quote.
  • A website should be checked in different browsers and on several devices before it is published.
  • You visit your website regularly to check it is still there and working.

So, if you are running an expensive telephone marketing campaign, you would test run in near live conditions prior to the launch and to monitor what is happening as it runs.

Wouldn’t you?