80/20 sometimes- Good Enough vs. Perfection

The 80/20 rule is generally a good one to understand. 80% of the effects come from 20% of the causes. So how does it apply to software, and to product development in general?

• 80% test coverage. Higher coverage is notoriously difficult to achieve.
• Fix the top 20% of your bugs as 80% of the problems come from them.
• Make 80% of your code side-effect free.
• 20% of your features are used 80% of the time, focus on those.

The list goes on. The 80/20 rule is a good one to keep in your head when you find yourself spending too much time on something.

But if you apply the 80/20 rule to everything, you will only end up with a product or code that is ‘good enough.’

I was looking at some trailers for a game I hadn’t looked at in a while, and the in-game cinematics were awful. Why? Because everything was good enough. The animation system is good enough. The combat is good enough. The tools were good enough. The character customization was good enough. It all amounted to a mediocre result (not the game, but the cinematics).

The 80/20 rule only works when you strive to hit 100%. If you aim for 80% test coverage, you’re going to be happy with 60. If you only care about 20% of your bugs, you’re going to become distant from your users. If you aim to keep 80% of your code side-effect free, you’re going to litter it with ‘one off’ side effects. If you only care about 20% of your features, you’ll probably only take each one to 80%.

It is obviously dangerous to demand 100% in everything, but 80/20 works as a way to balance priorities. 80/20 does not work as a goal. If you are phrasing your objectives in terms of 80/20, you’re never going to excel.