Vor einigen Jahren hätte ich “Perfektionismus” wahrscheinlich noch als wünschenswerte Eigenschaft für Entwickler angesehen. Mittlerweile weiß ich, dass Perfektionismus lähmend wirkt.

Das heißt auch nicht, dass man das Gegenteil praktizieren soll und alles immer nur “Husch-Pfusch” erledigt. Vielmehr sollte man sich immer das viel zitierte Pareto-Prinzip vor Augen halten. Das Prinzip wurde nach dem italienischen Ökonomen Vilfredo Pareto benannt, der Anfang des 20. Jahrhunderts beobachtete, dass 80 % des Landbesitzes in Italien im Besitz von 20 % der Bevölkerung waren. Später wurde diese Beobachtung auf andere Lebensbereiche übertragen, z. B.:

80 % der Ergebnisse entstehen durch 20 % des Aufwands.
80 % der Beschwerden kommen von 20 % der Kunden.
80 % des Umsatzes stammen von 20 % der Produkte.

Es ist wichtig zu verstehen, dass die Verteilung nicht exakt 80/20 sein muss. Der eigentliche Kern ist, dass ein kleiner Teil der Ursachen für einen Großteil der Wirkungen verantwortlich ist (Prinzip der ungleichen Verteilung).

Pareto-Prinzip in der Softwareentwicklung

Mehrere Studien untermauern dieses Prinzip auch für die Softwareentwicklung. So untersuchte eine Studie von Szymański und Ochodek (2023) das Wachstum von Open-Source-Code-Repositories und fand heraus, dass 75 % des finalen Codes innerhalb der ersten 25 % der Projektlaufzeit erstellt wurden. Dies deutet auf eine ungleichmäßige Verteilung der Entwicklungsaktivität hin, die dem Pareto-Prinzip ähnelt.

Jeder kennt auch die Entwickler, die alles perfekt machen wollen und unbedingt noch dieses und jenes Feature implementieren wollen. Hierbei sollte man sich vor Augen halten, dass 80 Prozent der Features nie oder fast nie genutzt werden.

Aus diesem Grund wird in der “Scrum-Bibel” 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.

Aus der Erfahrung meiner Tätigkeit als CEO eines Softwareunternehmens empfehle ich dringend, sich immer diese Erkenntnisse vor Augen zu halten. Gerade zu Beginn meiner Karriere habe ich viel Energie in erweiterte Features gesteckt, zum Beispiel in besonders gutes Datenhandling oder tiefgehende Analysefunktionen für unsere Anlagen. Heute weiß ich: Für fast alle alltäglichen Analysen reichen die Basisfunktionen vollkommen aus. Und selbst wenn einmal eine erweiterte Analyse gebraucht wird, ist es oft so, dass der Standard-Anwender entweder vergessen hat, wie man das Feature benutzt, oder gar nicht mehr weiß, dass es überhaupt existiert. Ich würde das Pareto-Prinzip deshalb sogar etwas umformulieren:

“Wenn 80 Prozent des Umsatzes von 20 Prozent der Produkte kommen, hast du den Großteil deiner Zeit verbrannt”.

Aber wie so oft im Leben, ist es einfacher, Dinge in der Theorie zu verstehen, als sie auch praktisch umzusetzen. Ich glaube, ein wesentlicher Punkt in der Umsetzung des Pareto-Prinzips, um Ressourcen nicht zu “verbrennen”, ist es, Perfektionismus gezielt zu reduzieren.

Perfektionismus vermeiden und “einfach mal machen”

Wenn man eine Firma aufbaut, muss man gewaltig viele Entscheidungen treffen. Im Falle von Unternehmen mit hohem Entwicklungsanteil fallen darunter folgende Entscheidungen:

Wie strukturieren wir unsere Zusammenarbeit? (Remote vs. Office, agile vs. klassisch)
Welche internen Tools brauchen wir? (Projektmanagement, Doku, Kommunikation)
Welche Kommunikationstools verwenden wir? (Slack, MS Teams, Discord)
Welche Versionsverwaltung verwenden wir, und wo wird unser Code gehostet? (z. B. GitHub, GitLab, Bitbucket)
Wie organisieren wir Codequalität, Testing, CI/CD, Releases?
Welcher Tech-Stack ist für unsere Anforderungen langfristig sinnvoll? (Frontend, Backend, Datenbank, Infrastruktur)
Wie managen wir Abhängigkeiten und Paketversionen?
Wie tracken und priorisieren wir Bugs und Features?
Welche Coding-Standards und Code-Reviews etablieren wir?
Wie dokumentieren wir unser Wissen? (Notion, Confluence, GitHub Wiki, …)
Wie führen wir neue Entwickler ins Projekt ein? (Onboarding-Doku, Mentoring, Setup-Skripte)

