Easy and Hard Problems
Tonight I've been thinking about that face Deryl gives me when I try to explain that it's OK for me to say some feature request is "easy". It's that look that says, "silly PM, you're dangerous and you should be destroyed."
First off, I'm no PM (never really was <rimshot />). I am, however, probably dangerous but that's why I'm trying to redefine Easy and Hard. They sound like opinion words - you would think you could convince someone that some problem has an easy solution and some other problem's solution is hard.
I theorize that "easy" and "hard" are statements of fact. Here's how:
An easy problem is one that's been solved before by someone who is accessible to consult on solving the problem again. A hard problem is one that hasn't been solved before by anyone who can be consulted with. Moderate problems fall somewhere in the middle. Where else?
An easy problem may have a solution that requires months of effort to implement. This is something the feature requester typically doesn't understand. They see the feature implemented right over there. They just want the same thing. That's ok - it's an easy problem but it's going to take months to make it happen.
Likewise, a hard problem may have a solution that requires minimal time to implement. The New York Times Sunday Cross Word is a hard problem but give me a week and I'll "implement" the solution (I'll get the answer from the key in the new paper)...
So, within a closed set of consultants, it's possible to ascertain to 100%
certainty that a proposed problem has an easy or hard solution (assuming
there's no debate on the congruence of the two problems - give me a little
wiggle-room here).
So, using my definitions, there's no need to go around putting down rabid
PMs (at least not for saying something's easy)...