Vilfredo Pareto, an Italian economist stated a principle in 1895 that we know as Pareto principle. The principle states that, for many events, roughly 80% of the effects come from 20% of the causes. This is now widely known as the 80/20 rule, the law of the vital few, or the principle of factor sparsity.
Since then, this rule has been applied for almost every industry including personal productivity literature. General rule 80% of the impact results come from doing 20% of the activities, and the remaining 80% of the activities produce only 20% of the results. Hence, this has been put forward by mentors/ gurus so that one focuses on just those things that are vital to attaining maximum results. To cite some examples of how this rule works:
80% of the sales come from 20% of your customers
80% of the products in a manufacturing company are usually on 20% of the line
80% of the sick leaves is taken by the 20% of employees
80% of usages are on 20% of your files
80% of dirt anywhere is on 20% of floor area
80% of the time you wash 20% of your clothes
80% of the time you wear is 20% of your wardrobe
80% of reading happens on 20% of the newspaper i.e. front page, sports page, editorials columns, feature stories
80% of your telephone calls will come from your 20% of your callers
As you can see the rule is quite interesting and no wonder it has caught attention from generations of productivity seekers. You can read more about it from the Wiki page.
80-20 Rule in Software Development Industry
Many have often attempted to apply this rule to the software industry as well. You can read about such attempts from here, here, here and here. Most of these reviews tend to prove that “80% of the development is completed by 20% coding”. And I totally disagree with these interpretations.
I am a Civil Engineer by academic qualifications and carry a couple of years of building constructions experience too. I can vouch and say that in case of any construction project the real efforts are involved in preparing blueprints of the project. These blueprints define almost every aspect of the finished building. The entire project can be vividly visualized using these designs and all of this design work happens even before you clear bushes/ trees from the site & start digging for the foundations. Once all blueprints are ready, rest is all simple execution. If you try to ignore the blueprints and try to apply 80-20 rule on the execution process alone then it would be totally misleading. Perhaps the same principle applies to movies as well. Story/ Scripting and other preparations, most of it before the actual scenes shooting starts, play a more important role in the success of a movie.
So is Software Development similar to constructing a building or making a movie? I would say both Yes & No. “Yes” because Software Development also takes a similar amount of initial efforts in planning before the first line of the code is actually written. And “No” because unlike a physical building & a movie, the software can be redesigned and its parts remade later on. Occupants of any new building would not start using the building till its complete. A movie would not release in theatres till its fully completed. However, a software would almost never be complete when it goes in the hands of the initial users. And of course, there are series of upgrades that keep flowing with the improved versions of it.
If you are looking at the 20% of the causes that bring out 80% of the effects then yes “20% of the causes” has to be the design part that is done before development is done. But, this 20% effort is not a single activity that happens in the beginning like in case of a building or a movie. There is a major chunk of it in the beginning and the rest is scattered in bits & pieces throughout the software development life cycle. Software development has to be seen in terms of collection of a small set of efforts (technically Sprints) that achieve a small subset of overall development goals desired. 20% cause is the planning is also referring to the efforts needed before beginning every new Sprint. In Software Development it would be difficult to apply this 80-20 rule when you are looking at finding that 20% that would produce 80% results.
However, 80-20 rule can still be applied to truly measure the progress of software development
So here are my two 80-20 rules about most of the software development industry.
1. When 80% of the features are coded then the software is only 20% ready.
I know this rule is hard to digest for many. Trust me, when 80% of the features are coded as per the design, the software is really just 20% complete. There is so much of the work that starts from this stage. Around this stage, real users start to get a full picture of the software product and then the requirements get refined. Tricky border scenarios surface. Innocent looking baby bugs are found. Certain design elements need to be re-done with the new set of requirements in view. For major projects, such re-design can go into multiple iterations. Growing up from real 20% is a very painful part of the software development cycle.
2. When software is 80% ready then the software becomes invisible.
I remember one incidence during my initial years of development. We were working on a software project that was stable, already in use for years and was undergoing further improvements. A new set of changes were coded & functioning correctly but were very slow. We needed performance improvement for the new feature. During meeting with end-users, one user stressed - “While using existing area I can do very fast, for the new feature software takes so long”. For both existing & the new features - it was exactly the same software house that was working on it and exactly the same set of users that were using it. If you re-read this sentence then you can find out that the user took all the credit when it comes to the features that are working perfectly fine and for the non-optimised area put the blame on the software.
Later I observed this as a trend. When you take long & steady efforts to ensure that the software is ready with real progress of 80% or more then the software & the software house become invisible. At this point of time, end-users feel empowered, highly productive and take pride in their increased independence, extraordinary efficiency. The software becomes part of their work life and thus is not considered as a separate entity. User is like a worrier who has attained ultimate perfection of warfare practices & mastered wielding their weapons, they reach a state whereby weapon is simply an extension of their body.
In this state, it's rare to find users giving credit to the software. During early years I used to wait for the praise to come from end-users but now I know that “No news is good news” !!
In fact when the software is undergoing real progress from 20% to 80% then the software team wants to stay invisible to their management & shareholders. This period is the toughest of all. Everything you are doing has already been communicated as “Already done” to them. There are no substantial visible changes that can be communicated to the management to keep them happy. When the development team wants to stay invisible to the management/ shareholders, they cannot. When they really want to remain visible to the end-users, they cannot. Sigh.
After having become invisible to the end-users for 5 times in my career so far, I can identify the trend and can tell real progress of the software product and even predict whether a product is ready for mass deployment or not.
Once you accept these rules you would never search for that “20% efforts” that bring in “80% results”. You would know it simply doesn't exist. This also explains why so many software projects fail. Many software houses simply put a tick to the “desired feature”, deploy it and walk away as quickly as possible. This means end-users are left with the 20-25% complete solution that can never attain the desired goals and thus leading to total failure of the software development.
Imagine a custom software development project, if software house does realistic estimates to develop a software with “real” 80% or more progress then its almost certain that the project would go to its competitor. To win the contract, one has to quote amounts that don't factor in these substantial efforts. After winning if the project is dragged too long it would kill the software house. They quickly complete the feature just enough to fulfill the contractual needs, hand it over and walk away. They don't wait to ensure end users are fully empowered. A custom software development project is almost always guaranteed to either make end-users feel like they wasted money or the software development house to incur a loss. Usually, both camps cannot be happy simultaneously. It's feasible when it's a mass-market product, means software is written for selling to thousands/ millions of users.
In case you are thinking about what would be the case with software that is 100% ready, in real life it never happens for any sizeable software solution. The end-user requirements/ expectations keep evolving. New innovations keep happening that change the way industry operates and thus software needs a new set of the changes all the time. Even governments change, tax regimes change and such changes would always keep the software developers busy.
Note that I have conveniently excluded the mission-critical software industry. You cannot afford to make your 300 million satellite keep crashing during launch to test that the software that controls the satellite launch vehicle is perfect. In such industries, first-time failure itself is not acceptable. Thus software teams behave differently with hand-picked best-experienced talents, best of the tools/ development practices, detailed exhaustive planning & testing cycles and with higher budgets, etc. Most common usage software solutions don't enjoy the luxury of high availability of funds & time and thus are managed differently.
#80-20RuleSoftwareDevelopment #80-20RuleSoftware
We at IntelliSoftwares would love to boost your business with top quality features.