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.

Comments

Wake Forest 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...
Wake Forest said…
Moderated comments AND Captcha? Really?

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro