Custom Software
TAG HERE

80/20: The Universal Truth About Software Development

The software development process can be a more seamless and cost-saving experience by following these simple principles.

Have you heard about Federico Damaso Pareto? 

A century and a half ago Federico Damaso Pareto discovered that 20% of the pea plants in his garden generated 80% of healthy pea pods. This discovery inspired him to think about unequal distribution. He realized that 80% of the land was owned by just 20% of the population, as well as that 80% of production typically comes from 20% of companies.

You might be wondering what this has to do with software development? 

Pareto discovered something we will later know as the universal truth or the Pareto Principle. This rule states that 20% of effort brings 80% of results. 

Translated into the language of software development: 20% of software bugs cause 80% of crashes. More importantly, to successfully complete a project, 80% of the time spent building an application ought to be committed within the first 20% of starting it because the remaining 20% of the build will take up exponentially more time.

Why is it important to gather user feedback? 

The thought that 80% of the time spent on a coding project should be devoted to the first 20% of starting it, is intertwined with the universal truth that 80% of users use only 20% of the features in an app.

Following the Pareto Principle makes software development a much easier process, as it allows software developers to focus on, and prioritize specific features that are most useful for customers, instead of crafting a whole suite of bells and whistles for the app.

Gathering user feedback before the launch is crucial, as it prevents the product from flopping upon launch. Software developers need to know whether their users will have UX challenges while using their application, which features are useful, and which ones are not. Waiting to fix these issues until after the launch might lead to adoption failure.

That said, the following are the most important types of feedback coming out of testing - a critical step in software development:

  • Feedback on priorities: It’s critical to ask questions about whether you’re building the right features for your application, and how useful they will be for the end-users. As we said, 80% of users use only 20% of an app’s features, and it’s important to discover, based on user feedback, what those features are to ensure your product’s success. 
  • Feedback on design: Most successful products are the ones that are easy to use and have a short learning curve. Software developers need feedback from their customers on the user interface, as good design and UI will help attract more users post-launch.
  • ​​Feedback on working software: It’s also important to ask whether the software you built actually does what you promised it would do? Will the application you created actually work towards what the users want to do? By asking these questions, you’ll save a lot of time spent by avoiding redoing the application build. 

How does prototyping greatly underestimate coding time?

Prototyping brings a wide array of benefits, including:

  • Users can give valuable feedback to software developers
  • Clients can see early on whether their solution matches their specifications
  • Provides insights into whether deadlines and milestones can be met

Prototyping in custom app development helps developers recognize flaws in their apps early on and allows them to correct those flaws in time. 

Users can test the product rather than trying to evaluate it just based on descriptions. Prototyping also provides a better insight into the software’s functions and potential issues. Lastly, prototyping provides deeper insights into functionalities that should be added, those that have not yet been considered but could be key factors in the post-launch success of an app.

App development requires constant testing and debugging 

Almost two decades ago, research done by Microsoft concluded that 80% of errors in Windows and Office are caused by 20% of all bugs detected. This data can be useful in software development to make the debugging process much faster, and more efficient.

More specifically, it will help developers focus on the most problematic areas of code that will decrease the majority of bugs reported in the application. This method can make software development an easier and more painless process. However, this approach comes with its own set of pitfalls.

While studies show that we can find the majority of bugs in 10-20% of code, they also show that this same portion of code is tweaked the most often. This can also lead to more problems.

Each time developers tweak the code in custom apps, they're increasing the chances for new bugs to appear. The problem comes from the fact that developers usually try to localize the bug, while losing the big picture that can provide a better overview of what's fundamentally flawed with the codebase.

By doing this, chances are that developers will just make things worse and inadvertently introduce a new bug as a consequence. This can cause a downward spiral that can result in the need for "brutal refactoring", i.e. new code needing to be written from scratch.

That said, while following this rule, and making the most out of it, it's important to look at a code as a whole and try to understand what's fundamentally flawed with it, not just focusing on troubleshooting individual bugs in isolation.

80% of an app can be developed in 20% of the time and budget

Following the Pareto Principle, we can also conclude that 80% of an application could be developed within 20% of the time and budget. 

But, that's easier said than done. Especially in custom app development. With iterative testing, debugging, and re-coding, It’s that last 20% of the application build that takes up a lot more time.

Software development isn't a linear process. And while it does require people who have sufficient knowledge and skills to complete the job, it also depends on other factors that can have a great impact on budget and time spent on a project.

Efficiency is a result of clear communication, which may be harder to achieve as large organizations continue to grow. Clear communication and clear requirements on the project demand discipline through all levels. 

First, clients need to be very clear about the requirements and functionalities they want to introduce in their app, and its overall look – which starts with user feedback. They also need to discuss their objectives with the software development company and know which questions to ask. Secondly, project managers need to communicate clearly with developers about what needs to be done. Lastly, developer feedback is crucial in managing expectations.

Final thoughts

While we do see how the Pareto Principle can be used to improve the software development process, we also understand the challenges of setting the right environment for its application. Even though having skilled developers is always a plus, sometimes external things can influence the production process to the point it inevitably suppresses productivity and efficiency.


Luckily, there are ways you can get the software application you need completed while keeping costs and deadlines within reason. By using a blended agile approach to projects, our team at AppIt Ventures ensures that common risks with the software development process are reduced to a minimum and that customer satisfaction is our top priority. To learn how the process works, send us a message!

Talk to our team to scope your next project.

BOOK A PROJECT CALL