« Squarespace Architecture - A Grid Handles Hundreds of Millions of Requests a Month | Main | Hot Links for 2009-8-26 »

Strategy: Solve Only 80 Percent of the Problem

Solve only 80% of a problem. That's usually good enough and you'll not only get done faster, you'll actually have a chance of getting done at all.

This strategy is given by Amix in HOW TWITTER (AND FACEBOOK) SOLVE PROBLEMS PARTIALLY. The idea is solving 100% of a complex problem can be so hard and so expensive that you'll end up wasting all your bullets on a problem that could have been satisfactoraly solved in a much simpler way.

The example given is for Twitter's real-time search. Real-time search almost by definition is focussed on recent events. So in the design should you be able to search historically back from the beginning of time or should you just be able to search for recent time periods? A complete historical search is the 100% solution. The recent data only search is the 80% solution. Which should you choose?

The 100% solution is dramatically more difficult to solve. It requires searching disk in real-time which is a killer. So it makes more sense to work on the 80% problem because it will satisfy most of your users and is much more doable.

By reducing the amount of data you need to search it's possible to make some simplifying design choices, like using fixed sized buffers that reside completely in memory. With that architecture your streaming searches can be blisteringly fast while returning the most relevant data. Users are happy and you are happy.

It's not a 100% solution, but it's a good enough solution that works. Sometimes as programmers we are blinded by the glory of the challenge of solving the 100% solution when there's a more reasonable, rational alternative that's almost as good. Something to keep in mind when you are wondering how you'll possibly get it all done. Don't even try.

Amix has a very good discussion of Twitter and this strategy on his blog.

Worse is Better

A Hacker News post discussing this article brought up that this strategy is the same as Richard Gabriel's famous Worse-is-Better paradox which holds: The right thing is frequently a monolithic piece of software, but for no reason other than that the right thing is often designed monolithically. That is, this characteristic is a happenstance. The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.

Unix, C, C++, Twitter and almost every product that has experienced wide adoption has followed this philosophy.

Worse-is-Better solutions have the following characteristics:

  • Simplicity - The design must be simple, both in implementation and interface. It is more important for the implementation to be simpler than the interface. Simplicity is the most important consideration in a design.
  • Correctness - The design must be correct in all observable aspects. It is slightly better to be simple than correct.
  • Consistency - The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
  • Completeness - The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

    In my gut I think Worse-is-Better is different than "Solve Only 80 Percent of the Problem" primarily because Worse-is-Better is more about product adoption curves and 80% is more a design heuristic. After some cogitating this seems a false distinction so I have to concluded I'm wrong and have added Worse-is-Better to this post.

    Related Articles

  • Worse Is Better Richard P. Gabriel
  • Lisp: Good News, Bad News, How to Win Big
  • Interesting Hacker News Thread
  • In Praise of Evolvable Systems by Clay Shirky
  • Big Ball of Mud by Brian Foote and Joseph Yoder
  • Reader Comments (8)

    It's funny that you use the Twitter example for this, because Twitter's search frustrates the hell out of me.

    When I'm searching for posts from a certain person about a certain thing, it's usually because that thing is buried so far down in their timeline that I don't want to have page through 100 pages just to find it. But the search is useless to me because it only seems to go back about 3-4 days.

    November 29, 1990 | Unregistered CommenterScott

    KISS - Keep it simple stupid. 'Nough said.

    November 29, 1990 | Unregistered CommenterAnonymous

    Scott, you're absolutely right. That's the hot point.
    The clever point is to give the user the option to select this 80% by his own. Let's say something like "give me the period" and/or force him to use your keys.

    November 29, 1990 | Unregistered CommenterStelios

    I think that's a good point. 80% solution is probably good enough in most cases. It's faster, easier and seems to be a good alternative. Also it's better to actually get things done than not getting them at all.

    A statement like "consistency of interface" is highly controversial. But I agree with 'worse is better'! Consistency and completeness are the holy grail for most enterprise architects and SOA fans. Especially SOA is solled as Complete (everything is a service), Consistent (one way for all software) and Correct because the use of contracts, standards and common data models. Simplicity, on the other hand, is not a goal of SOA. People hope simplicity will follow by striving for SOA's completeness, correctness and consistency, but it won't work. The other three will (almost) always decrease simplicity and a the new SOA systems will start to feel like legacy pretty quickly.

    Intentionally simple design often means robust software, which is far more likely to have long life than systems that try to be consistent and correct.

    November 29, 1990 | Unregistered CommenterMachiel Groeneveld

    I always heard this as, "The perfect is the enemy of the good." With four kids around the house, "perfect" is a luxury we gave up some time ago. :7)

    November 29, 1990 | Unregistered CommenterWill E.

    Don't use any numbers. You can call it: "good enougth".
    It's all about reaching the new goal and not stop on the way to the old target.

    November 29, 1990 | Unregistered CommenterMichael Mosmann

    It's all about reaching a new goal. Don't get confused with stopping half way to your old target.

    November 29, 1990 | Unregistered CommenterMichael Mosmann

    PostPost a New Comment

    Enter your information below to add a new comment.
    Author Email (optional):
    Author URL (optional):
    Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>