Comments on: Why 90% solutions may beat 100% solutions http://www.johndcook.com/blog/2008/11/07/why-90-solutions-may-beat-100-solutions/ The blog of John D. Cook Sat, 31 Jul 2010 07:45:27 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: CogitoErgoCogitoSum http://www.johndcook.com/blog/2008/11/07/why-90-solutions-may-beat-100-solutions/comment-page-1/#comment-36449 CogitoErgoCogitoSum Thu, 15 Apr 2010 22:41:09 +0000 http://www.johndcook.com/blog/?p=809#comment-36449 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. 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 http://www.johndcook.com/blog/2008/11/07/why-90-solutions-may-beat-100-solutions/comment-page-1/#comment-14635 Derek Ditch Tue, 17 Mar 2009 13:21:37 +0000 http://www.johndcook.com/blog/?p=809#comment-14635 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 <em>my</em> library X is going to do everything that you want to do in <em>your</em> 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. 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 http://www.johndcook.com/blog/2008/11/07/why-90-solutions-may-beat-100-solutions/comment-page-1/#comment-9142 Kevin McCarty Fri, 07 Nov 2008 21:13:58 +0000 http://www.johndcook.com/blog/?p=809#comment-9142 "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. “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.

]]>