ticket punching

I recently sent off another report through FixMyStreet, pointing at the horrible state of the roads round here. (I am more than a little disappointed with the Android client app, by the way.) Within a week, some of the worse potholes had been tar'n'gravelled. Meanwhile, even more seem to have appeared or worsened. What it needs is someone to have a look down the street and think about resurfacing, or at least for some sort of statistical alert to fire showing an unusually high level of potholes based on the incoming reports.

I'm not aware that any of the councils are doing anything clever with the stats, which is itself disappointing. All the cool kids, meanwhile, are fascinated by people like Adam Greenfield and his "walkshops on networked urbanism". He likes the idea of using a ticketing paradigm for things like FMS; I'm not so sure. (More here. First, as friend of the blog Duane Griffin pointed out, geeks love trouble-ticketing and nobody else does.

In fact, Duane's exact words were that every young programmer eventually decides to design their own ticketing system. (What he didn't say is that once they have wasted their time and failed, they are no longer young.) I suspect that this is simply a case of the face growing to match the mask - a hell of a lot of IT people spend significant chunks of their time in symbiosis with either a ticketing application, a distributed version control system, or both, and as a result they come to imagine that all the world's problems are soluble in a typical Sourceforge project page.

Secondly, there is a more fundamental problem with this - it requires problems to be discrete, atomic, and transactional. In fact, as our keen and agile minds will no doubt have noticed, these characteristics are also intrinsic to the MySQL or SQLite databases that underpin these applications. You open a ticket, it gets assigned, it gets updated, it gets closed. But how do you model a persistent or repeating task, or one that involves a relationship rather than a truck-roll? I don't, in fact, want potholes patching; I would like the road surface to be maintained, which implies changes in Islington Council's budgeting and management procedures.

And I suspect that an unintended consequence of ticket-based support in general is that it trains everyone involved to prioritise cancelling the noise. Do the minimum necessary to outprocess the ticket. It requires a further, meta-level of analysis to recognise any root causes - there's a kind of old fashioned Taylorist view of organisation embedded here. If change is needed, it has to come from some sort of management layer analysing the stats. Further, and more subtly, it models the user, customer, or citizen as an entity that is either silent, or whining. You are expected to shut up, until your environment becomes intolerable, at which point you squawk.

Now, Daniel Davies would probably say that negativity is useful. It is harder to contribute positively than it is to oppose stupidity, so you're more likely to do some good to society by flinging poo than by drafting a manifesto on the future of the Left. He has a point. And Stafford Beer's Cybersyn actually worked on this principle - enterprises were silent while they could deal with their own problems, and only escalated issues in the system when they encountered something they couldn't fix themselves. But I can't help being sceptical that this is any way of organising a city. By the time you get significant numbers of tickets for cracks in a viaduct, your problems are well advanced.