OdeToCode IC Logo

Don't Ask Me If It's Possible

Wednesday, June 3, 2009

Years ago, ex-Googler Doug Edwards wrote a blog post to explain the meaning behind a few favorite words in the software developer’s vocabulary: orthogonal, cruft, canonical, and the big one - non-trivial.

It means impossible. Since no engineer is going to admit something is impossible, they use this word instead.

I’ve spent the bulk of my career developing commercial software, and it’s amazing how many sales people, executives, and marketing managers ask if something is possible. Example:

Is it possible to reverse the flow of time when we click this button?

The requests are more realistic, of course, but the stock reply is:

Given enough resources, anything is possible.

The response doesn’t say the feature is impossible, or even non-trivial. You might think the response is the habitual reply of yet another passive-aggressive software developer (the canonical developer, to use Mr. Edward’s lexicon), but I much prefer to think of the reply as a zen-like answer that points the questioner to the realities of software development. Despite what the pointy haired boss hears from tool vendors and analysts, creating software still requires resources – both time and mental effort.

What I’ve Learned

Building commercial software for a vertical market is a … non-trivial endeavor. But, not non-trivial in the impossible sense. The problem is you don’t know precisely what features will provide enough value to attract new customers until you’ve done some work.

I’ve generally found that if someone inside an ISV is asking if a feature is possible, it’s only a feature they want if it comes for free. They haven't done the homework to understand how the feature would work to provide value for the mainstream customer, and the idea is still in an incubation phase. It will be difficult to even estimate the amount of work required.

When they turn the question into:

What does it take to get this into our software?

Then you know they are serious and passionate about the idea, and it’s time to start talking. 

Eduardo Wednesday, June 3, 2009
I prefer that ("Given enough resources, anything is possible.") than when the developer says:

Can't be done

when he really means:

I don't know how to do it
Jacob Wednesday, June 3, 2009
I've taken to snapping off with "we can do anything" when asked those open-ended questions. As you say, nine times in ten business leaders haven't done any homework at all and their query is a subtle way of asking you to do their evaluation work for them. I don't know if "anything is possible" is zen-like, but it certainly puts the responsibility back where it belongs.
Martin Thursday, June 4, 2009
Nice post. I'm using this answer too ;-)
Duke Tuesday, June 9, 2009
Having designed and built commercial software/startup companies now for almost 20 years I would say the problem isn't the feature, if the feature has merit, it has value and as such it must be evaluated against development and support costs etc. The problem is marketing and the fact that no one holds these guy's feet to the fire. For example when I get a feature request from marketing, I ask them how many sales will this feature generate, very important question and one where I want the answer researched and documented. That answer gives me the potential market value of that feature (or one that I can call BS on), now I can determine if the feature value is worth the investment in development etc. If we proceed with a feature and it doesn't result in x sales, guess who gets thrown under the bus, and its this consequence which keeps marketing honest and that is the problem. Those asking for features aren't willing to accept any consequence thereafter for that feature, so why not ask for the world if you got nothing to lose.

I once had a group of marketers who thought if we charted a private jet flew down to Houston, chucked a little party and did the golf thing we could land a very large deal (this was software worth millions of dollars per contract with a very small but very high end market). I suggested that I would agree to their request given if they didn't get a signed contract they were walking home. This to me was a perfect example of the problem of no responsibility in marketing which is frankly epidemic in our industry. Make marketing responsible and answerable and you will see a natural reduction in requests for bogus features.
Duke Tuesday, June 9, 2009
The other thing I should point out is finding a good software marketer is far more difficult then find a good coder. My experience is far too many marketing guys try to market software based on features it might have in the future, rather then selling the features the product currently has. I sometimes think this is because most people selling software really don't know how the software works or how it is used as a tool to enable the client and hence overlook the big picture to focus on some minor peripheral issues.
.net development Monday, June 29, 2009
Great Post! Really very useful one.
Comments are closed.