Just A Summary

All my adult life, I’ve seen a computer as an amazingly flexible servant. If it doesn’t yet do what I need then it’s possible to program it so that it does. That’s what computers are for after all.

This seems to be rather a long way from the experience of the people I’m working with. For them the relationship is inverted. The servant becomes the master and they have to conform to its way of doing things. Flexibility disappears.

On my first day I spent some time keying in data from feedback forms into a badly designed Access database. I was walked through the process which involved inputting data into the table view. This isn’t necessarily a bad way of doing things, but some columns were supposed to be set to one of five satisfaction levels, and those levels weren’t simply numbers, they were text: “Excellent”, “Good”, “Satisfactory”, “Poor” and “Don’t Know/Not Applicable”. Not fun to type in repeatedly.

So I spent 10 minutes setting up a form complete with combo boxes and other appropriate devices to ensure that the data entered was valid, with the added bonus that data entry through the form was way faster. I estimate that it would have taken me at least half an hour to input the data through the table view, and I wouldn’t have a great deal of confidence about its validity. With the form, I had the data input within 10 minutes of finishing the form. Bear in mind that this is the first time I’ve ever used Access; it just seemed obvious that anything that called itself an end user database would be able to do what I needed.

Before I started the job there were already 200 entries, all apparently input by hand. Nobody had taken the apparently simple step of adding a form to make life easier. (Someone had, but it was a terrible form with an insane tabbing order, and nobody seemed to know about it).

It’s terribly easy for programmers to dismiss non-programmers as stupid, but they’re really not. There’s a schism between users and programmers that’s as fundamental as the divide between C.P. Snow’s Two Cultures

I’ve written, indirectly, about this before, but this is the first time I’ve seen the difference so plainly. Mainstream software like Microsoft Office becomes more and more programmable with every iteration and those features hardly ever get used by end users. And end users are the people who really could benefit from this stuff. They’re the people who know what they need the software to do. The divide tends to mean that programmers implement what’s easy for them rather than what’s Right. So users, unfamiliar with the power of programmability, end up feeling that a bad ‘solution’ has been foisted on them.

Picking another example, there’s a bookings system here. It’s terrible. Things that should easy to do in software end up being done by hand—one obvious example is when you use a canned query to find all of a client’s bookings, the list that gets returned isn’t in date order. If you book a room to someone the system doesn’t check that the room’s available, you have to check by hand first (but that’s a pain, because, as before, the list of bookings for a room aren’t in date order)... By any measure, the software these people are working with is terrible. It’s not as if it’d be hard to fix, simply tweaking a couple of queries would make things noticeably better.

As far as I can tell, the people who use this system never met any of the people who wrote the code. Or maybe they never had a chance to play with what’s possible, so they don’t know that software doesn’t have to be this bad.

The Usual Sermon

As those of you who’ve been reading this blog for a while can probably guess, this is the bit where I point out that Agile methodologies win big in this situation. Development that gets a rough model into the hands of the users and then debugs its way to full functionality through a dialogue between users and developers will end up with a more habitable product.

The real power of the conversational approach is the conversation itself. If I can get immediate clarification from the user; if my development practice means that I can say “I think I’ve got an idea that’ll make this easy for you, give me half and hour and have a demo for you”; if I can then deliver running code that shows what I mean, then that can only be a win.

It might take a little more time (the Agile people will tell you it’s actually faster because you don’t waste time on unnecessary code and endless meetings and requirements gathering—I tend to believe them) but I’m prepared to bet that the resulting code will be a great deal more robust and useful. Not just that, but the users will have learned an important lesson about the flexibility of code, which just has to be a good thing. Even if users never learn to program themselves, the knowledge of exactly how flexible these tools are is empowering all by itself.

I’m not sure I’d go so far as to recommend that every programmer out there goes and spends some time working in an office doing the daily admin grind, but if you do find yourself in that position, keep your eyes, ears and mind open. There’s a great deal of good stuff to learn—who knows, you might just come up with the next great product.