Comments on: Why 90% solutions may beat 100% solutions

By: Slobodan Blazeski

Slobodan Blazeski — Thu, 22 Dec 2011 18:26:34 +0000

Sounds like worse is better by Richard Gabriel http://www.dreamsongs.com/WorseIsBetter.html

By: human mathematics

human mathematics — Thu, 10 Nov 2011 02:36:18 +0000

Even though Rails has more hype, I’ve heard Sinatra is easier.

By: Jon Peltier

Jon Peltier — Wed, 02 Nov 2011 15:06:46 +0000

When you release a 90% solution, user feedback will steer you toward the additional 1% that’s worth spending effort on. So your 90% solution at 10% of the effort becomes a 91% solution at maybe 15% of the effort. Not so bad.

By: John

John — Wed, 02 Nov 2011 13:11:19 +0000

Some problems can be addressed at an 80% level and some cannot. It’s not enough for my keyboard to have 80% of the keys.

In Olin Shivers’ example, he’s discovered something where someone else cannot implement the extra 20% he needs because the infrastructure isn’t there. Something foundational is missing. So you could argue the wrong 20% was left out.

It’s better to think in terms of users rather than features. Instead of saying you’re going to include 80% of your original feature list, which may or may not make anyone happy, you could aim to please 80% of the public. (Or 2% of the public, if that’s a big enough market for you.)

By: Roshan Mathews

Roshan Mathews — Wed, 02 Nov 2011 12:08:44 +0000

What do you think of Olin Shiver's take on this?

By: CogitoErgoCogitoSum

CogitoErgoCogitoSum — Thu, 15 Apr 2010 22:41:09 +0000

This doesnt just apply to coding at all. Its a fair thing to say about any industry or any social problem. Wherever there is an issue or a problem that needs resolution. It makes sense to worry more about the bulk that concern all than to worry about the minutia that concerns only a few. Something about efficiency, work, cost. Im reminded of the 80-20 Rule as a matter of fact.

By: Derek Ditch

Derek Ditch — Tue, 17 Mar 2009 13:21:37 +0000

Really, the same design philosophy should apply to the design all libraries in any language, except those designed for a particular project. There is no way that my library X is going to do everything that you want to do in your project. The idea is to abstract out the stuff that is useful in more than one project and set an API for that. The advantage to languages like Ruby (and Python, which I prefer) is that you can change the API at runtime to be what you need. When using these dynamic languages, it is useful to have more elaborate libraries which can be easily molded into what you need.

I think the trap that library designers fall into is feature creep. They try to solve all of the world’s problems in one package. Be more like UNIX tools. Small tools for specific tasks. Glue them together and you have a larger project solution.

By: Kevin McCarty

Kevin McCarty — Fri, 07 Nov 2008 21:13:58 +0000

“At first it sounds unprofessional to develop a software library does anything less than a thorough solution to the problem it addresses”

The iconic counterexamples include:

* C
* Unix
* the Internet

They are all incomplete, but they worked well enough that, in their time, adoption was almost universal, because they were so darn powerful in spite of their shortcomings.