The Rise of Worse is Better(dreamsongs.com)
dreamsongs.com
The Rise of Worse is Better
http://www.dreamsongs.com/RiseOfWorseIsBetter.html
23 comments
For anyone who isn't aware, this essay was also written by Richard P. Gabriel under a pseudonym as a rebuttal to his earlier worse is better paper.
On http://www.dreamsongs.com/WorseIsBetter.html Gabriel talks about the difficulty he had in deciding whether worse really is better and that he wrote various documents taking opposing positions
But is worse really better?
http://dreamsongs.com/Files/IsWorseReallyBetter.pdf
http://dreamsongs.com/Files/IsWorseReallyBetter.pdf
done is best
The use of the word 'worse' is misleading. The article wanders. I do not feel it is worthwhile.
I find the worse entirely accurate.
This is a classic piece of programmer lore that goes a long way to describing why the software industry is the way it is today i.e. why everything sucks so much. My only criticism I have of it is that he mischaracterizes the-right-thing as being monolithically designed and slow performing (towards the end of the page). The-right-thing to me is always functionally and computationally superior, it just takes longer to make.
This is a classic piece of programmer lore that goes a long way to describing why the software industry is the way it is today i.e. why everything sucks so much. My only criticism I have of it is that he mischaracterizes the-right-thing as being monolithically designed and slow performing (towards the end of the page). The-right-thing to me is always functionally and computationally superior, it just takes longer to make.
I've never been able to make sense of the article either, and I've tried many times. I think it boils down to its title, which is just the right mix of vague and catchy to be optimal for getting repeated. The article itself is merely the title's host organism.
The <article|movie|book> itself is merely the title's host organism.
It's a classic and iconic piece of computer literature -- it even provided a common phrase used describe certain methodologies ("worse is better").
Not to mention it's quite short and to the point, this is not some academic or over-indulgent blah-blah.
As for the use of the word "worse" it makes perfect sense, and the context is very easy to pick up.
I can't even fathom how one could say it "wanders".
Not to mention it's quite short and to the point, this is not some academic or over-indulgent blah-blah.
As for the use of the word "worse" it makes perfect sense, and the context is very easy to pick up.
I can't even fathom how one could say it "wanders".
I suspect the essay itself might be an example of worse-is-better principle applied in practice. :)
My first impression was that author basically recommends quickly releasing ‘minimal viable products’ and expands on what should be considered ‘minimally viable’ for some specific kinds of software.
‘Worse is better’ is an interesting way to put it, though. I think it can be applied widely.
One way to avoid perfectionism is to constantly remind ourselves what's important, what's in MVP. Sure, there are a lot of things that are important for good product, but some are more important and we should focus on them first.
On the other hand, we can just remember that ‘worse is better’. No need to make yourself focus on what's important—it will come naturally once you label everything else ‘worse’.
It's hard to explain and I may have missed author's point, but that was one of takeaways for me.
My first impression was that author basically recommends quickly releasing ‘minimal viable products’ and expands on what should be considered ‘minimally viable’ for some specific kinds of software.
‘Worse is better’ is an interesting way to put it, though. I think it can be applied widely.
One way to avoid perfectionism is to constantly remind ourselves what's important, what's in MVP. Sure, there are a lot of things that are important for good product, but some are more important and we should focus on them first.
On the other hand, we can just remember that ‘worse is better’. No need to make yourself focus on what's important—it will come naturally once you label everything else ‘worse’.
It's hard to explain and I may have missed author's point, but that was one of takeaways for me.
The word "worse" might be worse than some other term Gabriel could have picked. But this article (written in 1989) was really pretty influential at the time, and cemented the phrase "worse is better" in a lot of peoples' minds.
The article even has its own Wikipedia page. Apart from whatever merits it might or might not have in itself, I think it's a worthwhile read because it made an impression on a lot of people back in 1989. It's one of the first explicit attempts to discuss the "Unix philosophy."
The article even has its own Wikipedia page. Apart from whatever merits it might or might not have in itself, I think it's a worthwhile read because it made an impression on a lot of people back in 1989. It's one of the first explicit attempts to discuss the "Unix philosophy."
JavaScript is classic worse-is-better.
JavaScript is what makes me think that worse isn't better, it's just that worse is easier and immediate. "Worse" things happen sooner and with more frequency, so that means a greater chance that a worse thing will stumble upon what's actually most important.
Turns out that brain dead code distribution was the most important thing. Similarly, brain dead web app deployment is what makes PHP so popular. Seems that when the web was born, "is available in some browsers" was better than "soon to be available in some browsers" and so JavaScript took off like a rocket. JavaScript doesn't get code distribution anywhere close to "the right thing", but it does it and it's ubiquitous, which is what's important if you want to reach people. After that, it's just a virtuous/vicious cycle.
Turns out that brain dead code distribution was the most important thing. Similarly, brain dead web app deployment is what makes PHP so popular. Seems that when the web was born, "is available in some browsers" was better than "soon to be available in some browsers" and so JavaScript took off like a rocket. JavaScript doesn't get code distribution anywhere close to "the right thing", but it does it and it's ubiquitous, which is what's important if you want to reach people. After that, it's just a virtuous/vicious cycle.
I think the point of "worse is better" is that "easier and immediate" is better.
JS is worse than what? why?
JS is worse than a competently designed and implemented language.
This is because it was not competently designed and implemented.
This is because it was not competently designed and implemented.
[deleted]
It's interesting that in the development of a single project, in the prototyping phase it really is better to just get something done, even if it's crappy. But as you go on, you want to pay off the technical debt, clean things up, and finish with a polished product. Which philosophy is better is a function of what phase of the project you're at.
It's possible, and I'm hoping it's true, that "worse is better" is a property of the current phase of growth of the computer industry, not a general principle of software. I'm hoping we can reach the finished product stage in my lifetime.
It's possible, and I'm hoping it's true, that "worse is better" is a property of the current phase of growth of the computer industry, not a general principle of software. I'm hoping we can reach the finished product stage in my lifetime.
The author points out that "worse" opposed to "the right thing" is better in terms of life expectancy. As being simpler, "worse" has better survival characteristics to evolve toward something satisfying (opposed to the extreme difficulty to figure out the right thing from the first attempt).
This is totally similar to the lean startup methodology in use today. Making something "worse" reduce the length of the feedback loop, allowing more flexibility, thus being better positioned to survive.
Javascript is a good example as the REPL (read eval print loop) allow beginners to start and see results right away which is very encouraging and easier to assimilate.
This is totally similar to the lean startup methodology in use today. Making something "worse" reduce the length of the feedback loop, allowing more flexibility, thus being better positioned to survive.
Javascript is a good example as the REPL (read eval print loop) allow beginners to start and see results right away which is very encouraging and easier to assimilate.
Or the attributes that define whether something is good or not are not the same as they used to be.
Atwood has some of the best worse-is-better essays I've ever read, some dating back a decade: http://www.codinghorror.com/blog/2004/08/worse-is-better.htm... It's peppered throughout his writing, and he really gets it.
http://www.dreamsongs.com/Files/worse-is-worse.pdf