How Agile Software Development Can Limit Bloat 09/09/16


One of the ten core principles of agile software development is to apply the Pareto principle to the process of building new applications. This principle simply states that in most events, 80% of the results are derived from 20% of the causes. Pareto came up with this principle in the late 19th century by simply observing his surroundings. For example, he noticed that 20% of the pea pod’s in his garden produced 80% of the usable vegetables. Likewise, he observed that 20% of the population owned 80% of Italy’s land.

When we apply this principle, also known as the 80-20 rule, to software development, interesting things happen. One of the most important results is that it helps to limit software bloat. In an era of mobile applications requiring specific functionality without sacrificing speed and reliability, getting rid of bloat is important.

[Not a valid template]

Eliminating Wasted Time

Agile software development expert and author Kelly Waters wrote an excellent piece back in 2007 that, while dated, is still relevant in 2016. In that article, he mentioned internal Microsoft research that indicated the average Word user only takes advantage of about 8% of the software’s capabilities. That’s is no surprise today, but it was pretty surprising back in 2007.

Here’s the point: Microsoft developers wasted a lot of time implementing a tremendous amount of functionality that users were not interested in. And they are not alone. Software bloat continues to be a problem more than a decade after we figured out we need to bring an end to it. Agile software development can be a big part of eliminating bloat by preventing developers from wasting time on unnecessary functionality.

Practical Implementation of Pareto’s Principle

What would the Pareto principle look like in practical terms? Well, we know that successful agile software development is a team effort. It is not just one person building everything from the ground up. It involves a team of developers and engineers working together to create the final product. The Pareto principle suggests that before anything is done, the team sits down and figures out what their app should accomplish at its core.

Remember that today’s mobile users are all about function. If they are using an app that lets them create a packing list for business trips, the functionality of that packing list is the core of the app. That’s where the team starts. Only after core functionality is mastered is it necessary to begin looking at the user interface and extra features.

What typically happens is that one team starts working on function while another is busily working on interface. The two teams have to meet every now and again to make sure they are on the same page. And more often than not, the interface team is putting a lot of time and effort into developing things that, in the end, are not really going to be useful or desirable. If the team understood that 80% of what is important would be accomplished during the functional development stage, they wouldn’t spend so much time working on things that are unnecessary.

As Waters so eloquently stated in his article, software teams have a tendency to over-engineer their software solutions. It is far better to get a project to market with just the functionality users demand – and nothing more – than to pour resources into functions and features that will give very little use. Just think Microsoft Word if you doubt that.

Agile software development is a different way of looking at building applications. Applying the Pareto principle streamlines agile development to help produce great results without a lot of waste.