Thursday, January 23, 2014

Discerning the Problem from the Proposed Solution

I often encounter situations at work where a colleague is in pursuit of an amazingly complex solution to a elegantly simple problem.

It starts innocently enough as a conversation about backing up some files. "What's the best way to back up some files I have at home?" A healthy, responsible question. Off to a good start.

Except the reply turns into, "I can help you build a SAN for your home and you can back up everything there." Then it's a flurry of Google searches: "synology," "netgear prosumer," "government auction NetApp."
Come on, that last query was funny.... right?
By the time I'm invited to the discussion, the question has become, "what model of the ReadyNAS would you get?"

Wait a minute. Why are you looking for a home storage solution again, especially one that costs hundreds of dollars? It turns out that the guy really just needed a way to back up his MacBook. "Go buy a WD My Passport for Mac." Plug it into the Mac. Turn on Time Machine. Done.

It's often the case that people, especially IT professionals, ask questions that obfuscate the real problem they are trying to solve. For example, I was once asked how to add a vNIC to a VM. I asked why someone wanted to do that. "So we can add another IP to the server." Clearly there's a better way to do that.

The challenge is to listen not just to the question, but to discern the real question.

---

PS - Now that I've posted this, I'm not even sure why I wrote this. I may have just wanted to write something. Anything. It's just that I have so many ideas during the day, and no time. Then in the evenings, I have time, but no ideas. And the water cooler outside my cube in the basement makes this loud vibrating sound every 8 minutes and it's like Harrison Bergeron. Ok, that's enough. Long footnotes and post scripts remind me of House of Leaves, and that's disturbing.


Mastodon