That's pretty interesting - I'm fairly new to programming but now believe that at least 50% of my time is spent dealing with fringe cases (accounting for a small percent - a low traffic foreign language, odd xml validation problems, etc).
The protestant work ethic would suggest you haven't finished your job until you've covered that last percent.
The flipside to that is you can improve user experience for most of your users most of the time with a fraction of the work.
So given a finite amount of resources, what's better?
That depends on how important the project is. It would be worth it for Google to have someone optimize add-words for a full year even if they only got an extra click per 1/50,000 page views. However, that much attention to detail is useless when you have far fewer users / revenue. The secret is to focus on the highest reward areas and shift focus when other things become more important.
Or unless those "other things" have unlikely but potentially really bad consequences.
Most of the time, maybe 80% of the time avionics software does not need to contend with the plane flying through a thunderstorm. But I hope that the programmers didn't just toss that possibility into the "not important" category.
The "80/20" rule is something MBA types like to toss out so that they sound wise, but in some cases it's needs to be more like the 99.80/00.20 rule.
When working with code that's effort has lives on the line, the rules obviously change entirely. How many people ACTUALLY work on such systems though? For the majority the 80/20 rule is going to be fairly legit a large portion of the time.
If the "80" here is reasonably accurate, then here is what we have: in 80% of the cases, we only have to focus on 80% of stuff (that's about 64% of the total), and in the rest 20% we focus almost on 100% of stuff (that's almost 20% of the total), which means that we need to focus on almost 64+20=84% of the total, which is still pretty close to the original 80%. :-) OK, this is silly. (We can only get it equal when we go with 100% instead of 80%.)
At work, we are following this rule for a feature. We have to maintain compatibly for this feature in the next release while working on the functionality that interacts with it.
We don't know how many if any customers actually use it, but if we broke it, someone would complain.
We think we have all the cases covered and that it won't break, but it isn't polished the way it should be. The error messages aren't as great as they could be. But it works. If we have time later, we may come back to it. If a customer files a bug, we will address it then. In a year, it might even be pulled from the product.
That is confusing work ethics with implementation strategy.
One could argue that it is more ethical -- your duty to your investors, employees, employers, customers, etc. -- to focus on a more practical solution ("80%") than to seek perfection to satisfy your own personal standards. But if your responsibility (whatever it may be) dictates near perfection, then clearly that is what needs to be done. (Ex: 80% safe mass transportation system?)
The main decision criteria are likelihood and recoverability. If the error isn't recoverable (maybe it leads to data corruption, say), then you generally have to really batten down all your hatches and fix and/or test everything you can, even if it doubles or triples the overall effort. Generally, if you're shipping the software instead of doing SaaS stuff, fewer things are "recoverable" than if you control everything yourself and can quickly patch things (either patch the code or patch the data) to work around edge cases that come up infrequently. Non-recoverable edge conditions generally need to get fixed regardless of their likelihood; as issues get easier to recover from, the likelihood of them occurring needs to be higher in order for them to be worth addressing, relative of other things. And of course, you also need to factor in the expectations of your customers, which will be highest if they're buying the product to use themselves and lowest if they're using a free service you provide.
If you haven't realized it already, you'll eventually realize that finding and patching and testing all the edge cases is incredibly laborious and really is usually the "hard" part of development (the happy-path cases are usually the easy part), and secondly that prioritization is the key to productivity. There's an art to knowing what will come back to bite you, what's recoverable, how bad it'll be, when to bullet-proof and when to move on to the next thing.
Honestly, it somewhat boggles my mind that the original poster (and the post he links to) could both discuss the issue without reference to "worse is better," as if this was some sort of new insight that Twitter and Facebook have made . . .
I think you are right and have Worse-is-Better to the post. We are still telling and learning from 2000 year old stories so it probably doesn't hurt to play dress up :-)
Philip Greenspun also talked about this. The problem is that some gigantic asshole will grasp onto that unsolved 20% and convince some other gigantic asshole in charge of your destiny that the fact that you couldn't solve that other 20% means you're a moron. Speaking from experience.
I do wonder what will happen, when everybody starts making 80% solutions. When I use three 80% done third party libraries will I get (10.80.8*0.8 =) 51.2% done library?
Does 80 percent solutions only apply to the highest level?
17 comments
[ 2.5 ms ] story [ 52.0 ms ] threadThe protestant work ethic would suggest you haven't finished your job until you've covered that last percent.
The flipside to that is you can improve user experience for most of your users most of the time with a fraction of the work.
So given a finite amount of resources, what's better?
That depends on how important the project is. It would be worth it for Google to have someone optimize add-words for a full year even if they only got an extra click per 1/50,000 page views. However, that much attention to detail is useless when you have far fewer users / revenue. The secret is to focus on the highest reward areas and shift focus when other things become more important.
Most of the time, maybe 80% of the time avionics software does not need to contend with the plane flying through a thunderstorm. But I hope that the programmers didn't just toss that possibility into the "not important" category.
The "80/20" rule is something MBA types like to toss out so that they sound wise, but in some cases it's needs to be more like the 99.80/00.20 rule.
We don't know how many if any customers actually use it, but if we broke it, someone would complain.
We think we have all the cases covered and that it won't break, but it isn't polished the way it should be. The error messages aren't as great as they could be. But it works. If we have time later, we may come back to it. If a customer files a bug, we will address it then. In a year, it might even be pulled from the product.
For now, we make it usable, but not perfect.
One could argue that it is more ethical -- your duty to your investors, employees, employers, customers, etc. -- to focus on a more practical solution ("80%") than to seek perfection to satisfy your own personal standards. But if your responsibility (whatever it may be) dictates near perfection, then clearly that is what needs to be done. (Ex: 80% safe mass transportation system?)
If you haven't realized it already, you'll eventually realize that finding and patching and testing all the edge cases is incredibly laborious and really is usually the "hard" part of development (the happy-path cases are usually the easy part), and secondly that prioritization is the key to productivity. There's an art to knowing what will come back to bite you, what's recoverable, how bad it'll be, when to bullet-proof and when to move on to the next thing.
http://en.wikipedia.org/wiki/Worse_is_better
http://sethgodin.typepad.com/seths_blog/2006/04/the_customer...
aka "focus on high ROI stuff and cut everything else"
are we seeing a trend here yet folks or do we need to see this principle dressed up in anecdotes a few more times?
Does 80 percent solutions only apply to the highest level?