Wenn man alle diese Fragen bis ins kleinste Detail analysieren will, um sie “optimal” zu beantworten, wird man vor einer Mammutaufgabe stehen. Vor allem gibt es bei den meisten dieser Fragen auch kein “richtig” oder “falsch”, sondern manche Ansätze sind mehr oder weniger fürs eigene Vorhaben geeignet. Wenn man etwa nach Projektmanagement-Tools sucht, wird man davon Hunderte finden. Dazu tausende Blogartikel, Forum-Posts und Reviews. Jeweils mit anderen Schlussfolgerungen und Empfehlungen.

Meine Empfehlung zu all diesen Fragen und Entscheidungen:

“Einfach mal machen!”

Ich würde jedem folgende Herangehensweise empfehlen:

Seine eigenen Anforderungen kurz niederschreiben
Suchen, welche Tools diese erfüllen
Hat man eines, bei dem die meisten Punkte erfüllt sind, gleich damit starten und nicht mehr nach einem noch besseren Tool suchen!

Wie schon erwähnt: In der Praxis nutzt man von den meisten Tools ohnehin nur einen Bruchteil der Features regelmäßig. Wenn ein Tool die Basics gut abdeckt, lohnt es sich kaum, Wochen mit der Suche nach einer vermeintlich noch besseren Alternative zu verbringen.

Gerade in der Gründungsphase ist das ein entscheidender Vorteil gegenüber großen Unternehmen: Wir können schnell entscheiden – und sollten das auch tun.

Mut zur Entscheidung: Geschwindigkeit schlägt Perfektion

Selbst wenn man mal eine falsche Entscheidung trifft, ist es viel weniger schwerwiegend als man denkt. Viel schwerwiegender sind langsame Entscheidungen. Und das sage nicht ich, sondern einer der erfolgreichsten Unternehmer überhaupt: Jeff Bezos, der Gründer von Amazon. Dieser unterscheidet zwischen zwei Arten von Entscheidungen:

Typ-1-Entscheidungen: Diese sind bedeutend und irreversibel – sogenannte „Einbahnstraßen“. Sie sollten sorgfältig, langsam und mit viel Überlegung getroffen werden. [1]
Typ-2-Entscheidungen: Diese sind reversibel – sogenannte „Zweibahnstraßen“. Sie können schnell von Einzelpersonen oder kleinen Gruppen mit gutem Urteilsvermögen getroffen werden. Wenn sich eine solche Entscheidung als suboptimal herausstellt, kann man sie leicht rückgängig machen. [1]

Bezos betont, dass die meisten Entscheidungen vom Typ 2 sind und daher zügig getroffen werden sollten. Er warnt davor, in großen Organisationen alle Entscheidungen wie Typ-1-Entscheidungen zu behandeln, da dies zu Langsamkeit, übermäßiger Risikovermeidung und mangelnder Innovation führt. [1]

In seinem Aktionärsbrief von 2017 führt Bezos weiter aus, dass Entscheidungen oft mit etwa 70 % der gewünschten Informationen getroffen werden sollten. Wartet man auf 90 %, ist man in den meisten Fällen wahrscheinlich zu langsam. Er betont, dass es wichtiger ist, schnell zu entscheiden und bei Bedarf Kurskorrekturen vorzunehmen, da Verzögerungen teuer sein können. [1]

Schnell entscheiden, später korrigieren – Beispiele aus meinem Alltag

Wissensdatenbank

Ab dem ersten Mitarbeiter war für mich klar: Eine Wissensdatenbank ist unabdingbar. Da wir mechatronische Systeme erst durch Software zum Leben erwecken, gibt es naturgemäß unzählige Kleinigkeiten, die trivial erscheinen, aber einfach gewusst werden müssen. Andernfalls verbrennt man enorm viel Zeit beim Entwickeln oder Debuggen. Dazu zählen etwa Konfigurationseinstellungen für Motion-Anwendungen, spezifische Hardware-Kombinationen oder Eigenheiten in der Ansteuerung.

