This is a form of the famous Pareto rule: roughly 80% of the effects (“Usefulness”) come from 20% of the causes (“Efforts”).
But this article is not about the Pareto principle; it is about the development of software systems and technology. Specifically:
- Why most people will verbally agree on what is essential but still fail to think (and act) accordingly
- What to do about it
- Exceptions — when is perfectionism necessary
It can be difficult to accept that we are going to build something imperfect.
“We want to make the best product! Improvements are easy to spot, so why don’t include them!? Let’s build a future-proof system, optimize and automate everything! Let’s add more things to cover more use cases!”
Thinking like this often ends up in failure, disappointment and late releases.
I am trying to figure out why do we think like this. It is easy to propose a gazillion methodologies to “solve” this issue (Scrum works to address it, but it fails if not implemented correctly). Solution always depends on the context. I would instead like to understand why we lose the focus on essential things.
Maybe because in school, we got our grades (acknowledgement and sense of achievement) based on how close to perfection we did on the exams? The famous saying “you get what you measure” applies here — good students chase perfect grades.
I recommend the book “Surely You’re Joking, Mr. Feynman!”. If you don’t have the time to read it (which would be a pity), here is a short excerpt that shows how people focus on less important things in education.
Organizations have scoring systems that indicate who can do bad/good/best work. Because there are no grades, we are looking for things under our control which we can make “perfect”, hoping that they will show our value and contribution. We disregard the usefulness (impact on revenue, for example).
Fear of being perceived as an underachiever makes us chase perfection even though it may not be relevant. We fix our efforts on something that we believe we can successfully do, instead of something beneficial we should do. We can waste a lot of time like this.
Besides, we don’t always know what is essential for the business at the moment, so we miss the target.
Another reason for chasing perfection (sub-optimal value) may be measuring our work against the most famous in our domain. Someone set the bar in your community, and many are copying them.
Everyone knows and admires Ferrari. They make cars on the right part of the graph, close to perfection. You can downplay and ridicule (almost) any car by comparing it to a Ferrari.
Fiat Panda looks stupid compared to it. Look.
But nobody talks about the fact that FIAT bought Ferrari (90% ownership in 1988) and that their revenue is ~30 times bigger. FIAT produces mostly ordinary, dull cars that fulfill 99.9% of all the daily needs for transport — and it’s a giant company. 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 Ferrari.
It is similar in software engineering. Each era has a set of modern technologies. They become favoured 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 without an exact plan on how will it bring benefit to your business doesn’t sound right.
Promote a different definition of perfection.
Achieving perfection in technology is impossible because requirements continuously change. Everything we ever develop will one day be deleted and will reach the end of the life cycle.
I think we need to redefine “perfection” like this:
Optimal means: a measure of contribution to the business vs time and resources needed to deliver it. (Still sounds complicated, can we simplify? Any ideas?)
There are methods to measure the value/contribution, but let’s not go there. The best technique depends on the context, teams and business, and this article is already long.
The goal is that your teams reach a level of maturity when they don’t need a process or a person who decides what is optimal. The teams can autonomously make better decisions if they go for a different kind of perfection.
It is so much easier if managers support “the graph”.
One simple thing that anyone can do is, for example, ask: “How will this benefit our revenue in the next month or two?”. And then leave it. Don’t push. The goal is to kick-start the mindset, water it until it becomes the standard.
There are situations where anything less than perfection equals disaster. Some examples include flight control, brain surgery, the up-time of the stock exchange systems. These are the high-risk areas where releasing imperfect products makes no sense.