The Pareto Principle in Software Engineering
Leveraging the 80/20 Rule for Productivity
In software engineering, efficiency is often the key to success. The Pareto Principle, also known as the 80/20 rule, offers a framework to focus effort where it matters most. This principle suggests that 80% of results come from 20% of the effort - an insight that can really shape how software teams can organise their tasks, manage collective efforts, and consequently deliver the value that matters most.
In today’s Theory Thursday article, we’ll explore how the Pareto Principle applies to our world of software engineering, how it can impact productivity (for better or worse), as well as how to use it to its best potential.
What is the Pareto Principle?
The Pareto Principle was named after Italian economist Vilfredo Pareto, who in the late 19th century, noted that 80% of Italy’s wealth was owned by only 20% of its entire population. This concept has since been extrapolated to suggest that a small percentage of causes often leads to a majority of effects in various contexts, of which software development is one of them!
In software engineering, the Pareto Principle can take a number of forms:
80% of software usage comes from 20% of features
80% of bugs arise from 20% of the codebase
80% of development time is often spent on 20% of tasks
The key is to identify what the critical 20% is and maximising it to our potential.
Applying the Pareto Principle
Let’s take a look through a number of different lenses to see how the Pareto Principle could be used within a software engineering context.
Prioritise Features
It probably comes as no surprise that most features in an application are not providing a great deal of value. For example, animations on a UI look great and add a sense of finesse, but they’re definitely not a critical part of the application’s functionality. Similarly, have social integrations to share content which typically wouldn’t be shared by people (e.g. on your personal health record from your GP/practitioner’s system) makes little to no sense.
Using the Pareto Principle / mindset, we can use data to inform how we go about building and prioritising features. Use things like analytics, user feedback, A/B testing to identify where the most value values, and prioritise using this.
It’s better to have a bug-free, fully-functioning service than something which breaks regularly yet allows you to switch between light and dark mode (although dark mode is definitely a winner).
Focus on the 20% of features which deliver 80% of the value.
Optimise Bug Fixing
It is a known fact that the majority of bugs will originate from a smaller section of an application’s codebase, usually legacy.
Using the Pareto Principle, we can shift focus on to the 20% of bugs which might be causing 80% of the issues that end users face. This was exactly the tactic that Microsoft has previously adopted when tackling Windows crash issues as reported in this older article.
As another example, by implementing good observability practices we can more easily highlight the potential hotspots within an application’s end-to-end. This greater visibility then allows us to spot and resolve things quicker. I did this in a previous role by auto-instrumenting a legacy application and API, which quickly highlighted some issues with database performance that caused the majority of server errors that were slowing the service down and preventing user access.
Improving Team Productivity
There is another concept called “social loafing” which stipulates that individuals work less hard in a group environment compared to when working alone. This can also result in a smaller portion of a team contributing more towards the output of the team than others. In other words, 20% of the team are delivering 80% of the output.
Flipping this on its head
For example, senior engineers might be the only ones making the critical architecture decisions within the team and leaving the more junior members to perform menial tasks. Although this might appear to work, it doesn’t help the team grow and become less dependent on more senior team members. The action here is to perform effective coaching and mentoring to help up-skill the more junior members to reduce the bus factor, allowing for a more even distribution of value delivery and productivity from the team.
Closing thoughts
How might you use the Pareto Principle?
What 20% of the tasks you perform add the most value?
Where do 80% of your system errors come from?
Where does the majority of your time go each week?
I hope this simple idea acts as food for thought. The beauty is that it can be applied to pretty much anything regardless of whether it is time allocation, sources of bugs in a system, feature development etc.
If you liked learning about this theory, please like, share and comment on my newsletter as it helps me grow my audience. Additionally, if you’re not already a subscriber then please consider subscribing today and never miss one of my articles again!