Ben Scofield

Ben Scofield

… rarely updated

12 Feb 2013

On "people" problems

My friend Justin Gehtland tweet this a bit ago:

That spawned a quick response from me, Jim Van Fleet, and Ben Vandgrift. I want to refine what I said, however -- and to a certain extent take it back.

First, a definition: a problem is a mismatch between the way the world is (facts and circumstances, in Justin's formulation) and the way that some person wants the world to be. Not all such mismatches are problems (the non-existence of unicorns isn't a problem, despite the fervor with which my daughter wishes they existed), but all problems are mismatches of this sort.

For example, here's a problem: my website is vulnerable to a security exploit. This is a problem because the way the world is (my site is vulnerable) does not match my desires (to not have my site be vulnerable). 

Here's another problem: a space probe sent to Mars stopped functioning the day after it landed. This is a problem because the way the world is (the probe stopped working) does not match a widely-held desire (for the probe to work properly over a long period of time).

OK, so if that's what a problem is, what makes a problem a particular type of problem? What makes something a "people" problem?

I'd argue that we usually classify problems by their solutions. If the way to resolve a problem is by rebooting the server, then it makes sense to call it a server problem. If you have to replace a power source, then it's a power problem. If you have to change code, then it's a programming problem. 

So: problems are mismatches between the world and desire, and we classify problems by their solution. It follows from these two points that Justin was correct -- all problems are people problems, because we can in fact resolve all problems by changing people. Specifically, we can eliminate any problem by changing the desire side of the mismatch. If I don't care that my site is vulnerable to a security exploit, then the fact of its vulnerability is not a problem. If NASA doesn't care that the Mars probe isn't working, then its failure to work is not a problem.

Of course, this makes calling something a "people" problem a triviality. In the vast majority of cases, we want to resolve the problem by changing the world, not our desires. So, let's refine the classification of problems to say that it should prefer solutions on the state-of-the-world side, falling back to the desire side only if no other option is available. For my insecure website, the best solution isn't to stop caring that my site is vulnerable -- it's to fix the code to be more secure (so it's a "security" or "programming" problem). For the Mars probe, on the other hand, we may not actually have a way to change the world -- we can't zip up to Mars and unstick the wheels, though we might be able to push code changes if the issue is one of programming. In that case, we'd either have to live with the problem unresolved or eliminate it by changing how we felt about the situation.