Strategy: Solve Only 80 Percent of the Problem

Re:Strategy: Solve Only 80 Percent of the Problem by mbenjaminsmith on Friday August 28, 2009 @04:09PM (#792184)

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?

[ Parent | on HN ]

Re:Strategy: Solve Only 80 Percent of the Problem by Retric on Friday August 28, 2009 @04:19PM (#792205)

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.

[ Parent | on HN ]

Re:Strategy: Solve Only 80 Percent of the Problem by ams6110 on Friday August 28, 2009 @04:59PM (#792282)

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.

[ Parent | on HN ]

Re:Strategy: Solve Only 80 Percent of the Problem by runevault on Friday August 28, 2009 @05:03PM (#792286)

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.

[ Parent | on HN ]

Re:Strategy: Solve Only 80 Percent of the Problem by cema on Friday August 28, 2009 @10:07PM (#792664)

The 80/20 rule is self-applicable and so applies to 80% of cases. (Captain Obvious said hi.)

[ Parent | on HN ]

Re:Strategy: Solve Only 80 Percent of the Problem by cema on Saturday August 29, 2009 @12:20AM (#792770)

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%.)

[ Parent | on HN ]

Re:Strategy: Solve Only 80 Percent of the Problem by akeefer on Friday August 28, 2009 @08:58PM (#792594)

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.

[ Parent | on HN ]

Re:Strategy: Solve Only 80 Percent of the Problem by varikin on Friday August 28, 2009 @04:52PM (#792273)

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.

For now, we make it usable, but not perfect.

[ Parent | on HN ]

Re:Strategy: Solve Only 80 Percent of the Problem by lucifer on Friday August 28, 2009 @06:01PM (#792377)

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?)

[ Parent | on HN ]