Avoiding the Zone of Suck with the 80/20 Rule
Most people are familiar with the concept behind the 80/20 rule or Pareto Principle. It generally states that 20% of a population consumes 80% of the resources. It’s attributed to a 19th century Italian economist, Vilfredo Pareto, who realized that 80% of the wealth in a given population was concentrated in the hands of 20% of the people. Pareto referred to this inequality as the “Vital Few” versus the “Trivial Many.” This observation has since found its way into numerous disciplines, including logistics, management, inventory control, biology and (you guessed it) software.
Put another way, 80% of something can be accounted for by just 20% of the total possible reasons or causes for it. One common adage in the IT industry is that 80% of all end users typically use just 20% of a software application’s features. In software testing, 80% of observed errors are often caused by 20% of the entire pool of known bugs. And so on.
Depending upon who you ask, the 80/20 rule cruelly predicts that in every human endeavor effort and payoff are inversely related.
At Microsoft, the 80/20 rule was treated like gospel and frequently cited by software testers, engineers, group managers and even the CEO, Steve Ballmer. Microsoft applied the 80/20 rule to everything from balancing DHCP server usage to analyzing crash reports for Windows and predicting how Chairman Bill Gates would divide his time between Microsoft and the Gates Foundation.
In a memo to his employees, Ballmer wrote about an epiphany he had with his company’s error-reporting tool:
One really exciting thing we learned is how, among all these software bugs involved in the report, a relatively small proportion causes most of the errors. About 20 percent of the bugs causes 80 percent of all errors, and—this is stunning to me—1 percent of bugs caused half of all errors.
Applying logic to this statement, the inverse must also be true: 80% of the bug-free functionality is produced by 20% of the code.
If this is true, then software engineers—not just at Microsoft, but all engineers—are writing an awful lot of crappy code.
Enter the Zone of Suck
A similar distribution exists for the requirements of a software project. The project manager knows this well—it’s their job, after all, to understand the full set of requirements, keep a project on track, on budget and delivered on time to the satisfaction of the customer. The project manager’s mantra for their team, therefore, is to focus on the 20% that matters. I wish I had a dime for every time I’ve heard this phrase uttered during my career.
Every software team knows that projects begin with a set of requirements and proceed through a series of steps where the original specifications are compared with the end product for completeness and acceptability. Without going into the various software development methodologies, generally speaking it’s a process of refinement and revision. During each revision, if the requirements of the process follows a Pareto distribution, a few key issues will bubble up and need to be addressed, while old requirements will gradually fade away. Here’s an example Pareto distribution for a software project:
The left vertical axis is an arbitrary measure of the importance of a requirement while the right axis indicates a cumulative percentage. To apply an 80/20 rule of requirements management to a project, two lines (above) are added to indicate the 80% cut-off between the significant few, at left, and the insignificant many.
Another software adage which bears emphasizing here is that, in a given project, the first 80% is easy while the last 20% is hard. Early in the project life cycle, decisions are made about things like the choice of platform, database, data model, programming language and core functionality of the software. These decisions, once made, very seldom change. As with all things, the devil is in the details.
As one who’s worked for big software companies, small software shops and startups, it’s nearly always attention to the last 20% that makes a software project “pop” or fall flat. The engineer may report that they’ve coded the first 80% of an application according to the specification, but if the last 20% is rushed or neglected then code defects, poorly implemented features and performance bottlenecks can kill a project. Budgets are exhausted, deadlines missed, the customer is unhappy and the engineers are fed up. At this stage, the project may be said to have entered the Zone of Suck. It’s a place no one wants to be.
Failure to identify and respond to the last 20%—the significant few—near the end of a software project’s life cycle is what separates a usable, elegant, high-performing application from one that, well…isn’t. In the case of web applications, the ones that fail to impress usually reveal a similar set of problems: lackluster user interfaces, sloppy CSS, poor usability, missing features, slow response times and so on. Too often, shortcuts are taken to rush a product out the door and this critical last 20% (i.e., what the customer notices and expects) suffers as a result.
A Better Alternative
If we accept that the 80/20 rule has some merit, then it’s possible for software teams to anticipate the last 20% and avoid the Zone of Suck. Proponents of the Agile software development methodology will tell you that their principles are ideally suited to anticipating the last 20%. They’ll further tell you that changing requirements, even late in the process, are welcome so long as they satisfy the customer. Happy customers lead to repeat business, referrals and more revenue for the software makers. For startups, it can mean the difference between securing a second round of funding, a major liquidity event, or a lot of unhappy users and investors.
Regardless of which development methodology is used, a software business should never tell the customer, “it wasn’t in our contract,” that something which is clearly an oversight is “expected behavior,” or that it’s okay to release a beta version product with 20% of the bugs outstanding. This points to a major failure and is the quickest way to develop a poor reputation and kill off any hope of future business or funding.
Being involved in a winning software project feels great. The project managers, engineers and client are all stoked. If you’re lucky, the end-users you’ve designed it for will love it, too, and your application attains the Holy Grail of web software: the hockey stick moment.
The good news is it’s possible to change, if your team is willing to listen, engage with the customer and commit to the last 20%.
7 Responses
to “Avoiding the Zone of Suck with the 80/20 Rule”
1 Trackback(s)
- Nov 30, 2009: 5 Ways You Can Cure Yourself Of ‘Someday’ Disease - Work smart, play smart
Nice blog post.
teaches alot
Good job BillZ
The Zone of Suck: when your boss says to do 80% of the work in 20% of the time.
This is an interesting article. I think I may have heard of it years ago, in high school. One of my favorite things in school was learning different laws/rules and of all of them, i kind of liked inverse (proportionate) relationships. Ah, but it’s all fuzzy now.
I was wondering if this model, Pareto’s Principle, would hold in Cameroon. A part of me is not sure it would, but it might. I also wonder about the idea of the “zone of suck.” I suspect it can be avoided by simply scaling back expectations, doing a good job of course but realizing that perfectionism can only go so far and then it becomes a “deadly zone.” I apply this idea to my poetry. I get to a place where I decide and say, “This poem isn’t perfect, but it is good enough. Done. Moving on.”
I am sure, you and your co-workers will get to points where you can just say, “This looks pretty good, works pretty good, let’s run with it, let’s not beat ourselves up. Thanks for the hard work, everyone. If anything goes wrong, we’ll just put our heads together and do our best. Yeah. Do our best and let it go.”
I think the key is to try to determine what 20% of one’s efforts yield 80% of results and eliminate time-wasters sooner than later – not easy, but overtime and with experience it becomes easier. Interestingly, I realise that this principle holds true for how I use my personal things – I definitely only wear 20% of my clothes, jewelry and shoes – wow — time to get rid of 80% of my closet – definitely sucks!
It’s funny just how many ways there are to apply this rule. I’ve been struggling with my company’s insistence on focusing 80% of our design efforts or 20% (or less) of our users. Of course, this misguided effort also ignores improvement to those areas that account for 80% of our revenue.
In any case, perhaps your next article should highlight the perils of over promising while under delivering. I’m pretty sure that the combination of these ideas represents the Holy Grail of user centered design.
@churchill, thanks man!
@Joan, that is the zone of suck, indeed.
@BB, in the software business we sometimes call this “throwing it over the wall”.
@Anike & Monkey, nice observations. I’m sure I listen to 20% of my music collection 80% of the time, spend 80% of my time around 20% of my friends, and so on. Re: over promising & under delivering, been there with some product groups that shall remain nameless–wasn’t pretty.