I’m sure you’ve heard of the 80/20 rule, also known as the Pareto principle. It’s the idea that for many outcomes, 80% of the consequences come from 20% of the causes.

I recently read a book on the topic, which I don’t necissarily recommend, unless you’re into marketing. But it shed a new light on this topic for me. In summary, the author claims that the 80/20 rule applies specifically to processes where feedback is incorporated into the process itself.

This applies to most natural processes, as most natural processes incorporate some sort of feedback loops. Some more obvious than others.

It certainly applies to economics, where Vilfredo Pareto first observed the phenomenon. But it also applies to most biological processes (the sizes of plants and animals, etc).

And for our purposes… it applies to most software development practices, as well. Or at least the ones where we’re wise enough to apply to feedback.

Let me make some guesses based on this principle:

• 80% of the code in your project is written by 20% of the developers
• 80% of commits come from 20% of developers
• 80% of peer feedback comes from 20% of colleagues
• 80% of testing is done by 20% of the team
• 80% of debugging is done by 20% of the team
• 80% of bugs are written by 20% of the developers
• 80% of the bugs in your code are caused by 20% of the same types of mistakes
• 20% of the lines in your codebase are executed 80% of the time
• 20% of the features you’ve developed are used by 80% of your customers
• 20% of the files in your codebase contain 80% of the most used features

What other 80/20 relationships can you identify, or imagine are likely to exist? And how can this inform your approach?