A reason not to automate: policy flexibility

October 25, 2011

We have some bookable compute servers, machines that can be reserved for a single person. When we first introduced them and for a long time afterwards, demand for them was low and we handled all of the booking and related tracking by hand (mostly with email). Demand has been picking up lately and as a result, we've automated much of the process.

(The trigger for automation was when the machines actually got queues of people waiting to reserve them. Handling a single active booking per machine was relatively easy, but queues meant that we needed to track who was next and it became important to end a booking on schedule.)

However, one of the pieces that we did not automate was the process of actually making reservations. It would not have been difficult to do it, but after discussing it among ourselves we made a deliberate choice to leave it out. Ultimately we did it for a simple reason:

When you automate something, what your automation does becomes your de facto policy.

Regardless of what your actual policy is, the practical reality is that people will view what the automation allows and doesn't allow as the real policy. If your automation doesn't allow it, in practice your policy forbids it. If your automation allows it, in practice your policy allows it.

There are two problems with this. The obvious one is problems with your code, including cases that you didn't think to check; for example, one person reserving all of the bookable compute servers at once. When this happens you are in the position of having to take back something that you gave the person, which generally makes people angry. Sometimes you will have to make 'new' policy on the spot to justify it, which makes people more angry.

The subtle problem is that automation is always cruder than real policy, because real policy is implemented by human beings who are prepared to be flexible when it's called for. As part of this, automation also doesn't really allow for appeals or pleading your case as a special exemption; automation just says 'no, that's not allowed'.

We have a general policy on fair reservations of the bookable compute servers; it's reasonably simple and reasonably easy to articulate. But when we talked things over, we decided that we didn't want to actually code it and thus freeze it, because in reality the policy is more flexible; we're prepared to make exemptions, we'll encourage two people who both really want the same machine at once to talk to each other about it (instead of just the first person to make it to the CGI saying 'I got it and that's that'), and so on. We think that preserving all of this is much more valuable than saving some time by automating a form.

(This is a lesson I first learned in the world of MUDs, where any system you automated had this risk; people took what the code did or did not do as being the game reality, instead of simply being an approximation of it. 'The code let me do it so it's okay' and 'the code says this is what happens' both cause problems. Sadly I forget it periodically, given that I was the person who initially thought about automating even the 'make a reservation' portion of the bookable server reservation system.)

Written on 25 October 2011.
« Salting passwords compared to slow password hashing
How to fail at useful cryptography: bad error messages »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Oct 25 00:41:12 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.