Most devs I know are problem solvers by nature. We’re naturally inclined to start finding solutions as soon as we hear a problem stated.

Yet no matter how satisfying it may be to immediately board the bus to Solution Land, it is always worth it to take a moment and ask ourselves a simple question: “Do I actually understand the problem?“. Allow me to illustrate with a humorous anecdote.

“Make My Screen Transparent”

A few years ago, a development team for an “enterpris-y” desktop application got a request from a power user to make the screen optionally transparent. Not only that, this user wanted the ability to control which portion of the screen would be transparent.

Almost immediately, the team started brain storming:

– “Ok, transparency should be simple enough if there aren’t a lot of controls on the screen”

– “What happens if the user is trying to interact with the transparent part?”

– “Is the transparency a binary setting or can you vary it?”

– “What would the UI for this look like? How about a slider on one side of the page that he can use to control opacity?”.

After some time had passed, someone finally said:

– “You know, this is going to be pretty difficult to get done right. Also, I’m not sure exactly why we need to do this in the first place. Should we talk to this guy first?”

And so they did. After asking why he needed this functionality, the user said that he had to work in multiple applications and really wanted to see one of them while working in the other. Making the screen transparent was in his mind the obvious solution.

Hearing this, one of the devs said:

– “Is there a reason why dual monitors won’t work for you?”.

– “Dual monitors?” answered the user. “Wait, are you telling me I can connect more than one monitor to my computer?”

But What About Paralysis by Analysis?

Having the discipline to define the problem first is really hard. Moreover, defining the problem correctly is even harder. It’s easy to get antsy and start trying to “do something”.

In fact, a mistake I used to make frequently is confusing inaction with indecision. “Why aren’t we doing something already?” I’d say, “Isn’t this paralysis by analysis?“.

Well, there is a big difference between figuring out what to do and why to do something. If you understand why you have to do something but are struggling to decide what to do, you should just pick a direction and go for it. After all, the reason you’re struggling is likely because the right choice isn’t obvious and no amount of hand-wringing will change that.

However, if the why isn’t clear or well understood, picking a solution won’t help. Unless you want to make the screen transparent.

You may also like:

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!

This post got one comment so far. Care to add yours?

  1. Erik says:

    Whoah. I’ve gotta try that dual monitor thing. 😉

    Anyway, it’s an excellent point about not bothering to consider the “why”. Sometimes I see that exemplified on stack overflow where a series of technically accurate responses to a weird question come in before anyone bothers with a comment like “why would you want to do that?” Someone does come along with that comment, but you can see the subset of programmers more interested in being right quickly than in solving the real problem.