Reine Wissensdatenbank-Tools sind heute selten, meist sind sie Teil größerer Plattformen mit Projektmanagement, Git-Integration oder Time-Tracking.

Auf Empfehlung meiner Frau probierte ich zuerst Easy Redmine aus, das sie von ihrem damaligen Arbeitgeber kannte. Zwei Tage später zeigte ich es einem Kollegen und wir konnten nicht mal die einfachsten Dinge darin anlegen. Der Höhepunkt war ein Anruf vom Anbieter, bei dem uns eine mehrtägige Schulung angeboten wurde, um das Tool überhaupt bedienen zu können.
Für mich ein No-Go: Projektmanagement-Tools und Wissensdatenbanken sollen das Leben einfacher machen – nicht komplizierter. Wenn ich zuerst eine Schulung brauche, um ein Taskboard zu bedienen, erhöht das nicht die Effizienz, sondern den Frust. Noch heute scherze ich mit meiner Frau über – wie ich es nenne – „Hard Redmine“.

Danach testete ich Confluence von Atlassian. Es war sofort intuitiv zu bedienen, das Feature-Set schien umfangreich und zukunftssicher. Auch meine Kollegen kamen auf Anhieb damit klar. Damit war schnell klar: Wir nehmen die Atlassian-Welt. Somit hatten wir mit Jira auch gleich das Tool für das Projektmanagement und mit Bitbucket jenes für die Git-Verwaltung. Sofort führten wir alles ein, ohne weitere mögliche Tools zu analysieren. Die Entscheidung hat sich bis heute als richtig erwiesen, vor allem da wir für das Time-Tracking später auf Tempo setzen konnten. Dies war möglich, da Atlassian offene Schnittstellen für 3rd-Party-Plugins bietet.

Trotzdem hatten wir anfangs große Probleme mit unserer Wissensdatenbank – nicht wegen Confluence, sondern weil wir es falsch nutzten. Wir führten es ohne Plan ein und legten einfach alles an, was irgendwie nach „Wissen“ klang.

In unseren frühen „Knowledge-Base“-Spaces finden sich heute noch Ordner mit dem Titel „Legacy“, gefüllt mit völlig unnützem Zeug: Seiten voller Konfigurationen, die man mit einer Google-Suche sofort auf Beckhoff Infosys findet. Oder Notizen zu YouTube-Tutorials, von denen wir dachten, sie würden „noch mal ultra wichtig“. Spoiler: Wurden sie nicht.

Heute halten wir uns an ein paar einfache Prinzipien für unsere Wissensdokumentation:

Dokumentiere nichts, was man nicht auch innerhalb kürzester Zeit via Google oder ChatGPT nachsehen kann.
So wenig wie möglich, so viel wie nötig.
Verwendet vordefinierte Space-Templates.
Je mehr Zeit eine Dokumentation einsparen kann, desto eher sollte man sie erstellen.

Abhängigkeiten und Paketversionen

Wenn man, wie wir, Software komplett selbst entwickelt, steht man schnell vor der Frage, wie man eigene Libraries sinnvoll managt. In der klassischen PLC-Welt gibt es dazu leider kaum gute Vorbilder. Die wenigen, die es gab, warnten zu Recht vor einer „Dependency Hell“.
Deshalb entwickelten wir parallel zum ersten Projekt eine eigene Standard-Library, in der wir all unsere Basisklassen bündelten.
Leider schrieben wir zu diesem Zeitpunkt keine Unit-Tests. Entsprechend viele Bugs hatten wir. Mit Mühe und Not konnten wir unser erstes größeres Projekt mit TwinCAT gerade noch abschließen.
Eine echte „Dependency Hell“ hatten wir zwar nicht – wir hatten nur eine einzige Library, die alles enthielt. Aber dafür war diese eine Library … „hell“ genug.

Die nächsten beiden Projekte standen an. Beide mit knackigen Deadlines.
Uns war klar: Wir brauchen Libraries, die sauber getrennt sind und vor allem solche, die konsequent mit Unit-Tests abgesichert sind. Aber wie sollten wir das alles so schnell aufsetzen? Die Herausforderungen waren klar:

Wir brauchen eine PLC-Runtime – lokal und für automatisierte Tests.
Bitbucket allein reicht nicht – wir brauchen zusätzlich ein CI/CD-System, das zu unserer TwinCAT-Welt passt.
Wie releasen wir unsere Libraries? Jeden Tag eine neue Version rausschieben?
Was passiert, wenn jemand während einer Inbetriebnahme kurzfristig die Library ändern muss – sei es für einen Bugfix oder ein neues Feature?

