Strategy: Solve Only 80 Percent of the Problem
Friday, August 28, 2009 at 2:04AM 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:
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.
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.
KISS - Keep it simple stupid. 'Nough said.
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.
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.
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)
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.
It's all about reaching a new goal. Don't get confused with stopping half way to your old target.