Killing Innovation with Corner Cases and Consensus | Hacker News Reader

Killing Innovation with Corner Cases and Consensus

steveblank.com

25 pointsterpua8 comments

"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.

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.

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

steve

Sure sounds a lot like premature optimization.

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.

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

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

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

Reply on news.ycombinator.com