Good Robot, Bad Robot.

I dealt with two robots on Friday. One good and one Bad.

The good robot was at Cavendish (A nearby shopping mall). When I drove into the parking garage I noticed that above every parking bay was a little sensor with either a red or green light on it. Red meant taken, green meant free. This means that from the one side of the garage you can easily spot an open bay… Combine this data with a direction system and you have digital arrows above the lanes that point you towards open bays. I drove in, the arrow said turn left, I turned left, another arrow said turn left, I followed and then bam, there’s my open bay. I realise that the electronics and software involved in something like this is all really not all that complicated, but when put together it forms a flawless system that just works ™. I love technology like this; stuff that is so simple yet so effective. No more driving around aimlessly looking for that mystery bay, no more getting stuck at dead ends with 6 cars behind you. The only tragedy of systems like this is that it’s so simple to “use” that we’ll take it for granted within no time.

Henk Kleynhans wrote an interesting post a few days ago about why software developers should do tech support. I agree with Henk and I think I have some additional insight. One of my biggest projects was building a pretty large system that managed the day to day business of a very large online travel company. It was a CRM, ERP, Accounting, Web Analytics etc etc application that was for the most part born out of being at the coal face and seeing what people were struggling with or what took more time than necessary. No one could have written a system specification for the final product… You just would not have been able to see all the opportunities in the beginning of the project, and you almost certainly would have ended up developing tons of functionality that someone thought was a good idea but would never have been used. The key to that project’s success was having a “no rules are good rules until proven so” attitude. This meant challenging every single process until it was as refined as it possibly could be. It meant that sometimes I would have to bang heads with some of the most ingrained procedures in the business, but ultimately the system was, and still is, a success. I still get a kick out of hearing people who initially moaned heartily about its introduction, now wax lyrical about its many virtues and how it saves them so much time etc.

Anyway, those three years, plus some “formal” education in the Business Analysis world, taught me to do what I’ve always done: Question Authority. If there was a procedure in place and it wasn’t immediately obvious why it was there, I had to find out why. And this is where I want to add to what Henk said. Not only should developers be taking tech support calls (which will essentially root out bugs and bad usability) but they should also, in the absence of good business analysts, be actively involved in the day to day running of the business, constantly on the look-out for better ways of doing things or areas where some software could improve the lives of the customer and the business operators.

There was nothing wrong with the Model T Ford. Tech support/engineers might have tightened some nuts or strengthened a part that kept on breaking, but essentially it would have stayed a Model T Ford. The engineers and designers who built the new Audi R8 have improved on decades of learning. It took engineering principles of “how can we make this quantifiably better?” and design principles of “How can we make this work better, feel better, look better etc” to end up with the R8. Henk’s developers are already on this journey with some of the functionality they’ve introduced… they’ve seen a problem that has two solutions. 1. The easy one, make the customer change some settings. or 2. The hard way, Figure out how to solve the problem once so that the customer doesn’t even know you’ve solved their problem. This is the same as the pretty lights in Cavendish… within a few years this sort of technology will be ubiquitous and young drivers will probably wonder why we need little arrows telling us where to go… I mean, a parking lot is easy, you drive until you find an open spot, right? Well, as anyone who’s ever been stuck in a busy parking lot knows, it is a painful experience.

Which brings me to my Bad Robot.
The City of Cape Town still thinks I live in Pinelands and still sends my electricity bill an address I used to live at about 10 years ago. This is despite numerous faxes to the contrary. Once again I found myself on the phone arguing with a call centre employee. They are unable to change my address over the phone because they need a fax. They can’t do it over the phone because I could be anyone. They can do it with a fax because a fax has a signature. They have no idea what my actual signature looks like. Ergo, anyone could send them a fax with a bogus signature on it, ergo, no safer than just doing it over the flipping phone.

I asked the girl if I could speak to her manager. I wanted to relay the vulnerability to someone more senior in the hopes that they might say “Hey, you know what? You’re right, that is a dumb rule”. Nope. The manager was busy (har har) and besides, “She can’t change the rules either”. “So who can change the rules?” I asked. “Nobody, they are rules” she said. “Nobody? I asked… “Surely Thabo Mbeki could change the rules, so maybe someone else high up in the municipality could change the rules too?”. She didn’t understand my example. She was a bad robot. She refused to question her rules, and in her painfully little world the rules were rules and you NEVER change the rules. I like to console my pain with the thought that the very fact that she can’t question rules is the reason that she works as a call centre employee and probably always will. It’s sad, but I guess the world needs droids.

Oh, and their fax number isn’t working. YAY!

over and out.
j.