In my opinion, the Pareto Principle, - also known as the “80-20 rule” - could be by far the most misunderstood and abused thing in software development. You can often see how people apply this rule in the following way: “Only 20% of our efforts brings 80% of the results, so let’s drop the rest”. Well, fair enough, sometimes it may work and save you some resources. No kidding. Be careful though! The Pareto Principle doesn’t say anything about the last 20% of the outcome. Do you need them? Are they essential? Can you actually ignore them?
In order to simplify our mental model for the “80-20 rule” let’s think about physics. Assume, you would like to go to Mars. In order to do that you have to obviously leave Earth first. So, your goal is to fly around 11 km per second. That needs 100% of the thrust and fuel available for your rocket. And you can’t dodge or argue that really. Physics never splits the difference. There is no acceptable 80% success which you can buy for 20% of your resources. You’re either left the planet or dead.
Going back to software development problems you can find references to Steve Ballmer, ex-CEO of Microsoft, saying that the 80-20 rule applies to bugs, as well as features. And casually mentioning that, in general, 80% of a piece of software can be written in 20% of the total allocated time. Smart, isn’t it? Yep. But here is the catch. Reasonably so, the missing 20% of the code occupies 80% of the development time. Bad news, huh?
Standard dynamics of an average development cycle follows logarithmic curve. Velocity goes up quite fast and then slows down dramatically. In order to build a prototype you usually don’t need a lot of time. You can cut some UI / UX corners, put something together, skip validations here and there, forget about translations, ignore customer support needs and throw all of the reporting out of the window. The result looks amazing and feels “almost ready”. You can do an impressive demo for your investors. And some people can even start testing the solution. But in order to go to production without losing all of your remaining hair coverage you need to properly finish dangling 20% of the task. Without translations, paper trails, monitoring and reporting it won’t be possible to sustain the feature in the long run. Meanwhile, adding all of those things now, according to the Pareto Principle, will require 4x the time you just spent to build your “almost ready” solution. That can be quite frustrating for your team if you were not prepared! And the best part is that for an external observer nothing is happening, as if you just stopped working. You push hard, you spend time and money, but no visible change is coming out of the funnel. Kind of a software development event horizon in action.
Team suffers the most during such stretches of time. List of issues seems almost endless. And then, when everything is finally finished from the development point of view, it comes down to an adoption. You need to roll out the feature, document it, present it to your users and make sure it is actually understood. Otherwise, especially with internal back office systems, you may easily end up in a situation when something is technically available and ready, but before this last adoption push the feature is not used at all.
When mentally applying the “80-20 rule” to the software development project make sure that missing 20% of the result can actually be abandoned or delivered later on and down the road. Without this understanding or willingness and readiness to walk 20% of the path while spending 80% of the resources you may end up with a set of very expensive text files stored in a fancy way on your hard drives across multiple data centers instead of the useful feature you worked so hard for. So, watch out!