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.
The best ticket-based experience was based around an extraordinarily poor proprietary bug tracking system, but had a committee reviewing, re-prioritizing, merging and deleting tickets twice a week as required. The product manager (with whom I still work, in another organization) was totally on top of the bugs/feature requests to the extent he had a lot of the tracking numbers memorized for long running issues.
There should be someone somewhere with detailed knowledge watching things and integrating a story out of it. Eternal problem->resolution is not caretaking.
I can imaging incorporating a GIS component into a tracking system to help, and assigning regions to people or even allowing ad-hoc queries for interested parties to review history and determine problems. To my suprise MySQL has a relatively high level of support for this:
http://dev.mysql.com/tech-resources/articles/4.1/gis-with-mysql.html
And if MySQL does it, presumably Geodjango will sit above it.
But the guy who memorised ticket numbers is exactly the problem. Asperger’s isn’t a methodology. Now, a ticket system that let the user specify a meaningful name for an issue would be an advance; one that did a Bayesian comparison with other cases and could tell you if it’s that damn thing again would be a triumph.
Although, knowing ticket numbers is the kind of un-standardisable implicit skill organisations have to grow.
The ticket-memorizer guy was not too Aspergers-y, he mostly did that to put the smackdown on the more ignorant managers. He was totally on top of things, merging bugs, killing stupid ones, etc.
My main point is that you need people constantly grooming and raking the tickets and providing oversight. The automation of the tickets is the equivalence of the autonomic nervous system, needs higher functions to make it do useful work. You can provide tools to help (Bayesian stuff, text mining, etc), but a curator is best.
As QA (in another company) I used the source control data to track the developers who were checking the same files in a lot with small changes. They were a rich source of easy bug reports. Never told the developers though.
re: Geo stuff in databases, I once did postal code proximity in mysql (i.e. closest store to your postal code) entirely in SQL; eastings and northings and the pythagorean theorum. I’m not proud of that, but I did it.
“an unintended consequence of ticket-based support in general is that it trains everyone involved to prioritise cancelling the noise. “
To support gawp’s view:
Highly evolved software companies already know this about ticket-based systems. They put some effort into analysing the trends and sources of the incidents. It takes collaboration between support management and product management, so it’s not easy.
Primitive companies take incidents closed as the metric of success. Eventually the company fails because they don’t understand customer requirements well enough to meet them anymore. This may however take quite some time and be very painful in the process. Right now I’m managing my queue by decibel level – the louder the screaming, the higher the priority. It’s not healthy..
re: Doug K.’s comments:
If you have rigid (dis)incentives in place i.e. penalties for too many bugs open on your code, rewards for tickets closed, then the system gets gamed. QA will come to talk to you directly instead of opening a bug on your stuff, tickets will get closed prematurely. That compromises the knowledge you can extract from the data.