Our 2022 Software Engineering Meeting Benchmark Report revealed interesting insights into how engineers and developers spend their time. We found that engineers are more productive when they can focus deeply and work faster when they have more time to focus.
Both of these things center around one thing: effective time management (and, okay, fewer meetings). How can software developers prioritize their time and optimize their schedules for the best results?
One solution lies in the Pareto Principle, sometimes referred to as the 80/20 rule. In this guide, you’ll learn the following:
- What the Pareto Principle is, and where it came from
- How the 80/20 rule appears in software development
- Advantages of the Pareto Principle in engineering and development
What is the Pareto Principle?
Named after economist Vilfredo Pareto, the Pareto Principle (or 80/20 rule) states that 80% of outcomes or consequences result from 20% of causes or inputs. The original observation stems from Pareto’s look at the relationship between wealth and population in Italy in the late 1890s. He observed that 20% of the population owned 80% of the land in Italy. Pareto surveyed other countries and realized the same generalization applied to other areas.
Ultimately, the Pareto Principle is a generalized phenomenon that highlights an uneven power distribution. Over the years, this concept spread, and we adapted it to various industries and topics, including time management strategies. Some examples include:
- 80% of total website traffic stems from 20% of the website content
- 80% of a company’s profits come from 20% of a company’s customers
- 80% of points scored during a sporting event come from 20% of players
As a time management strategy, we might find that 20% of efforts and tasks produce 80% of results that move us toward our goals. So, it would make sense to bump these 20% tasks to the top of our to-do lists.
Examples of the 80/20 rule in software development
We can apply the 80/20 rule to software development. There are many use cases where we can relate this concept to the world of coding throughout the software development process. Let’s dive into a few examples to bring the idea to life.
Feature development
When considering the development of new features, we can apply the Pareto Principle as such: 80% of users will benefit from 20% of features. Why does this matter? Feature requests may come in left and right. Suppose the development team is small or has limited resources to dedicate to improving current features or rolling out new features. In that case, the team will need a system to help prioritize which features are most important. That’s where the 80/20 rule can help development teams identify critical application features that will satisfy most users.
Some research supports this theory. In a study, Pendo found that around 80% of product features are “rarely or never used” despite companies spending a lot of money building the software. With this in mind, teams may want to consider scaling back the number of features to focus on the highest-priority ones to provide the most value.
Similarly, we can apply the Pareto Principle to the effort development teams put into building a successful application with well-constructed features. The phenomenon would imply that 20% of development efforts result in 80% of successful features. In this case, developers may benefit from spending 20% of their time on deep work (reader: see Focus Time) to allow them to write code and give it their best effort.
Michal Suski, Chief Product Officer and Co-Founder at Surfer, uses the Pareto Principle with his team when prioritizing features:
“When coding, we focus on the main functionality of a feature first and then move on to the minor details that would improve user experience. Additionally, we often use MVPs (Minimum Viable Products) to get users' feedback faster while ensuring that most of their needs are met by the product's core features. We will then add more complex features based on these insights, which we do after assessing whether they are necessary according to the 80/20 rule. If they don't provide significant benefits compared to the effort required, then we won't waste time with them.”
Bugs and testing
The 80/20 rule is handy when thinking about code quality and debugging issues. We can apply the Pareto Principle to quality control, as 80% of bugs can be found in 20% of the code. If 80% of bugs lead back to the same lines of code, that should signal to programmers that those lines require additional attention. While debugging one specific bug may be a high priority and a first step, teams can use this information to dive deeper into the code and prevent other bugs from arising from the same code snippet.
In the early 2000s, Microsoft’s CEO famously applied the 80/20 rule to bugs. The company reported that 80% of errors and crashes in Windows and Office resulted from 20% of the pool of bugs detected. That’s not to say the 20% were issues that were easy to resolve, but the implication of a small portion of the code causing bugs held true.
Prototyping
It’s no secret that prototyping is critical to developing new technologies, and the 80/20 rule can apply to the prototyping process. With a prototype, developers can pull together 20% of a product and obtain enough feedback from stakeholders to determine if they should proceed with it or not.
Dustin DeVries, Co-Founder of Caffeine Interactive, sees the Pareto Principle in his agency’s processes for rapid development using prototypes. When asked how the 80/20 rule fits into prototyping, DeVries said, “In my opinion, prototypes are a great example of the 80/20 rule because you're developing way less of the product at first but getting the critical feedback you need in a matter of days to weeks, not months.”
And the benefits are clear: “It essentially allows you to answer the product-market fit question in a tenth of the time (and cost) it takes to build the actual product because you're not building the whole product. You're only building the interactive interface that allows users, investors, whoever else to understand the product, interact with it, and provide feedback,” DeVries said.
Development time
Regarding time management and the Pareto Principle in software development, we might suggest that developers spend 80% of their time on 20% of the project’s requirements. If a small portion of requirements takes a majority of the team’s time and bandwidth, it’s necessary to ensure that the team is prioritizing the most critical needs in case they run out of time during the sprint.
Senior Software Engineer at Ultimeta, Fedor Yaremenko, saw this scenario play out in his work:
“About a year ago, our team was preparing a product for a demonstration and presentation of document acceptance functionality for our customer. It was a significant client for us because it was one of the biggest real estate developers in the country. I decided only to implement the functionality needed for our demonstration, meaning if I made a mistake, it wouldn’t affect our whole product. I moved the implementation of the remaining requirements to the next sprint and marked some of the tasks as technical debt.”
The result? Yaremenko and the team finished the project on time with zero mistakes, and the customer signed a contract for the second phase of the work.
Advantages of the Pareto Principle in development
While the Pareto Principle may not apply to every development scenario, plenty of advantages are worth noting. For example, using the 80/20 rule when developing features in software development can lead to better web applications and technologies, which can also increase revenue.
Additionally, it can be highly beneficial when prioritizing work for developers allowing teams to cut through the noise and determine what is truly urgent and important.
Finally, in the context of prototyping, the 80/20 rule may even help organizations save money as developers spend time putting together prototypes before investing fully in new technology and determining if it’s the right one.
Going forward
The Pareto Principle (80/20 rule) suggests 80% of outcomes result from 20% of inputs. Many industries use this phenomenon as a time management strategy for prioritizing work. The rule applies to many facets of software development, including feature development, bugs, prototyping, and time spent developing. This technique can be beneficial in helping developers prioritize their time effectively to produce the best solutions with the most significant impact.
