Hacker News Reader

Comment by edgyquant | Hacker News Reader

Seems like it has to do with the word failure more than anything. It is a failure, every time you don’t ship a perfect product it’s a failure of some kind. The iteration process is simply removing failures from a product until you reach feature completeness. I don’t think the difference is that large between a failure and a mistake.

View on HN

I don't believe that a prior thing which lacks a new advancement means the prior was a mistake or a failure. We're a creative species that strives for improvement. The first running shoe wasn't a mistake nor was it a failure. But the ones I use to run 40 years later sure have improvements.

That’s why I don’t think failure is a good word. But what’s a word to say, “it works but it could be better,” other than failure?

Even if did ship a perfect product, it wouldn’t stay perfect because the world changes.

Which is why I think it is bad semantics to say changing an API is an indication of failure.

> It is a failure, every time you don’t ship a perfect product it’s a failure of some kind.

It's impossible to ship a perfect product. So perhaps we shouldn't use "failure" to denote not doing the impossible, and reserve it for cases where "success" is even possible.

It's possible to ship a product that doesn't break though.

You can add new APIs, etc, instead of breaking existing ones. Anytime you do a major rev because your changing an API or removing one, you could also ship new APIs instead and keep the major version the same.

This thread has made me appreciate the Star Trek Kobayashi Maru exercise in new ways. People _really_ don't like being told that they've failed.

Perhaps the approach of vapid, pessimistic short-takes doesn't play well outside of Twitter, where folks aren't as impressed by blue checks and large followings, and where there isn't a benefit to jockeying for engagement. Based on your comments throughout the threads here, you appear to be overly eager to paint with an overly negative, wide brush that ignores nuance and the multitudes of situations in which your assertion doesn't come close to being true. For instance, adopting an upstream dependency change containing a breaking change, which necessitates releasing a major version in which no notion of failure, mistake, or misstep exists. I'm unsure how you gained such a large following, but your comments aren't at all inspiring or insightful - only somewhat controversial.

This is definitely true for library code. I don't think the idea holds up for squishier things- moving from version 1.x to 2.x could make the user experience worse, depending on what you prioritize and who's making decisions.

Reply on news.ycombinator.com