A few years ago, I would probably have considered “perfectionism” to be a desirable quality for developers. I now know that perfectionism is paralyzing.

That doesn’t mean you should do the opposite and always tackle everything with slapdash work. Rather, you should always keep the well-known Pareto Principle in mind. The principle was named after the Italian economist Vilfredo Pareto, who observed in the early 20th century that 80% of land ownership in Italy was held by 20% of the population. Later, this observation was applied to other areas of life, such as:

• 80% of the results come from 20% of the effort.
• 80% of complaints come from 20% of customers.
• 80% of revenue comes from 20% of products.

It is important to understand that the distribution does not have to be exactly 80/20. The actual core is that a small portion of the causes is responsible for a large portion of the effects (principle of unequal distribution).

Pareto principle in software development

Several studies also support this principle in software development. For example, a study by Szymański and Ochodek (2023) examined the growth of open-source code repositories and found that 75% of the final code was created within the first 25% of the project’s lifespan. This indicates an unequal distribution of development activity akin to the Pareto Principle.

Everyone is also familiar with developers who want everything to be perfect and insist on implementing this or that feature. Here, it’s important to keep in mind that 80 percent of features are never or almost never used.

For this reason, the “Scrum bible” empfohlen, alle möglichen Features aufzuschreiben, dann auf Tasks herunterzubrechen und diese dann im Backlog nach Priorität zu ordnen. Danach werden die wichtigsten Features zuerst angegangen, um schnell zu einem Minimum Viable Product (MVP) zu gelangen. Ein MVP ist die kleinstmögliche Version eines Produkts, die gerade genug Funktionen bietet, um den Kernnutzen zu liefern und Feedback von echten Nutzern zu sammeln. Ziel ist es, schnell zu validieren, ob ein Produktkonzept in der Praxis funktioniert, bevor viel Zeit und Geld in die vollständige Entwicklung investiert wird.

From my experience as CEO of a software company, I strongly recommend always keeping these insights in mind. Especially at the beginning of my career, I put a lot of energy into advanced features, for example particularly good data handling or in-depth analysis functions for our systems. Today I know that the basic functions are perfectly adequate for almost all day-to-day analyses. And even if an advanced analysis is needed, it is often the case that the standard user has either forgotten how to use the feature or no longer even knows that it exists. I would therefore even reformulate the Pareto principle slightly:

“If 80 percent of your sales come from 20 percent of your products, you've burnt most of your time.”

But as is so often the case in life, it is easier to understand things in theory than to actually apply them in practice. I believe that a key point in implementing the Pareto principle in order to avoid “burning” resources is to reduce perfectionism in a targeted manner.

Avoid perfectionism and “just do it”

When you set up a company, you have to make a huge number of decisions. In the case of companies with a high proportion of development, this includes the following decisions:

• How do we structure our collaboration? (remote vs. office, agile vs. classic)
• What internal tools do we need? (project management, documentation, communication)
• Which communication tools do we use? (Slack, MS Teams, Discord)
• Which version control system do we use and where is our code hosted? (e.g. GitHub, GitLab, Bitbucket)
• How do we organize code quality, testing, CI/CD, releases?
• Which tech stack makes sense for our requirements in the long term? (frontend, backend, database, infrastructure)
• How do we manage dependencies and package versions?
• How do we track and prioritize bugs and features?
• What coding standards and code reviews are we establishing?
• How do we document our knowledge? (Notion, Confluence, GitHub Wiki, ...)
• How do we introduce new developers to the project? (Onboarding documentation, mentoring, setup scripts)

If you want to analyze all these questions down to the smallest detail in order to answer them “optimally”, you will be faced with a mammoth task. Above all, there is no “right” or “wrong” answer to most of these questions, but some approaches are more or less suitable for your own project. If you search for project management tools, for example, you will find hundreds of them. Plus thousands of blog articles, forum posts and reviews. Each with different conclusions and recommendations.

My recommendation for all these questions and decisions:

“Just do it!”

I would recommend the following approach:

• Briefly write down your own requirements
• Search which tools fulfill these requirements
• If you have one that meets most of the criteria, start using it straight away and stop looking for an even better tool!

As already mentioned, in practice you only use a fraction of the features of most tools on a regular basis anyway. If a tool covers the basics well, it's hardly worth spending weeks searching for a supposedly even better alternative.

This is a decisive advantage over large companies, especially in the start-up phase: We can decide quickly - and should do so.

Courage to make decisions: speed beats perfection

Even if you make a wrong decision, it is much less serious than you think. Slow decisions are much more serious. And it's not me saying that, but one of the most successful entrepreneurs ever: Jeff Bezos, the founder of Amazon. He distinguishes between two types of decisions.

• Type 1 decisionsThese are significant and irreversible - so-called “one-way streets”. They should be taken carefully, slowly and with a lot of thought. [1]
• Type 2 decisionsThese are reversible - so-called “two-way streets”. They can be made quickly by individuals or small groups with good judgment. If such a decision turns out to be suboptimal, it can easily be reversed. [1]

Bezos emphasizes that most decisions are type 2 and should therefore be made quickly. He warns against treating all decisions in large organizations as type 1 decisions, as this leads to slowness, excessive risk avoidance and a lack of innovation.[1]

In his 2017 letter to shareholders, Bezos goes on to say that decisions should often be made with around 70% of the desired information. If you wait for 90%, you are probably too slow in most cases. He emphasizes that it is more important to decide quickly and make course corrections when necessary, as delays can be costly.[1]

Decide quickly, correct later - examples from my everyday life

Knowledge Base

