Luca Maraschi is the cofounder and CEO of Platformatic.
The Pareto Principle, also known as the 80/20 rule, is popular in various industries, including software development. The idea is that 20% of developers’ time is spent on work that results in 80% of the value created.
But while this principle sounds good in theory, in practice, it doesn’t always pan out in the way software companies initially envision.
The Pareto Principle: Theory Versus Practice
The Pareto Principle is a framework that is supposed to give software developers more time and energy to innovate.
But in practice, it’s usually a different story. Instead of developers spending 20% of their time on tasks that produce 80% of the results, they often end up doing the reverse, pouring 80% of their efforts into work that ultimately amounts to a mere 20% of a product’s features, or that makes just 20% of the overall impact, which is not productive or efficient.
Research has shown the extent of software development’s efficiency problem. According to a 2018 study by Stripe, developers estimated that they and their team members spend an average of 17.3 hours weekly on “maintenance” work such as debugging and refactoring. What’s more, when asked what they believe is “hindering developer productivity” at their companies, 52% of respondents pointed to having to handle legacy systems and technical debt, 45% to leaders’ priorities in terms of projects and assignments and 40% to having to build custom technology.
The Consequences Of Inefficient Development Practices
When software companies inadvertently practice the Pareto Principle in the opposite manner, where developers spend 80% of their time yielding only 20% of the results, they put developers and themselves in a challenging position.
Development thrives on creativity, innovation and working on transformative solutions. Without room to innovate, developers can’t leverage their skills to the fullest extent possible. Instead of generating ideas to drive their careers and companies forward, they get stuck with mundane, repetitive tasks that don’t push the needle. When a large portion of developers’ efforts are invested into a smaller subset of a product’s complex features, there’s a greater likelihood of project timelines getting extended and budgets getting tighter. As a result, a company’s ability to meet customer wants and needs in a way that surpasses the competition becomes greatly diminished.
Working Smarter, Not Harder, Is Key
In trying to improve developer productivity and meet tight product deadlines, companies sometimes opt to eliminate complex features. But by cutting corners, companies risk harming their long-term ability to scale and their reputation among their customers.
But companies can avoid falling into the 80/20 trap by working smarter, not harder. Specifically, company leaders should do what the Pareto Principle is about on the most basic level—they should be intentional about having their developers invest just 20% of their time to generate 80% of the results. This entails taking a regimented approach to ensure that all processes are streamlined, that teams have the right tools for their work, that distributed teams are in sync and that complex code has been tamed—to name a few examples.
But this step alone is not enough. To see success, software leaders should also fundamentally change how they view the 80/20 rule. In addition to directing developers to invest just 20% of their time to yield 80% of the results, software leaders should also think about how they can take away the bulk of repetitive, mundane tasks from developers’ to-do lists. Instead of a workload ratio where 80% of the tasks are mundane and 20% are cutting-edge, they should strive for a flipped ratio, one where 80% of the tasks drive innovation and 20% serve more functional purposes.
To achieve this flipped ratio, software leaders should apply the modularity principle, which states that systems “should be built from cohesive, loosely coupled components (modules),” to the architecture and design of modern digital platforms and software. They should also try to leverage automation instead of human processes where possible. Furthermore, software teams must abandon the idea that they must reinvent the wheel every time. There’s a certain point where what works, works. Making micro-improvements to standard processes that already work will lead to results that add minimal value, if any. In almost all cases, simplification is the best policy.
Here’s an analogy to consider: LEGO bricks. With the classic 2×4 LEGO brick, you can build almost any structure. But sometimes, to reach their goals, enterprises put aside the “classics” that would have gotten them there faster. That’s where solid foundations step in. In our experience, solid foundations power distributed reusability, enabling software developers to use “off the shelf” components that have already been developed so they can focus on innovating where it counts.
In fact, according to McKinsey, there are “inner loop” and “outer loop” tasks in software development. Inner loop tasks are “directly related to creating the product: coding, building, and unit testing,” whereas outer loop tasks are ones developers “must do to push their code to production: integration, integration testing, releasing, and deployment.” McKinsey notes that at the top tech companies, the goal is for developers to “spend up to 70 percent of their time doing inner-loop activities.”
Scaling back is critical. By simplifying and reusing processes and code where appropriate, companies can save time and money, freeing up their developers to do what they best.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
Read the full article here
