Hacker News Reader

Comment by haberman | Hacker News Reader

There are way too many dichotomies that are getting muddled in this discussion:

  - hacky vs. beautiful
  - professional vs. amateur
  - waterfall-designed vs. evolving
  - centralized control vs. consensus control
  - crufty vs. well-maintained
  - open-source vs. closed-source

With so many axes to argue about, we can project whatever we are feeling about software today onto this "cathedral/bazaar" debate. We may think we are having one discussion, but we're actually having six discussions (or more) at the same time.

View on HN

Hacky vs beautiful is diferent from The Right Thing vs. Worse is Better.

Worse is Better is a very specific philosophy (at least, as it is described in Lisp: The Good News, The Bad News, And How to Win Big)

The Right Thing philsophy is, in essence, that simplicity of interface is the most important thing: every interface is an abstraction, abstractions shouldn't leak. Have a simple interface, be correct, be consistant, be complete. If the implementation is complex, so be it.

By contrast, the worse is better philosophy prioritizes simplicity of implementation: Be simple, be as complete, correct, and consistant as possible, but between having a simple design, and being slightly wrong, a little inconsistant, and not as complete, and having a complex design that is all of those things, take simplicity: 90% now is better than 100% never.

Over time, Unix has adoped some Right Thing ideas (plan9 took this to 11), and Lisp has adopted some New Jerseyisms (Scheme's dynamic-wind is definitely this).

You are right. I wrote that too quickly before thinking about it. I removed that part of the post.

You are far from the first person to misunderstand/misrepresent worse is better. The best part is when people recommend reading the essay, and then demonstrate they they don't know what it meant: It's not about the battle between simplicity and complexity, it's about the battle between simplicity of interface and the simplicity of implementation.

I definitely understood the distinction when I previously read the article. I just didn't reload enough of it into mental cache to remember.

I get it.

I like your breakdown of the essay into those six. A person or group studying this stuff should do a survey of various projects where those traits are clear. Then, assess what metrics of success resulted to see if there's any provable patterns.

Reply on news.ycombinator.com