From the very first employee, it was clear to me that a knowledge database was indispensable. As we only bring mechatronic systems to life through software, there are naturally countless little things that seem trivial but simply have to be known. Otherwise, a huge amount of time is wasted during development or debugging. These include configuration settings for motion applications, specific hardware combinations or peculiarities in the control system.

Pure knowledge base tools are rare these days; they are usually part of larger platforms with project management, Git integration or time tracking.

On my wife's recommendation, I first tried Easy Redmine, which she knew from her former employer. Two days later, I showed it to a colleague and we couldn't even create the simplest things in it. The highlight was a call from the provider offering us several days of training to be able to use the tool at all.
A no-go for me: project management tools and knowledge databases should make life easier - not more complicated. If I first need training to use a task board, it doesn't increase efficiency, it increases frustration. I still joke with my wife today about what I call “Hard Redmine”.

I then tested Confluence from Atlassian. It was immediately intuitive to use, the feature set seemed extensive and future-proof. My colleagues also got to grips with it straight away. So it quickly became clear: we would go with the Atlassian world. With Jira, we also had the tool for project management and Bitbucket for Git management. We implemented everything immediately without analyzing other possible tools. The decision has proven to be the right one to this day, especially as we were later able to rely on Tempo for time tracking. This was possible because Atlassian offers open interfaces for 3rd party plugins.

Nevertheless, we initially had major problems with our knowledge base - not because of Confluence, but because we were using it incorrectly. We introduced it without a plan and simply created everything that somehow sounded like “knowledge”.

In our early “knowledge base” spaces, you can still find folders with the title “Legacy”, filled with completely useless stuff: pages full of configurations that you can immediately find on Beckhoff Infosys with a Google search. Or notes on YouTube tutorials that we thought would be “ultra important again”. Spoiler: They weren't.

Today we stick to a few simple principles for our knowledge documentation:

• Don't document anything that can't be looked up within a very short time via Google or ChatGPT.
• As little as possible, as much as necessary.
• Uses predefined space templates.
• The more time documentation can save, the sooner it should be created.

Dependencies and package versions

If, like us, you develop software completely yourself, you are quickly faced with the question of how to manage your own libraries sensibly. Unfortunately, there are hardly any good role models for this in the classic PLC world. The few that did exist rightly warned of “dependency hell”.
That's why we developed our own standard library in parallel to the first project, in which we bundled all our base classes.
Unfortunately, we were not writing any unit tests at the time. As a result, we had a lot of bugs. We were only just able to complete our first major project with TwinCAT.
We didn't have a real “dependency hell” - we only had a single library that contained everything. But this one library was ... “bright” enough.

The next two projects were on the agenda. Both with tight deadlines.
It was clear to us that we needed libraries that were cleanly separated and, above all, libraries that were consistently secured with unit tests. But how were we supposed to set all this up so quickly? The challenges were clear:

• We need a PLC runtime - locally and for automated tests.
• Bitbucket alone is not enough - we also need a CI/CD system that fits our TwinCAT world.
• How do we release our libraries? Push out a new version every day?
• What happens if someone has to change the library at short notice during commissioning - be it for a bug fix or a new feature?

There was no time for all that. But we were able to introduce the most important thing in parallel with the project development: Unit tests.
We rewrote almost everything, but this time in thematically separate libraries and properly tested.
Instead of an automated pipeline, everyone simply knew: Before you release changes for merging to the main branch, you run all tests. Period.

In a small team, this works without any problems - with uncomplicated communication via Teams or directly in the office. Versioning was also simple: if there was an important change that corrected bugs or brought new features, you wrote in the Teams chat provided for this purpose. Only rarely were there changes that affected the signature of methods, for example, and had an impact on existing code. This was also communicated briefly - and everyone updated their program accordingly.

Of course, it is cleaner to version libraries and “freeze” them to one version if necessary.
But what we needed was: “sufficiently clean, but damn fast”. That's exactly what we achieved with our method. The processes were sometimes more chaotic than necessary, but the code was really clean this time. Again, the code is certainly the “feature” that should be given the most attention according to the Pareto principle.

Fast Forward:
We mastered both projects successfully.
We have now released our libraries as a Beckhoff Solution Partner under an OEM license. Every week we hold our “TwinCAT Library” meeting, in which the latest features and changes are discussed, and now everyone in the team can tell by the version number what level of change has been made.

Once again, it showed: just do it! Even if it may not be perfect from the start - it can become perfect over time.

My favorite tools and why

Communication - Microsoft Teams

Now standard anyway.
It works simply, is widely used and is completely sufficient for our requirements.

Project management - JIRA

Especially because I now also enjoy working in an agile way.
By the way, in this context I can recommend the scrum book .
Of course, we don't do everything perfectly here either - but at least we try seriously.

Knowledge base - Confluence

In my opinion, it is extremely intuitive, clear and easy to use.
Especially ideal in combination with JIRA - as it comes from the same tool world and is seamlessly integrated.

Version management - Bitbucket

Git is prerequisite anyway.
Where exactly the repos are hosted is honestly not that important to me -
Bitbucket was simply the logical choice in the Atlassian world.

Time-Tracking – Tempo

The ideal 3rd party supplement to JIRA.
With us, every single minute has to be assigned to a project, development or general task.
I think this is extremely important, especially when it comes to generating reliable cost estimates.
More on this in the second blogpost.

What really matters

When I look back today, it wasn't the perfect concepts that were decisive - but the decisions themselves. The projects that worked were never ideally planned from the outset. But they were implemented, tested and adapted.

Perfection is not a goal, but a process. If you constantly overthink everything, you lose the advantage of taking action.

Therefore my conclusion - for all those who start with software, teams or products:
Make quick decisions. Learn from them. Improve yourselves.

Because good systems are not created through hesitation - but through action.