Skip to main content

The Chaos Theory of User Ingenuity

There is just no telling what those crazy users are going to do. As a recent post at Worse Than Failure makes us realize, they can simply do some impressively unpredictable things. The case in question has bank tellers using the Windows Task Manager (ctrl+alt+del) to manually kill a process for an annoying dialog their employers had the developers make un-cancellable as an error checking precaution. I am simultaneously dumbfounded at their incompitence for thinking it fine to repeatedly hard kill processes as a form of annoyance reduction and my sheer amazement that the users knew enough to even try it in the first place.

The lesson can be applied in a lot of places. We need to do more than predict what the user will do: we need to make our software robust enough to stand up to the random environmental attacks it will take from the users' strange and completely unpredictable behavior. The user could be clicking on our links or importing our packages (end user versus developer) and inevitably they will do what you did not account for. Account for the unforeseeable.

Account for End User Ingenuity

Software is annoying and the most annoying things will be avoided. The ways we find to work around limitations, real or perceived, are huge. That is exactly what the bank tellers were trying to do. The dialog in question made them double check money counts on large amounts, but they trusted themselves and each other enough to learn how and pass on the technique of subverting the required dialog to save just a few seconds every few transactions. Yes, it didn't not even come up on a typical basis, so don't expect frequency to estimate likelyhood of tampering. The user might put up with an annoying main menu for years, but abuse a glitch to skip a step in a process they only use every few weeks.

Probably the single most effective way to combat dangerous ingenuity of end users is the feedback mechanism. Let the user subvert through you, not around you. Enable responsive adaptation to their needs, and tweak the hell out of the interface to shave off those milliseconds. Milliseconds add up when you're on your feet all day.

Account for Developer Ingenuity

We can take this story and adapt it to ourselves. We know there are things we do to software that only for-pay websites would show you. No one is more abusive to software than those who create it, and when we deal with the internals we only have more strings to pull. Whether you develop libraries consumed by other developers, or want to avoid abusing the libraries you use, there are steps you can take to keeping usage on the path.

Here, our single greatest ally is reduction. Take away optional parameters no one has asked for yet. Don't implement a function that has no use case. Eliminate type checking to allow proper ingenuity through duck typing, while being prepared to properly accommodate common patterns that arise, which you never foresaw. Give the other developers constraints by giving them less to work with, but let the pieces they have flex into shapes they need, so you can take their feedback and adapt the code to officially support every unofficial dirty deed they bend it over for.

Account for Your Ingenuity

Who uses your software more than you do? Maybe the most dangerous person to watch out for is yourself. No one has access to pushing the limits of the software more than you do. The users can find ways to subvert your interfaces. Other developers can exploit oversights in the API. You, on the other hand, can bend the entire thing to your will. If you think a high math function would be useful in all the places you happen to use the special file format library you develop over on Google Projects, don't add it right away. Ask yourself if it really belongs there, if anyone else will you use, or you would accept the patch coming from someone else and without yourself wanting the feature. As much as the users and other developers can take advantage of your software, you need to look over your own shoulder more than anyone, but there are a lot more of them than there are of you (hopefully!), so don't let your guard down from their side, either.


Jason Hare said…
Usually one includes a usability analyst, or should, somewhere in the lifecycle of your development project. User behavior is actually quite predictable. The developer that wrote the application annoying enough to warrant a bunch of bank tellers to run windows task manager to get their jobs done should ask him or herself how can I have written that to run silently in the background to take up less resources so as not to be annoying? In windows tasks should run at most as normal priority and best at low prioroty....just sayin...
Jason Hare said…
Moderated comments AND Captcha? Really?

Popular posts from this blog

The Insidiousness of The Slow Solution

In software development, slow solutions can be worse than no progress at all. I'll even say its usually worse and if you find yourself making slow progress on a problem, consider stopping while you're a head.

Its easy to see why fast progress is better: either you solve the problem or you prove a proposed solution wrong and find a better one. Even a total standstill in pushing forward on a task or a bug or a request can force you to seek out new information or a second opinion.

Slow solutions, on the other hand, is kind of sneaky. Its insidious. Slow solution is related the Sunk Cost Fallacy, but maybe worse. Slow solutions have you constantly dripping more of your time, energy, and hope into a path that's still unproven, constantly digging a hole. Slow solutions are deceptive, because they still do offer real progress. It is hard to justify abandoning it or trying another route, because it is "working", technically.

We tend to romanticize the late night hacking…

Finding "One Game A Month"

I was really excited about the One Game A Month challenge as soon as I heard about it.
For about two years I've struggled in fits and starts to make my way into game development. This hasn't been productive in any of the ways I hoped when I started. Its really difficult to be fairly experienced as a developer, which I believe I am in my day job as a web developer, while struggling really hard at an area in which your experience just doesn't exist.
Its like being a pilot who doesn't know how to drive.

But this challenge provided a new breath to this little hobby of mine. It gave me a scaffolding to experiment, to learn, to reflect on finished projects. I had spent far too much time on game projects that stretched on far past their exciting phases, bogged down by bad decisions and regret.
And it has worked.
I have a lot to learn. I have a lot of experience to gain through trial and error and mistake and discovery. I have a lot of fun to be had making more small games t…

On Pruning Your Passions

We live in a hobby-rich world. There is no shortage of pastimes to grow a passion for. There is a shortage of one thing: time to indulge those passions. If you're someone who pours your heart into that one thing that makes your life worthwhile, that's a great deal. But, what if you've got no shortage of interests that draw your attention and you realize you will never have the time for all of them?

If I look at all the things I'd love to do with my life as a rose bush I'm tending, I realize that careful pruning is essential for the best outcome. This is a hard lesson to learn, because it can mean cutting beautiful flowers and watching the petals fall to the ground to wither. It has to be done.

I have a full time job that takes a lot of my mental energy. I have a wife and a son and family time is very important in my house. I try to read more, and I want to keep up with new developments in my career, and I'm trying to make time for simple, intentional relaxing t…