THE PARETO PRINCIPLE: MAXIMIZING YOUR SOFTWARE DEVELOPMENT INVESTMENT DOLLARS

I attended an Angular event last night with my friend Matt Vaughn. The presentation was on unit testing, presented by Joe Eames. It was a great presentation, no wonder he’s a Pluralsight instructor.

I left though fixated on his comments “we should over-test…test everything.” I’ve been in the field long enough to know that many organizations aren’t testing enough, however testing everything and over-testing, just isn’t practical either.

As a lean process improvement practitioner, this is where the famous “80/20 rule” is so important. Formally known as the Pareto Principle, it can be distilled down to the following concept:

80% of all results come from 20% of the inputs.

I will examine the implications that this unofficial law has for software development and how it is the key to maximizing you development investments.

From Pea Plants to Software Bugs?

One of the remarkable aspects of the Pareto Principle is how it postulates that paying attention to a small detail can yield appreciable results. It is then appropriate that the principle originated, according to legend, through the observation of pea plants.

As Forbes recounts, the 19th century economist and philosopher Vilfredo Pareto supposedly noticed that 20% of his pea plants created 80% of his healthy pea pods. He then went on to investigate if there were such imbalances in many of the world’s important processes and found the 80-20 distribution everywhere; e.g. in Italy’s landownership rates and in the relative productivity of companies. The principle certainly holds true in software development too.

A Ubiquitous Phenomenon

Was Pareto’s discovery just an odd fluke? No, as the phenomenon has reappeared in many empirically verifiable forms for many decades. The applications range across economics, industrial reliability, management, marketing, and even personal development. As the article linked earlier notes:

? 20% of the sales reps generate 80% of total sales.

? 20% of customers account for 80% of total profits.

? 20% of the most reported software bugs cause 80% of software crashes.

? 20% of patients account for 80% of healthcare spending (and 5% of patients account for a full 50% of all expenditures!)

Pay particular attention to the second and third items on this list. This is our jumping off point for how the Pareto Principle interrelates software features, software maintenance, and customer satisfaction.

The Pareto Principle for SMB Software Investment

In software we can leverage the Pareto Principle to keep a lean feature set, to make smart choices regarding unit testing efforts, or even to deliver the most value to our clients by identifying the 20% of our features that 80% of our users are using. For SMBs this is not merely a clever tool to help boost business, it can be a game changer. It is a key to maximizing your investments since resources will be stretched way too thin if you maintain features that are not meaningful for your customers or for your bottom line, or test areas of your systems that nobody really uses or even cares about.

Organizations are often driven to add new features due to competitor pressure, a pushy client, or simply because of a good feeling the feature will be a success. However, many organization often look at only the development cost of the new feature and not its long-term hidden costs:

Increase in setup time: Your product, from an operational standpoint, gets increased overhead which could be in the form of configuration or required training.

Support costs: The feature may generate an influx of support calls. Keep in mind that customer support is an expense that involves payroll, supervision, training, office space, telecom expenses, etc.

Infrastructure costs: A feature may involve costly changes in infrastructure that you do not anticipate. For example, your feature may grow in usage quickly and rely on data from relatively costly RDBMS access. You will then have to consider a redesign with MongoDB or a more appropriate technology in order to maintain the feature.

Increased maintenance costs: Every feature adds a larger base from which bugs can emerge. This is particularly true with a high-volume feature. Your customers acting en masse may be able to break the product in a way that your developers or QA had not foreseen. Certain bugs can only emerge in corner cases that can only be seen in a production environment. It should also be noted that more code leads to a larger “attack surface” that malicious parties target, increasing the cost of security.

The Cost of Complexity: No matter how well-designed our solutions are, adding new features leads to complexity. Difficulty of development and troubleshooting always increases with the size of a code base and the number of moving parts that comprise a system.

Given all these factors, it becomes the organization's task to find out which features make the product “sticky.” There is a core set of functionality – 20% – within any system that drives 80% of success. You should perform a relentless analysis and paring to keep even the functionality lean.

No doubt, 20% of your outstanding bugs will cause 80% of your problems. You need to identify if any of these bugs are critical to your revenue-generating features. If they don't directly impact revenue and are not customer facing, then we can perform the most effective bug fix possible – remove the feature or de-prioritize the bug.

Eliminating bugs in software development by unit testing code is a critical practice, don’t get me wrong. However, organizations might try to target a percentage of code coverage in an effort to achieve a certain measure of quality of their software product while another might question the value of writing unit tests, especially when funding or resources are scarce. In either case, it is always best to concentrate unit testing investments to the 20% of your software that 80% of your customers use most.

20% of your customers drive 80% of your sales. Though we talk about the risk of new features, you must obviously have a product that evolves. The proper way to grow your product is to identify your fruitful 20% of customers and listen to their needs.

With only 20% of features really contributing to your bottom line, look to kill the remainder off. This can be done cold-turkey in extreme cases or through gradual weaning. One of the benefits of being relentless about dropping features is that if you discontinue the wrong one, your top 20% of customers will have an outcry. This will give you further insight into your customers and which features matter most.