Posted by The 80/20 Principle, as defined by Vilfredo Pareto and popularized by Richard Koch, is all around us. It’s applicable to any topic, industry, or field of study, and software development is no exception.
The 80/20 Principle is one of the best ways to make sense of the non-stop barrage of data, languages, tools, and things to learn in software development. It can also be leveraged to gain insights and optimize your product management and development processes. It makes it easy to see realities that are hiding in plain sight.
Let’s start by looking at exactly what the 80/20 Principle is, and then look at some of the most common 80/20 realities in software development.
What Is The 80/20 Principle?
In Richard Koch’s book of the same name, he defines the 80/20 Principle in three different ways:
A minority of inputs lead to a majority of outputs. A minority of causes create a majority of effects. A minority of efforts leads to a majority of results.
There are subtle differences between the three above sentences, but they all boil down to saying the same thing: you can do a lot with very little. The principle is straightforward, and if you look closely, you’ll see 80/20, 90/10 and even 99/1 distributions everywhere:
- Apple phones account for a majority of the profit in the mobile market, even though they account for a minority of the phones out there.
- Most of Google’s traffic is still generated from search even though it’s only one product among many others that they offer.
- A single company, Amazon, accounts for a majority of online sales in the world.
The list of examples goes on and on.
I want to focus on some of the more common manifestations of 80/20 in software development and see how we can use them to our advantage.
Principles You Can Exploit
Learn 20% of a language or framework to be able to do almost anything with it
I recently had to refresh my knowledge of Angular and JavaScript. In the past, I would have read a book cover to cover and spent many hours building sample applications with a language or framework before I’d consider writing real-world code. This was a highly counterproductive approach.
I did things differently this time. I started by identifying the concepts that I used most frequently in my language of choice (C#). That list included things like the core language, framework constructs, the packaging system and the IDE. I spent a few hours learning about each of them with respect to Angular and JavaScript, and then quickly put myself to work on a real task. Of course, I ran into things that I didn’t know how to solve, but armed with the knowledge of those core elements, I knew what and how to look for the answers I needed.
The 80/20 Principle doesn’t concern itself with mastery — it’s focused on generating the most value with as little inputs as possible. Mastery takes many hours — up to 10,000 depending on who you ask — to achieve. 80/20 sets you on the path, but there is no shortcut to mastery, unfortunately.
20% of the features in any software are used 80% of the time
Thinking back on the applications that I’ve worked on over the years, the customer invariably only used a small subset of the features that had been developed. The other features were used occasionally, but nowhere near as often as the core functionality. Subconsciously, I always knew this was true. Maybe I ignored the reality of it since it means that most of what we build is waste.
Does it mean we shouldn’t be building those features in the first place? Probably. And if we do still decide to build it, the true minimum viable feature-set is probably a lot smaller than what’s being asked. Another way to think of it is from an 80/20 perspective: spend 80% of development time working on core features, and only 20% of development time on the rest.
20% of an application’s code accounts for 80% of the bugs
A production-grade application has lots of code. The core features probably account for about 10-20% of the overall code base, with frameworking, bootstrapping, UI, and other components making up a large part of the application. The core features of the application are likely to be changed more frequently, naturally making them more sensitive to change.
We need to ensure the code causing 80% of the bugs is checked more rigorously during review. Code review, peer programming, and unit testing, regression & manual testing can all be of help here. On the other hand, the code that isn’t as crucial can have fewer verifications. Spending hours validating a feature that’s used infrequently just isn’t worth the returns.
Takeaways
Once you’ve seen the world through the 80/20 lens, you can focus more on high value activities and reduce or eliminate low value activities. I encourage you to think about how the 80/20 Principle applies to your development team, and how you can leverage it to gain a competitive advantage in your personal life, career skills and development process.
Marc Roussy 