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%.
I had an opportunity to stop by the 2009 South West Regional Agro-Pastoral Show, an annual exhibition for local farmers and craftsmen, here in Limbe this afternoon. The event was held on a community field ringed by exhibition booths overflowing with every imaginable vegetable, fruit and live animal cultivated and raised in the southwest region of Cameroon. In addition, there were a number of innovators with homemade products and gadgets crafted from local materials.
