

Ask HN: Good enough vs excellence -- which do you favor? - rmah

Simple enough question: would you rather work at a company that:<p>A) settles for "good enough" with rapid iteration, or<p>B) one that demands excellence but takes longer to for each iteration?<p>I favor B... but it seems that A is gaining strength these days.  It's a worrisome trend to my eyes.
======
byoung2
A is the route Google takes (e.g. there have been 6 updates to Android since
Feb 2009, with a 7th due out in a few months, but still not matching the
polish of iPhone OS).

Apple does B (e.g. one major update to iOS each year, even if it means
trailing the industry with features like copy/paste, multitasking, video chat
until they can do them the pretty "Apple way").

Microsoft these days seems to have found a choice C, which is longer and
longer iterations and settling for good enough or worse. Just look at the
following release dates for Windows Mobile and you can see longer intervals
for smaller improvements:

    
    
      5.0 5/2005
      6.0 2/2007
      6.1 4/2008
      6.5 5/2009
      6.5.3 2/2010
    

I personally would rather work for Google, so my answer is A. Rapid iteration
gives you the satisfaction of seeing something you worked on "go live" vs
seeing it die on the operating table after years of work and knowing you'll
likely see Halley's comet before another project goes live.

~~~
astrofinch
It's amazing that the tech industry's three giants all do things totally
differently and all make tons of cash.

~~~
grinich
It's likewise fascinating how different devices handle simple tasks in vastly
different ways. Just look at GPS navigation systems for cars.

------
rbrcurtis
I favor the company that chooses the option that is right for the circumstance
and for their customers (internal or external), not the one that chooses A or
B dogmatically.

------
astrofinch
Obviously, the right choice depends on the situation. Companies should tend
towards B if they already understand the needs of their customers or if
they're in a slow-moving market where customers make big, infrequent
purchases.

Probably it would be more useful if you described a few specific companies
that you think release products too frequently. Then we could argue if they
would benefit by releasing less frequently.

Keep in mind that the question of how companies should act to profit-maximize
is totally separate from the question of what sort of company you want to work
for. I'm only interested in the first one; you might not be interested in it
at all.

------
BrianHV
The way you phrase your question is somewhat prejudicial. No one wants to
claim that they'll "settle." However, everyone has some threshold of "good
enough" for release. Even your option B alludes to that; if you're iterating,
it means that there's something that can be improved after release.

The real question is at what point will releasing produce the most value for
you and your customers. For some circumstances, that point might be very early
with very little polish. In others, it doesn't make sense to release publicly
until you've ironed most of the kinks out.

------
todayiamme
I doubt that there is any one answer to a question like this.

What field are you talking about? If it is a performance critical application
like code for hospitals or intelligent life support systems/medical devices
then certainly one would go for B.

