You can never predict how customers will use computer systems, but one thing is certain, everything that can happen, will happen, whether you like it or not.

My company, systems@work, is the author of specialist software for expense management, and for the management of professional services organisations. Ours are highly configurable systems that can be used for a very wide variety of purposes. Even the terminology can be modified by the customer to suit the customer’s needs – one organisation’s ‘project’ is another’s ‘engagement’ or ‘case’, and yet another’s ‘investment fund’. Timesheets, attendance forms, expense forms, purchasing forms, absence request forms, planning, invoicing and reporting – these are some of the system’s possibilities, but each of our customers will set these up and use them in different ways. There is no right way to use our software, and however they set it up and use it, our customers must expect it to work.

Some years ago a few of our customers asked us to develop a new feature. Especially because end users might be scattered across the globe, they needed their administrators and first-line support staff to be able to log in ‘as if’ they are another end-user. And no, such end-users wouldn’t do any updates, they’d just be looking at the system as if through the eyes of the user they are trying to help, and yes, they wanted the end user to stay logged in whilst the administrator did his or her diagnosis, so both users could look at the same screen together.

So, we provided a highly restricted option called ‘Identity Switch’ that enables one end user, the administrator, we supposed, temporarily to log in as another.

Having two end users logged in to a system is uncomfortable. In our system, as in many, there are all sorts of temporary tables and sets of records that are identified by the end user’s name, and if two users are updating the same set at the same time you can create logical chaos. For that reason, we make it impossible for two users to login at the same time with the same user credentials. If they attempt it, the system says no.

Except, of course, for the administrator or support employee using the new Identity Switch function. We assume they will be careful, conscientious and that they understand the dangers of using Identity Switch to do updates in the system on behalf of the other user.

But you can never predict what users can do, and if there’s something you don’t want them to do you must prevent it, not merely advise them against it. Even if it’s more coding work up front, it will save you time later.

Over the last few months we’ve received a small flurry of reports of a few links between records getting lost.  It worried us, of course, and we spent many days investigating how it might have happened, finally discovering that it happened when Identity Switch was used. It turned out that Identity Switch was used for purposes way beyond those we had anticipated, not in exceptional circumstances, as we had recommended, but as part of the normal business process.

‘We warned you,’ we might say.

But what would be the point? We’ve still got to spend hours and hours diagnosing and repairing the problem.

There is no moral high ground to occupy if you’re a software developer. You can try to occupy it, but you’ll obtain no advantage. You simply cannot tell your users how your software ‘should’ be used, especially if you’re trumpeting its configurability. If it can go wrong, it will go wrong. If it can be ‘misused’ it will be.

In reality, there’s no such thing as ‘misuse’. If there’s something you don’t want your users to do, you must stop them doing it, not merely advise against it.

We’re working on it!