Worse is Better(dreamsongs.com)

26 pointsby snth16 anni fa3 comments

http://www.dreamsongs.com/WorseIsBetter.html

3 comments

jpren16 anni fa

IMO, the "worse-is-better" approach is especially applicable to startups in the sense that during its first few iterations, you (the founders) don't know exactly what-to-build. Hence, the definition of "completeness" in the scope of your product is fuzzy at best.

Once the idea of "completeness" is crystallized (based on listening to what people want), I think that's when it's a good idea to build it right.

By "building it right", I don't mean to pay the same amount of attention to all features for the sake of completeness. Here, I'm a proponent of the 80/20 rule. Specifically, that the important 80% of the features be implemented first. That doesn't mean ignoring the remaining 20%, just that the rest of it will need to be hashed out later/eventually. An 80% product is enough for a demo/risk-loving early adopters, but ultimately customers want to pay for 90%-100% products.

billswift16 anni fa

I have read several different takes on "Worse Is Better" on the Web, as well as Gabriel's book, Patterns of Software, and generally think it is a good way of developing useful software. It is too bad though that he didn't give it another name; the bad part about the phrase is how lazy or careless programmers use it to excuse their laziness and carelessness.

raganwald16 anni fa

I empathize with your sentiment, however optimizing an idea around trying to prevent lazy or careless programmers from using it to rationalize their laziness and carelessness is futile.

For example: Agile (We don't need no stinkin' thinking up front), BDUF (We don't need no stinkin' thinking as we go along), Static Typing (We don't need no stinkin' unit tests), Unit Tests (We don't need no stinkin' static typing) and so on.