On the other hand if you're designing a UI then there is no one way to do it.
It's true that Apple releases only one update in a long time but they make
hundreds of prototypes and test them out like anything (see:
[http://developer.apple.com/mac/library/documentation/UserExp...](http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html)).
So they do a clever combination of A+B, while maintaining their image.

However, if you're small then you can't afford to hire professional testers to
test everything, or do videotaped randomized trials with volunteers who have
signed a NDA. So, then a release often and correct often strategy would work
well for you.

The question should be; How should I decide which one is better for me? A, B
or A+B in some permutation?

[note: I am assuming that B in its pure form means micro-managed code that is
proactively developed to be perfect from the start based on some previous
parameters.]

------
Sam_Odio
Excellence in one thing. Good enough in everything else.

~~~
rmah
Concise, cogent, illuminating and thought provoking. Bravo.

~~~
zackattack
This is also known as t-shaped competence and is common in firms like IDEO.

------
NeilCJames
It is more of a continuum than an A or B question, and it would be a bad idea
to get religious over the question. From a pragmatic perspective, B should be
favored when either production constraints (capital investment, etc) or
distribution costs are tangible at the margin. So durable goods and long-term
services (e.g. insurance) should lean toward B. A is favored if and only if
iterative cycles can be accomplished without additional capital investment and
distribution costs are near-zero. So, basically anything that could be
delivered digitally that is not embedded in a durable good should be released
when "good enough" (and then only improved if the iteration creates more value
than the development of a new good or provision of a new service--iteration as
rent-seeking is wealth-destructive).

------
edw519
Illogical question. The entire point of "good enough" is that it _is_
excellent.

Each iteration of the project has to be good enough. All you need to be
excellent is enough iterations.

Perhaps a better question would be, "Which do you favor, many 'good enough'
iterations or one shot at perfection?" The answer to this question is
obviously the former because the latter almost never gets done.

~~~
astrofinch
There are a lot of similar questions that are interesting.

For example, let's say that all product development activity falls in to one
of three categories: "concept", where you're collecting ideas and talking to
customers, "prototype", where you do your heavy lifting, and "polish", where
you refine your product's performance/UI.

You aren't going to be able to control the amount of "prototype" you have to
do to achieve a given product state. But you can control how much "concept"
and "polish" you'll throw in with it. If you estimate that it will take you
two months working alone to produce a prototype that will interest customers,
what is the right amount of time to talk to customers before you write your
first line of code? I'd say a few days--in my view, startups should do this
early on, instead of jumping in right away.

As for the "ideas" part of "concept"--I've been surprised how easy it is for
me to turn on ideas like a tap. The insight that made me completely rethink
what I'm working on now came to me late at night when I had forced myself off
the computer because I wanted to start getting to bed earlier. But even if you
can't turn on ideas like a tap, how much time should you spend recording the
ideas that do come up and doing research on the internet? My guess--quite a
bit, but it'd be even better if you could outsource this work to a
nontechnical cofounder. (Too bad I haven't been able to find anyone who meets
my standards for this and wants to work with me on the product I'm building.)

The amount of "polish" you should do before serious PR efforts is extremely
situation-dependent.

\- If you're entering an established market with a bunch of small innovations
over your competition (Quora), you should do a lot of polish so your product
will genuinely be the best thing out there (and they did).

\- If you're doing something totally new, a moderate amount of polish is
probably better--just enough to avoid acquiring a bad reputation.

\- If your customers are going to be spending significant cash with you,
polish is key so you seem (and actually are) trustworthy.

"The answer to this question is obviously the former because the latter almost
never gets done."

If you know you're likely to irrationally give up on a product idea because
your morale is low or irrationally continue with a product idea regardless of
whether customers say it'll be useless, obviously those are factors to take in
to account.

Personally, I wouldn't be afraid to, say, spend a long time building a better
version of Ebay without doing any releases if I was convinced that people
would switch to my site if and only if it was a significant improvement. If my
intuition changed partway through the development process (without any solid
external evidence or new observations--just a change in my gut feeling) then I
would say "well, my intuition now isn't much better informed than my intuition
at the beginning of the project--they're equally valid intuitions" and operate
as if the average of my two intuitions were true (say, wrap up what I've got
so far and make a solid effort at releasing it. Or start working half time and
spend the other half of my time plowing onward with my project.)

------
biotech
When programming life support software for spacecrafts, A and B converge.
Nothing less than excellent is good enough. I know there are other industies
like this too, where 'release early and often' can result in death or some
other disaster.

------
mailarchis
It depends. You cannot have a "good enough" with rapid iterations approach for
a mission critical project. e.g. A software to control chemotherapy or a
missile controller program

However for consumer facing products or in some cases for enterprise products,
you can start with a minimal working version and then improvise.

Personally, i prefer A because the real feedback comes in from your consumers
and you will find lot of your assumptions going wrong

------
bbzeven
Good enough is never good enough. It leaves lots of room for mistakes and at
that point "good enough" becomes "oops." Not worth the rapid iteration if
there is room for it to come crashing down...

------
unavailable
A. Because existing good enough is better than non-existent excellence. And it
can be polished forever.

------
mkramlich
C) it depends. each is the smarter choice in different situations.

------
Charuru
I don't know who would prefer good enough, but the realities of the market and
life in general forces you into it.

Even companies which we associate with excellence end up shipping less than
ideal products with crucial things MIA, e.g. copy+paste, multitasking.

But in the end those things didn't matter so much, did they.

------
TotlolRon
B

 _Do your best to draw it straight. Slanted it will come out anyway._ \-- Mr.
Someone, 2010

------
zackattack
How do you know what is important enough to make excellent without trying lots
of good enoughs?

