Introduction
Italian economist, Vilfredo Pareto, to whom this principle is largely credited to, discovered that 80% of the land in Italy belonged to about only 20% of the population. He found that this was also true with wealth distribution across Europe at the time.
The 80/20 principle/rule or the Pareto principle states the following: 20% of the inputs drive 80% of the outputs. The ratio doesn't always have to be 80/20. Sometimes it is seen as 90/10, 99/1, or 70/30, but the principle still stands. A small portion of the inputs has a significant effect on the outputs.
The rule can be applied to a wide range of domains. For businesses, 80% of the profit is generated from 20% of the customers, or twenty percent of products account for 80% of sales. In the book publishing industry, this proportion is further skewed - about 1% of the books published generate 99% of sales revenue.
Software Development
For this article, the focus will be on how the 80/20 rule can be applied to the domain of software development.
Features
Features can either make or break a product. Too many features can lead to wasted effort since they might not serve a purpose. Having too few features makes the product unusable as there is no value. Deciding on which features to focus on and which ones to eliminate is important for creating a successful product. This is where the 80/20 principle can help us.
The 80/20 rule for feature development says 20% of the features are used by 80% of the users or 20% of features provide 80% of value in a piece of software. Finding out what that 20% is, through customer feedback, A/B testing, or other means, and focusing on those helps increase the value of the software.
Amazon Web Services (This can be generalized to most cloud providers), a cloud infrastructure provider, offers hundreds of services with more being added every year. It is impossible to keep up with all the services they offer and most are not used by everyone. There are however five core services (Compute, Storage, Databases, Identity Access & Management, Networking) that almost every customer uses. Even if you use something, not in the core services, it is likely the service is an abstraction of the core services (E.g: Machine learning tools are probably using Compute).
Bugs
Bugs are an inevitable part of the software development lifecycle. No matter how good your system is designed, bugs will eventually pop up. Large-scale systems will often have tens if not hundreds of known bugs. The 80/20 principle can help us decide which bugs to prioritize.
Using the 80/20 rule in this context says fixing 20% of the bugs can resolve 80% of the errors. This might seem hard to believe but has been proved to be the case. Microsoft discovered something similar when they were attempting to improve the quality of their products [1]. Their error reporting tool not only reported that 80% of errors were roughly 20% of the bugs but, 1% of the bugs caused 50% of the errors.
Design
Can the 80/20 be applied for something technical such as designing interfaces? Unsurprisingly, yes.
Only 20% of the functionality your interface provides is used 80% of the time. For an interface in an Object-Oriented Language, only a small amount of methods exposed will satisfy most use cases. The Linux I/O interface provides only a handful of methods for interacting with files. The same applies to REST APIs or CLIs.
Let's consider a popular command-line interface that almost every developer has worked with, Git [2]. Running the `git --help` will give you a large number of commands. Most of those commands are used rarely. For a developer's everyday job they might use `status`, `add`, `commit`, `checkout`, and `push`. Git is just one example of a good CLI, other tools that have this sort of usage pattern are `terraform`, `kubernetes`, and `docker`.
References
1. https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm
2. http://git-scm.com/docs
3. The 80/20 Principle, Expanded and Updated: The Secret to Achieving More with Less
