Prioritization and Perfectionism

You probably heard about the Pareto principle. It states that (approximately) 80% of consequences (effects) come from 20% of causes. For example, roughly 80% of customer complaints usually come from around 20% of customers. Another example is related to the World economy: approximately 20% of the population receives approximately 80% of the world's income. There are many other examples of this phenomenon.

So, how is this related to software development? It is about choosing a smaller subset of available backlog ideas (hypothesis) to focus on in order to create the biggest possible benefit for the business.

There are usually more ideas in every teams' backlog than there is time and human capacity for delivery to production. Wisely choosing which ideas to implement, and which to drop or delay, makes a difference between success or failure.

This article is about 3 things:

• Why most people will verbally agree on what is essential but still fail to think (and act) accordingly
• What to do about the prioritization
• Exceptions — when is perfectionism necessary

Why do we waste time and effort on less important things?

For many teams, it can be difficult to accept that they are going to build something imperfect. We often hear reasoning like this:

“We want to make the best product in the world! Improvements are easy to spot, so why don’t include all of them!? Let’s optimize and automate everything! Let’s add more things to cover more use cases!”

But thinking and acting like this often ends up in failure, disappointment, and late releases because teams capacity to deliver and maintain things is limited. Engineers who smartly choose where to invest their time always have a bigger positive impact than the ones who are not picky about the priorities. Remember that software development (and maintenance) is an investment, and it is usually quite costly.

So, why many teams don't prioritize and optimize for the biggest business impact? Here are two common reasons: 1) scoring in education is not the same as at work and 2) technology fashion. I am sure that there are more, like for example "gold plating" and others, but to keep this article short let's focus on these two reasons: 1) scoring and 2) technology fashion.

1. Scoring performance at work is not the same as at universities

In acedemia, we got our grades (acknowledgement and sense of achievement) based on how close to perfection and correct results we did on the exams. The famous saying “you get what you measure” applies here — good students chase perfect grades. But the success of building technology in a business environment has only one measure - achieved profit and value.

Organizations also have scoring systems for employees often called "performance reviews". Because at work there are no exams with points like in universities, employees sometimes look for things under their control which they can make “perfect”, hoping to show their value and contribution. Sometimes team members disregard the usefulness (impact on revenue, for example) for the sake of making their solution impressive and getting the recognition and admiration. But our salaries do not come from our colleagues tapping us on our shoulders, they come from the company's revenue.

Fear of being perceived as an underachiever makes some professionals chase perfection even though perfection may not be relevant for the business. They fix their efforts on something that they can do, instead of something they should do. Product and Engineering teams can waste a lot of time like this.

Besides, sometimes engineers don’t always know what is essential for the business at the moment, and can miss the target even if they try to optimize for profit. This is where managers either help or hinder, and a big value of good management is in communicating the business context to the teams.

2. Technology fashion

Another reason for chasing perfection may be measuring our work against the most famous in our domain of technology. Popular authors and blogs create technology fashion and there is a prestige in following the latest popular trends.

Let's take an example from the automotive industry to make the point. Everyone knows and admires Ferrari. They make luxurious fast cars on the right part of the Usefulness/Effort graph, close to perfection. You can downplay most other cars by comparing them to a Ferrari.

For example Fiat Panda looks quite poor next to a famous red sports car.

However, FIAT company bought the Ferrari's business (90% ownership in 1988) and that FIAT's revenue is around 30 times bigger than Ferrari's. FIAT produces mostly ordinary, dull cars that fulfil 99% of all the daily needs for transport — and it’s a giant company. Much bigger than Ferrari. It’s an excellent example of how the graph works. FIAT excels on the left part of the graph, and they make much more money than the most famous producer of fancy cars.

It is similar in software engineering. Each era has a set of modern technologies. They become favored by people telling success stories, and these days, via aggressive marketing. Decades ago it was COBOL, for example. Today it’s the Kubernetes, serverless, event sourcing, etc.

Following trends and fashion in technology without proper analysis on how will it bring benefit to your business - will likely have a negative financial effect for the company.

Adding the technical debt

The more features and logic we implement in a system, the more complexity and potential technical debt we introduce. Many features will be of low value but they will still add technical debt as likely as the most useful ones. The “price” (overall investment) in any feature consists not only of the time and money we need to develop it but also of post-release expenses (maintenance, bug fixes, technical debt and added complexity). These costs are a part of OpEx (Operational expenses) which directly diminish the profit and the value of a company.

What to do about this?

Promote a different definition of perfection and a culture built around profit optimization.

Perfection in engineering is an optimal ratio of usefulness and effort to release the product (increment)

The best technique for measuring the impact and evaluating the needed effort depend on the context, teams and business, so we need to select one and refine it. But without some sort of data insights we won't be able to make good decisions about prirorities.

The same prioritization principle is applicable to personal workload of any engineers. All of us often need to make micro-decisions about what to focus or day and hours on. Of course, data (measures) is not the same for one person workload and the entire team, but the principle remains the same - prioritize things that make the most impact. And if you don't know what the impact is - seek clarifications.

Exceptions

There are situations where perfectionism is necessary, or at least as close to perfectionism as possible. These are usually mission critical things that can endanger human lives or jeopardize many people's wellbeing. Some examples include flight control systems, critical medical equipment, stock exchange systems, etc. These are the high-risk areas where we can not trade off much.