Für all das war keine Zeit. Aber das Wichtigste konnten wir parallel zur Projektentwicklung einführen: Unit-Tests.
Wir schrieben fast alles neu, aber diesmal in thematisch getrennten Libraries und sauber getestet.
Statt einer automatisierten Pipeline wusste einfach jeder: Bevor du Änderungen zum Mergen auf den Main-Branch freigibst, lässt du alle Tests laufen. Punkt.

In einem kleinen Team funktioniert das problemlos – mit unkomplizierter Kommunikation über Teams oder direkt im Büro. Auch die Versionierung war einfach: War es eine wichtige Änderung, die Bugs korrigierte oder neue Features brachte, schrieb man in den dafür vorgesehenen Teams-Chat. Nur selten gab es Änderungen, die z. B. die Signatur von Methoden betrafen und Auswirkungen auf bestehenden Code hatten. Auch das wurde kurz kommuniziert – und jeder updatete sein Programm entsprechend.

Natürlich ist es sauberer, Libraries zu versionieren und bei Bedarf auf eine Version zu “freezen”.
Aber was wir brauchten, war: „ausreichend sauber, aber verdammt schnell“. Genau das haben wir mit unserer Methode erreicht. Die Abläufe waren manchmal chaotischer als nötig, aber der Code war dieses Mal richtig sauber. Auch hier ist der Code sicherlich jenes „Feature“, dem gemäß dem Pareto-Prinzip die meiste Aufmerksamkeit gewidmet werden sollte.

Fast Forward:
Beide Projekte wurden mit Bravour gemeistert.
Unsere Libraries haben wir mittlerweile – als Beckhoff Solution Partner – per OEM-Lizenz herausgegeben. Jede Woche halten wir unser „TwinCAT-Library“-Meeting, in dem die neuesten Features und Änderungen besprochen werden, und mittlerweile erkennt jeder im Team schon an der Versionsnummer, welchen Grad an Änderung gemacht wurde.

Auch hier zeigte sich mal wieder: einfach mal machen! Auch wenn es vielleicht nicht von Anfang an perfekt ist – perfekt werden kann es mit der Zeit.

Meine Tool-Favoriten und warum

Kommunikation – Microsoft Teams

Mittlerweile ohnehin Standard.
Funktioniert einfach, ist weit verbreitet und reicht für unsere Anforderungen völlig aus.

Projektmanagement – JIRA

Gerade weil ich mittlerweile auch sehr gerne agil arbeite.
In dem Zusammenhang kann ich übrigens das Scrum-Buch empfehlen.
Natürlich machen wir auch hier nicht alles perfekt – aber wir probieren es zumindest ernsthaft.

Wissensdatenbank – Confluence

Meiner Meinung nach extrem intuitiv, übersichtlich und einfach zu bedienen.
Vor allem in Verbindung mit JIRA ideal – da es aus derselben Tool-Welt kommt und nahtlos integriert ist.

Versionsverwaltung – Bitbucket

Git ist ohnehin gesetzt.
Wo genau die Repos gehostet werden, ist mir ehrlich gesagt nicht so wichtig –
Bitbucket war einfach die logische Wahl in der Atlassian-Welt.

Time-Tracking – Tempo

Die ideale 3rd-Party-Ergänzung zu JIRA.
Bei uns muss jede einzelne Minute einem Projekt-, Entwicklungs- oder allgemeinen Task zugeordnet werden.
Ich halte das für extrem wichtig, vor allem wenn es um die Generierung von belastbaren Aufwandsschätzungen geht.
Mehr dazu auch im zweiten Blogpost.

Worauf es wirklich ankommt

Wenn ich heute zurückblicke, waren nicht die perfekten Konzepte entscheidend – sondern die Entscheidungen selbst. Die Projekte, die funktioniert haben, waren nie von Anfang an ideal geplant. Aber sie wurden umgesetzt, getestet, angepasst.

Perfektion ist kein Ziel, sondern ein Prozess. Wer ständig alles zerdenkt, verliert den Vorteil des Handelns.

Deshalb mein Fazit – für alle, die mit Software, Teams oder Produkten starten:
Trefft schnelle Entscheidungen. Lernt daraus. Verbessert euch.

Denn gute Systeme entstehen nicht durch Zögern – sondern durchs Tun.

Perfektionismus als Gift