The Ninety-Ninety Rule And Pareto’s Principle

90/90 — The Funny One

The 90/90 rule is a tongue-in-cheek “law” of software development. It states:

The first 90% of the code you write is responsible for the first 90% of development time. The last 10% of the code you write is responsible for the last 90% of development time.

Obviously, 90% plus 90% is greater than 100%. That’s the point. It’s meant to show us that project planning always underestimates actual development time.

Anyone who has worked on a project from start to finish understands this concept. Everyone gets together and they talk out the project specifications in a series of seemingly-never-ending meetings. The milestones are set in stone. The project makes leaps and bounds for most of its development time. The largest and easiest parts of the codebase are released to a development server. It kinda looks like the whole thing is almost done. A few more sprints to handle the details and the project will be complete. Everything is going according to plan — the project is right on time.

But then the development of the last few features gets… complicated. Those last few sprints turn into eight. Complicated issues start to pop up. QA finds issues that need to be addressed with their testing functions, usually due to some obscure combination of states. A stakeholder has a new feature that needs to be added. An engineer has concerns with a feature’s implementation and wants to re-write it after discovering an issue in how it was initially planned and built.

It feels like it takes as long to wrap up those supposed “loose ends” as it did to complete everything else. In many cases, it actually does.

The 90/90 rule is humorous, of course. People remember funny things more than they remember boring things, after all. The rule is to remind us of those complicated issues that arise at the end of a project, which then takes longer to complete than expected. It’s meant to illustrate the recurring theme of underestimating the amount of work that’s actually needed to complete a project.

80/20 — The Not-Funny One

The Pareto Principle, also known as the 80/20 rule, states that 80% of the outputs of a system come from 20% of the inputs of that system. In other words, 80% of the results stem from 20% of the causes. This isn’t a tongue-in-cheek rule — this is a real observation. It was first noted by the Italian political philosopher Vilfredo Pareto. It isn’t a strict rule, of course — all systems behave in different ways. But the vast majority of systems, in general, behave something like this.

20% of your clients generate 80% of your sales. 20% of your users are responsible for 80% of your app’s use. Testing 20% of the codebase will take up 80% of QA’s time spent creating test scenarios.

Pareto’s original example was from his garden, where 20% of his pea plants generated 80% of the peas he harvested. He then extrapolated his idea out to other systems he could observe, such as income, or tax receipts.

How Are They Related?

These two rules illustrate how certain inputs in a system will generate greater outputs than others. The 90/90 rule illustrates recurring issues when calculating a project’s development requirements. The 80/20 rule illustrates the fact that some development efforts are going to take longer to complete than the rest.

The 90/90 rule arises out of the fact that our brain doesn’t really understand the 80/20 rule. When we naively think about the time to complete a large project, we do it in a linear way. We consider the median time it takes us to complete a feature, and then we extrapolate that out to be the time that each separate feature will take. In reality, most features cluster around a certain amount of development time and effort to complete them. But a handful require a much greater commitment to finish. Those few high-effort tickets skew the project’s development time in a way that is — time and time again — underrated during the planning phase.

In other words, these two aphorisms are an attempt at describing a power-law distribution. In our particular case, we are talking about how the creation of a certain section of a codebase can absorb far more developer resources than other sections. This factor is often overlooked and causes time and budget overruns.

Plan For The Unplanned

If you or an organization you work for has an issue with these types of overruns, the easiest solution is to just budget more time or resources from the start. Let’s call this an “Unplanned Issues Allotment.” But to most project managers, that feels bad. They want a reason why the budget needs to be increased by some amount — whether in time allotments or actual dollars.

Some quick googling about project management and budget assignment produces results like this.

Take a moment and give it a brief skim. Do you see anything in there about budgeting for unplanned work or unplanned difficulties? No! It’s absent!

Hopefully, your organization has enough historical budget data that you can show a clear pattern to defend your decision to increase the budget. That’s covered in either step 1 or step 2 in the referenced project budgeting cheat sheet. If you’re the project manager or a business analyst, you should try to derive your usual overruns from this data.

But if you don’t have the historical data to defend against budget overruns or your PM doesn’t have a grasp on your historical trends, you’re going to have to consider step 3. That’s the step that informs the project manager to “leverage their experts.”

If you’re a developer or other knowledge-worker on the team, this is your chance to bring up the potential issue to whoever is budgeting resources, before it can become an issue. They’ll understand what you’re talking about.

This story is republished from my original Medium article.