5 ms·

Settling for mediocrity - why releasing software is all about compromises

25 points by dools 16y ago

antirez 16y ago
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 16y ago
  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/ http://ma.tt/2010/11/one-point-oh/
lazylland 16y ago
tl:dr; settle for "selective brilliance"
- stcredzero 16y ago
  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.
powdahound 16y ago
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 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 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 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 16y ago
  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 16y ago
    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.

25 points by dools 16y ago

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 16y ago
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/ http://ma.tt/2010/11/one-point-oh/

lazylland 16y ago

tl:dr; settle for "selective brilliance"

stcredzero 16y ago
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.

powdahound 16y ago

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 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 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 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 16y ago
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 16y ago
  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.