[English] "The Pareto Principle" in Software Engineering

🇮🇩 Bahasa Indonesia Version 👇

In the world of software development, we are often faced with numerous choices that must be executed within certain deadlines. It’s not just about being confronted with these choices; we are often bombarded with them. This makes setting priorities seem almost meaningless. Our team's agility and focus become fragmented as we are forced to move in various directions.

In Greg McKeown's book "Essentialism," the divided focus of an individual or team is illustrated in this manner.

Greg McKeown explains that doing “Less but Better” leads to superior outcomes. As leaders of a development team, we have the authority to determine the team's direction, operational methodology, and pace. It is also crucial for leaders to acknowledge that team members have the right to decide their own paths and work processes.

Given the extensive backlogs, varied priorities, and dynamic nature of our teams, it is essential to devise strategies that ensure sustained productivity and optimal performance. One effective approach is “The Pareto Principle”, which posits that 80% of results stem from 20% of efforts. This principle enables leaders and development teams to concentrate their time and energy on innovating and tackling the most critical tasks—(the vital few).

Regrettably, in practice, the inverse often occurs. Teams frequently expend excessive effort (80%) while achieving minimal results (20%). According to a 2018 publication by Stripe titled "The Developer Coefficient" developers spend 17.3 hours per week on debugging, maintenance, and refactoring. This misallocation of effort underscores the need to better apply the Pareto Principle to enhance focus and outcomes.

The publication also revealed that developers acknowledge they spend too much time grappling with bad code.

When we talk about bad code, it often involves activities like refactoring or tidying up code, which can be endless. Additionally, developers face tight deadlines from a massive product backlog that needs to be addressed promptly, along with OKR and KPI targets, support tasks, bug fixing from customer reports, and research.

As the result, at the end of the quarter: 90% of the Product Backlog was delivered, with the remaining 10% still on the Todo List; 60% of these deliveries were delayed. The Incident Rate increased by 50%, indicating numerous defects within the product. Customer satisfaction decreased by 2 points, and the Google Play Store rating dropped from 4.0 to 3.5. Despite their efforts pushing their limits, the outcomes were not satisfactory.

It seems clear that both you and I agree that "More work does not necessarily mean productivity" and "Overtime does not guarantee our team can achieve the goals"

[Subsribe to Readmore]