[转] Strategy: Solve Only 80 Percent of the Problem
2009-09-01 11:02
357 查看
Strategy: Solve Only 80 Percent of the Problem
Fri, 08/28/2009 - 16:04 — Todd Hoff
Strategy: Solve Only 80 Percent of the Problem (301)
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.
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.
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
Fri, 08/28/2009 - 16:04 — Todd Hoff
Strategy: Solve Only 80 Percent of the Problem (301)
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. GabrielLisp: 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
相关文章推荐
- chrome视频无法播放的解决方法(Solve the problem of Google player cannot be played normally)
- How to solve the issue of RSARTE's starting problem
- What are some of the differences between using recursion to solve a problem versus using iteration?
- 解决线性规划的工具(the tool of solving linear programming problem):lp-solve
- solve the problem of 'java web project cannot display verification code'
- ubuntu source for caffe reference to solve the problem of the LIB
- method to solve the problem : Could not cast value of type 'NSManagedObject_ to
- Jaw Crusher to solve the problem of cement production
- Q.3.4 To solve the problem of hanoi
- How to solve the problem "A project with an Output Type of Class Library cannot be started directly "
- Solve the problem of "Java: illegal start of expression"
- TFS2010-Closed the problem of Installing tfs> configured >review > [sharepoint] display [failed]
- the problem of overfitting
- ZOJ Problem Set - 3880||Demacia of the Ancients
- 关于问题The fully qualified name of the bean's class, except if it serves only as a parent definition fo
- 关于问题The fully qualified name of the bean's class, except if it serves only as a parent definition fo
- NotImplementedError: Only the following pseudo-classes are implemented: nth-of-type.
- Error:A problem was found with the configuration of task ':app:packageRelease'. > File 'F:\AndroidSt
- 7 - 1 - The Problem of Overfitting (10 min)
- poj 3100 Root of the Problem