Pareto Programming

One of my favourite principles is the Pareto Principle, also known as the 80-20 rule. The principle states that frequently, around 80% of the effects come from 20% of the causes. I love this principle because it is so simple, and it can be observed and applied to so many different areas in our professional and personal lives. It is powerful enough to fundamentally change the way we approach our work, and encourages us to accept that the world we live in is unbalanced. Things aren’t evenly distributed.

The principle is named after an Italian economist named Vilfredo Pareto, who observed that 80% of the land in Italy in 1906 was owned by 20% of the population. More recently, a report produced by the UN in 1992 stated that the richest 20% of the population of the world controlled around 80% of the world’s income. The principle can also seen in nature, indeed Pareto is said to have observed that 80% of the peas in his garden were produced by 20% of the pods.

But how can the Pareto Principle help us to produce better software?

Here are some ways we can apply the Pareto Principle at work to ensure we are spending time and money where it will have the greatest impact, and to accept that imbalance exists and there is no point pretending otherwise.

80% of Value is Delivered by 20% of Requirements

This idea is particularly useful at the start of a project. Generally speaking, the initial functional specification in any software project is produced from an optimistic point of view. What developers and customers often fail to realise is that around 80% of value, whether we measure that in terms of customer satisfaction or profits, will be delivered by 20% of the requirements contained in that specification. This doesn’t mean that the other 80% of requirements are pointless or a waste of time, it just means that they are less important. For this reason, it is crucial to prioritize requirements. This may sound obvious, but it is surprising how little time is often dedicated to prioritization. The false assumption made at the start of a project is that we will have time to do everything, therefore it doesn’t really matter what we do first. The reality is of course that we will be faced with unexpected obstacles, therefore it pays to get the most valuable stuff done first. If we then don’t have time to do everything, at least we will not be omitting any of the vital 20%.

80% of Errors and Bottlenecks Will Be Contained in 20% of the Code

As a codebase ages, it is common for developers to fantasize about ripping it up and starting over. It seems to be riddled with bad code and inconsistencies. It is slow and difficult to read. The reality is that we just like to start with a blank page as this is more exciting for most people than having to drag an old codebase forwards. In truth, by rewriting 20% of the code, we can remove 80% of the solution’s ‘badness’. This does not mean that we should indeed go ahead and rewrite 20% of the code, it just means that we shouldn’t assume it would be best to start again. Again, we need to prioritize. If we are determined to improve things, we should work on identifying where the bad 20% is, and decide whether improving that will be enough.

80% of Your Productivity Will Be Delivered in 20% of Your Time

As desirable as it might be, you simply cannot function at 100% productivity, 100% of the time. Creativity tends to come in bursts and learning to recognise when you are feeling creative and when you are not is a valuable skill. Expecting yourself to constantly produce brilliant work is a recipe for stress. It might appear to work for a period of time, but soon your body will force you to stop and take your foot off the gas. Luckily, in any job, there are lots of menial tasks which need doing and are perfect for those times when we are not at our most creative. This might be writing some code which is not challenging, adding comments or reviewing your work or someone else’s. One technique I have used in the past is to categorise items on my to-do list as ‘creative’ or ‘menial’, and to choose tasks based on how creative I am feeling. Humans function in cycles whether you like it or not, and by learning to work within these cycles, you can maximise your overall levels of productivity in a sustainable way.

80% of the Value of a Team is in 20% of its Members

This may be controversial, but in every project I have worked on, success has depended primarily on the abilities of a small portion of the team. There are generally a couple of ‘stars’, usually including the team leader, who are there for other team members to lean on and whose experience and skill carries the project over the line. If that 20% of the team were to leave, the project would probably fail, whereas much of the rest of the team are more easily replaceable. These are the team members who have the greatest overall understanding of the project, allowing them to intuitively make important decisions and identify potential pitfalls. This does not mean that the other 80% of the team are useless. A good team needs reliable workers who can take designs created by others and make them a reality. There have certainly been times in my career when I have been part of that 80% of the team.

I really believe that understanding the Pareto Principle and its ramifications is crucial in software development. Whether we are considering requirements, bugs, team members, tasks or customers, all things are not equal. By acknowledging and accepting this, we can adjust our behaviour according to the relative importance of a particular thing, and embrace imbalance rather than deny it.

The post Pareto Programming appeared first on The Proactive Programmer.