Human problem or software problem?

Here's an excellent post from 37signals: Control vs. Communication.

Whether you build software or use it, this is worth reading. In fact, it applies to organizations in general. The question is: When you face a problem, do you solve it through rules, policies or, in this case, software restrictions, or do you solve it through communication and individual responsibility?

More and more, there's a perspective that software must prevent every mistake a user could possibly make. In fact, if a user can mess something up through a maze of obscure steps, steps nearly intentional in their negative impact, it's a bug in the software, not the person :)

Simply communicating with people about your expectations of their behavior is often the simplest and most effective solution. It’s respectful, it’s kind, it’s fair. And if someone does something you didn’t want them to do just remind them politely that they weren’t supposed to do that. They’ll almost always get it the second time.

The fact is that someone who is attempting to route around authority will continue to seek out those avenues when they hit a manufactured roadblock. That's the core issue to address. Software can do a lot of things, and certainly must handle common mistakes as well as common hacks, but at some point the user has a personal responsibility as well.

Read the full post.

Comments

[Todd McKinney]

Brian, I think you're right in your suggestion that the core issue is communicating expectations to users. This often gets lost both in system design, where we have a very expensive "arms race" to harden things, as well as in operational communication with end users.

A recent personal example may explain more clearly what I mean. We've got some significant system churn going due to the coming DST change. I will be spending a lot of time over the next couple of weekends getting environments upgraded with the least impact on users. One interesting thing came up on Friday as we were communicating the details of the process with a customer and they said "oh, if we have to do that, can we wait until Thursday or Friday to do it?"

The problem, and it's a costly one, is that the project managers have assumed that the customer will be inconvenienced less if the change happens on the weekend. Rather than suggest FIRST that we would prefer to do it during the week, then offering above and beyond effort if required.