80:20 Rule For Software Development

Unless you were living under a rock, you probably have heard of Pareto Principle, better known as the 80:20 rule.

It states that 80% of effect comes from 20% of causes

https://en.wikipedia.org/wiki/Pareto_principle
This principle is named after Italian economist Vilfredo Pareto, who observed that approximately 80% of the land in Italy was owned by 20% of the population. 

This principle is often sited in various industries as a rule of thumb:

• In sales, 80% of the sales come from 20% of the clients
• In software, 80% of users only use 20% of application’s features
• in management, 80% of work is completed by 20% of your team

The point of this principle is not about the exact math, but understanding the imbalance between the input and output. Once you understand this, you will see this can be applied to any part of your everyday tasks.

80:20 Rule in Software Development

Like any other industry, software development is no different. There is an imbalance of every effort and output. 

In Product Management
This is one area Agile specifically addresses. There is a concept of prioritizing product backlogs (possible future tasks). Priority should be taken seriously. At this level, it’s not simply based on number of users or amount of usage. It’s somewhat complex matrix of importance from different groups such as endusers, business needs, executives’ priorities and development capabilities. 

In Development
80% of the task is completed by 20% coding. Start with that first. Don’t waste time on the small stuff initially. It is still important to get all parts completed, however, by moving in a prioritized manner, you have more flexibility to possibly address emergency issues that may arise. Also, having bigger chunks of the tasks done sooner, the more meaningful feedback you will get.  This will allow you to iterate based on real feedback, as in true Agile way. It’s always harder to change when you already have the details completed, even if it’s incorrect.

In UX
80% of use cases can be completed by 20% of interface. Make this portion of the interface very easy to use and design them first. Too often I see the user interface tries to cover 100% of the use cases and end up making the common usage difficult. Is button that is off by 3 pixels have more impact than confusing next step? Be realistic about the priorities. Don’t just make busy work for the team.

In QA
Knowing that 80% of the people only use 20% of the application features, you should be focusing on the 20% that matters. I’m not saying ignore the other 80%, but prioritize your testing efforts based on what matters. If you are spending the same amount of time testing for some obscure browser just because it is supported, you are missing the point.

For your regression test, have a prioritized list of features. When running the test, execute them from top to bottom. This will give your team a flexibility of shortening your testing time as needed, but still covering the most used features even when the time is shortened.

In Architecture
I’ve seen architects blindly quote some industry best practices as if they are one-size-fit-all solution. They need to understand why it is a best practice and know if it actually applies to your product. Industry's best practices should be a guide and not a must follow. If your architect doesn’t know the difference, why do you need him/her?

For example, a caching feature can be a good solution for optimizing the performance. But if most of the users only see unique pages, does this make difference? This solution adds nothing more than a development and QA headache.

This is an important role and your team will pay for your mistake for a long time. 

Stop the Busy Work

Focusing on what matters sounds like a common sense and logical. However, if you look around, it’s not as common as you think. Stop the busy work and come up for a breath from the sea of process. You may realize you are simply busy treading in the same spot. 

Using the 80:20 rule is not an exact science. By focusing on identifying the imbalance of inputs and outputs and prioritizing them, your team will produce more meaningful work and reduce unnecessary busy work that gets you nowhere fast.