
Killing Innovation with Corner Cases and Consensus - terpua
http://steveblank.com/2009/04/22/killing-innovation-with-corner-cases/
======
iigs
"The heuristic I suggest is: hear the corner case objections, make the
objector calculate the odds, if the potential damage estimate is low
(probability of the event occurring multiplied by its ability to put you out
of business) keep the meeting focussed and move on. _If you do this
consistently your team will catch on._ "

I'm not sure what the last sentence is supposed to convey. In my opinion one
of the most important reasons to raise objections is to get people thinking
about other related problems that they may know of but not be thinking of at
the time.

Attempting to suppress dissenting feedback by embarrassing or pressuring
people on the spot sounds like a passive-aggressive tactic to me. If you don't
want the input you might as well just ignore people or tell them to shut up.

~~~
mrcharles
That's not the problem, the problem is when people attempt to use corner cases
to destroy a good idea. Having a valid metric of when corner cases become
truly important is a great way of avoiding people destroying ideas before they
have a chance to come to fruition, simply because of corner cases that may or
may not have major impact.

In the article he even states that it's good to hear the corner cases. You
just have to make sure they don't rule the day unless they actually will have
major impact.

~~~
sblank
That's the point I was trying to make in the post. But you said it much
clearer than I did.

steve

------
edw519
Sure sounds a lot like premature optimization.

~~~
stcredzero
True. It's not as if the group will be so smart, that they will be able to
think of all the corner cases ahead of time, anyways.

There are times when something might not be just a corner case, however. One
should ask: is there a motivation to exploit it?

In online games, the impact of a minor bug will be greatly enhanced if large
numbers of users are motivated to exploit it. An example: in Eve Online
several years ago, certain operations involving items could cause large server
overhead. This wasn't seen as a big issue, because those operations weren't
_that_ frequent. Unfortunately, these operations were also virtually free, so
the losing side in a big fleet battle would sometimes use this to cause a
server crash, often negating their loss. The result: lots of crashes during
big fleet battles, and lots of unhappy paying customers.

Perhaps the right solution to a corner case is to make sure the economics
don't encourage exploitation.

------
mrcharles
This article has a lot of applications that are in different scope. For
example, it's applicable to game design as well.

~~~
stcredzero
See my comment responding to the "premature optimization" observation.

------
ticktock
Mr Blank must have gotten confused and deleted my comment asking him to delete
his post.

