

Settling for mediocrity - why releasing software is all about compromises - dools
http://www.workingsoftware.com.au/page/Settling_for_mediocrity

======
antirez
The concept exposed in this article is a very important one, and one that is
affecting in very bad ways our industry.

I agree that many developers are perfectionists, and this affects very badly
their work in many forms: over engineering, as many times to gain the last
feature instead to find a compromise you are forced to add a lot more
complexity. Not releasing at all, as some time you'll end in an infinite loop
and the code is never good enough. Users less happy, as if you release with
the precisionist state of mind you'll hardly be able to release often. And so
forth.

It seems so obvious that software is a matter of approximation, and still so
hard to apply it in practice apparently. Maybe a big role in this matter is
played by feeling not well with the idea that others will look at your not
perfect code? Possible, even if many times I think it's much more a matter of
mindset.

~~~
powdahound
Well said. Reminds me of the "1.0 Is the Loneliest Number" [1] post by Matt
Mullenweg. A balanced mix of compromise, iteration, and vision is a healthy
thing to strive for.

By the way, we use and love Redis. :)

1\. <http://ma.tt/2010/11/one-point-oh/>

------
powdahound
Garret from HipChat here. The way we decided on AIR is close to what you
guessed but we had one major requirement: the app can not suck. That means it
can't feel like a wrapped up web app, it can't use unnecessary CPU and memory,
and it must be pleasant to use.

It's true that lots of AIR apps are nasty, and that's why it gets a bad name.
We agreed that we'd only use AIR if we could make the app beautiful and fast
through our hard work, and we were able to do that (go try it and see). As a
result we've saved a lot of time, only have to write features once, and have a
consistent user experience between all users. Even Alex himself enjoyed it and
provided some feedback: <http://twitter.com/#!/al3x/status/25370589657042945>.
Note that the feedback is mostly minor improvements, not "wow this app is
gross". Of course, if you want to hate something you'll find a way -
<http://bit.ly/eCRyMc>.

"Settling for mediocrity" is not a great way to describe us, however. Mediocre
is defined as "not very good" which is how we view the current state of group
chat services. Deciding to use a self-hosted IRC or Jabber server is settling
for mediocrity (feature comparison: <http://www.hipchat.com/compare>).

Bottom line: we're building a tool that is a joy to use and allows teams to
get more work done.

And don't settle for mediocrity, just work smart.

~~~
dools
Hmm didn't mean to "tar you with the mediocre brush" there. I just wanted to
illustrate that whatever you need to do to get a product to market is fine so
long as people use and enjoy it.

I've removed the bits from the article specifically referring to "too much
cpu/memory" as that's not really the original point of Alex's post anyway and
I can see how that directly implicates a problem in your software which I have
_no_ evidence of.

EDIT: oops! s/have evidence/have no evidence/

~~~
powdahound
No worries. Totally agree with your message, just don't think "mediocre" is
the right word for it. Every decision in a company is about compromise. If you
can't compromise intelligently you're screwed.

------
lazylland
tl:dr; settle for "selective brilliance"

~~~
stcredzero
Right. It's not so much "settling for mediocrity" but more awareness of where
your fulcrum is and exerting your force to utilize it to best advantage.

There's another analogy in battlefield tactics. Many times, a brilliant
general will create a tactical advantage which brings them victory by opening
up a tremendous vulnerability in another area.

Another analogy from rock climbing: sometimes you can put yourself briefly in
an untenable position to gain a better position right after.

