For those outside of the IT field, developers are looked at as miracle workers – through us, business leaders think anything is possible (and they often see no reason why we can’t work our latest miracle by the next morning). In reality though, we do work miracles; we save companies vast amounts of money every year through increased worker efficiency and automation, we enable new lines of business that wouldn’t be possible otherwise, and reduce energy costs because we keep the office lights turned off. Well, that’s more or less how they see us.

But for all of the wonders we are responsible for, there is one thing we can’t do (no matter what amazing powers some executives think we have to make them look better or earn them more bonuses):

I’ve often described development as being a professional problem solver, and we are often tasked with rather challenging problems to solve. Sometimes the problems are purely technical – making something new possible that previously was impracticable or even impossible, sometimes it’s all about efficiency, other times it’s about image and controlling how people see a company. When the problem is the user though, you know you’re in for a rough day.

I was recently given such a task – the users weren’t listening to their supervisors and they wanted the software to force these users to do whatever it was that management told them they should be doing. I was given less than a week to find ways to make people who don’t want to work, work.

Basically, users fall into three simple categories:

• Power Users – these users understand software, and require little, if any instruction – more than anything, you give these users a tool and stay out of their way.
• Average Users – odds are, your mother or father falls into this category. They understand enough to get by, and with a little instruction they should have no trouble.
• Idiots¹ – odds are, you work with one of these users. You lead them by they hand, and show them exactly what to do – just in time for the boss to walk by and praise them for doing a good job (and 10 minutes later you find them playing in traffic, somehow defying Darwin in the process).

For users of the last category, there’s just not much you can do.

I always do my due diligence while building software; doing all I can to make it simple to use, flexible, and forgiving of user error. I always use extensive data validation, carefully worded instructions and dialogs, and do my best to follow the various best-practice guides for UI and UX; yet for all this effort and design – I can’t write software that thinks for people or makes judgement calls based on business rules that only they know (probably because they make it up as they go).

No matter how helpful or intelligent an application is, or how idiot-proof you think you’ve made it, reality is that you simply can’t fix stupid – you can’t take an incompetent person that refuses to think for themselves and turn them to into a great, productive asset. After years in this industry (which has made me just a little cynical [in the way that Sol only seems little when compared to Betelgeuse]), I’ve come to understand something rather disturbing: idiots keep getting better.

Somewhere, right now, idiots are working to build even better idiots – and that’s a really scary thought.

We can make a user more efficient by automating tasks, providing better information, or helping to manage their workload – what we can’t do is make them smarter, make them think through their actions, or force them to do what their managers tell them. Yet we are, at least on occasion, asked to fix this problem.

Despite our best efforts as professionals and passionate developers; if a user won’t think – we just can’t fix it.