Home > Technology > Our software is perfect. If something has gone wrong, it must be YOUR fault – The Register

Our software is perfect. If something has gone wrong, it must be YOUR fault – The Register

Something for the Weekend “That’s it! I’ve had enough of this! I’m leaving!”

How tiresome. Oh well, let them leave. Perhaps then we’ll get some peace – although I doubt it.

Sure enough, a quick scroll downwards reveals three more posts from users that detail how a small piece of commercial software fails to meet their high standards. Each whiney post culminates in a gloating, toys-out-of-pram declaration that from now on they will use a competitor’s software package instead.

Social media is absolutely the worst place to seek assistance with a product.

Compare it to a software company’s own web-hosted user community forums. Here, a user will write a post inviting suggestions to assist with a problem whereupon fellow users try to oblige. But the same software company’s user support groups on social media tend to attract dramatic types.

These are not people seeking help with a software problem. They want to tell you how unhappy they are with the software. They express the importance of their custom and the gravity of their dissatisfaction. They predict that their decision to cease being a customer will have catastrophic financial repercussions for the software company.

It’s not a cry for help. It’s a cry for attention.

Imagine if they did this in a shop. “Look at me as I walk out the door! I’m leaving right now! See me as I reach for the door handle… I’m turning it… I’m going out… Watch me as I step through the doorway…” etc.

The one thing that this class of user hates the most is a software update.

Here, you and I may diverge in the way we react to an update. You work in the industry and are naturally cautious, so you hold back and wait to see what happens. You prefer to let other customers wrestle with all those weird new features that nobody asked for, unexpected incompatibilities, and potential performance issues. Like a careful motorist who leaves a gap of two chevrons behind the car in front, you maintain a graceful breathing space behind any latest software release.

Me, I see the notification and have to exercise extreme restraint to stop myself hammering on the Update Now button, yelling: “Yeah! A bug-fix! Get in!”

The Thrill Of The Update is beginning to wane, however. I have noticed a growing trend for cloud-based products to enforce updates whether you want them or not. In parallel, there is a growing trend for these mandatory updates to be utterly dreadful.

A SaaS product used by a client did this to me just recently. To be fair, it had given fair warning months in advance that there would be a major update to the system. Sure enough, we booted up on Monday to find it had changed – completely. UI, menus, workflows, shortcuts, the lot. Delaying or refusing the update was not offered as an option.

The updated app is pants.

It freezes frequently, crashes regularly, and occasionally even spontaneously reboots your computer mid-flow, which keeps you on your toes. Did I mention it was a customer-facing system? It’s not a good look.

My suspicion is that nobody outside the software company’s HQ got around to testing the update before rolling it out. Small things give the game away, such as how the agenda function now insists on displaying all meeting details exclusively in Pacific Daylight Time. Our customers have been asking why we keep booking meetings in the middle of the night.

So, we do the right thing: ignore social media, sidestep the user community forums, and log a support ticket. In response, a support rep asks me to send her my log files. Good idea: hopefully they should contain a record of the crashes and freezes. The only problem is that the software’s log files are quite literally empty. Zilch. I send the files anyway.

  • They come back to me to complain that the log files are empty.
  • I respond to say that I am aware of this.
  • They state that they cannot investigate the problem without the log files.
  • I write back expressing regret that their software not only keeps crashing on us but apparently also fails to record its own log files, and politely ask what they want me to do about it.
  • They suggest that I must have installed the local app incorrectly.
  • I point out that I did not install the software at all: it was a forced update that happened automatically and was completely out of my hands.

At their request, I have uninstalled and reinstalled the local app several times on multiple computers, and I have submitted multiple copies of log files – which appear to be variously empty or, for some unfathomable reason, always precisely TWO DAYS out of date. At one point the support desk provided details on how to roll back to the previous version, only for us to discover they had disabled big sections of its functionality so is useless to us.

All of this, as far as they’re concerned, is our fault.

Just as we were pondering what to do next – should we start testing some other products from competitors? – another service we use went haywire.

That is, it was updated automatically without giving us a Not Yet button to click on. Worse, there was no notification it was about to happen. The service update just did its own thing overnight without so much as a word of warning, headed off for a celebration curry, and spent the next day having the runs.

It freezes and crashes frequently. It’s another customer-facing app and some of our customers are saying it has been freezing and crashing their computers too. Not a good look. So we log a support ticket.

The response is instant: a support rep tells us we are wrong. The software underwent comprehensive in-house testing before being rolled out, we are told, so the problem must lie elsewhere.

For “lie elsewhere,” read “it’s your fault.”

We tentatively ask them if they would like to see some log files. “Oh no, we don’t keep those,” they tell us. “It’s a privacy matter.” What about your own log files on the main system, we ask. “No we don’t keep those either.”

Then they go on the offensive, accusing me of running something else on my computer.

Well, of course I’m running something else on my computer: it’s a computer, isn’t it? That’s what they’re for. If my phone doesn’t work and I complain to my phone provider, they don’t accuse me of willfully using my phone to call other people, do they?

Given such a response, it seemed a waste of ANSI characters to point out to them that in-house testing in an air-conditioned, laboratory-controlled, germ-free-adolescent room in the basement is insufficient. Beta testing should be done, if not in the wild, at least in an acceptably realistic reproduction of a grubby user system.

But developers have always known this. Who were the beta testers for these two cloud-based software service providers? Were there any?

Sure, users are a pain in the ass. However, outright denial that there is any problem is not the best way to solve bugs. It’s bad enough that they may not be adequately beta testing; it’s worse that they won’t even accept bug reports after rollout.

It’s odd, for sure, but it seems to be the new way of doing things. Bish-bash-bosh, get the software out! Hire a UX designer to make it look nice so nobody notices that it doesn’t work! Three cheers for Disruption!

It may be the new way but insistence that the customer is always wrong is not the best way to retain business. That’s it. I’ve had enough. I’m leaving.

Watch me as I walk out the door… watch me, everyone…

Youtube Video

Alistair Dabbs is a freelance technology tart, juggling tech journalism, training and digital publishing. Don’t get him started on FAQs. Why is it that FAQs never include a section on ‘Bugs, Crashes and Workarounds for Amateurish Software Development’? More SFTW here. Other stuff at Autosave is for Wimps and @alidabbs.