Vor einigen Jahren h\u00e4tte ich \u201cPerfektionismus\u201d wahrscheinlich noch als w\u00fcnschenswerte Eigenschaft f\u00fcr Entwickler angesehen. Mittlerweile wei\u00df ich, dass Perfektionismus l\u00e4hmend wirkt.<\/p>\n\n\n\n
Das hei\u00dft auch nicht, dass man das Gegenteil praktizieren soll und alles immer nur \u201cHusch-Pfusch\u201d erledigt. Vielmehr sollte man sich immer das viel zitierte Pareto-Prinzip vor Augen halten. Das Prinzip wurde nach dem italienischen \u00d6konomen Vilfredo Pareto<\/strong> benannt, der Anfang des 20. Jahrhunderts beobachtete, dass 80 % des Landbesitzes in Italien im Besitz von 20 % der Bev\u00f6lkerung<\/strong> waren. Sp\u00e4ter wurde diese Beobachtung auf andere Lebensbereiche \u00fcbertragen, z.\u202fB.:<\/p>\n\n\n\n Es ist wichtig zu verstehen, dass die Verteilung nicht exakt 80\/20 sein muss<\/strong>. Der eigentliche Kern ist, dass ein kleiner Teil der Ursachen f\u00fcr einen Gro\u00dfteil der Wirkungen verantwortlich ist<\/strong> (Prinzip der ungleichen Verteilung<\/em>).<\/p>\n\n\n\n Mehrere Studien untermauern dieses Prinzip auch f\u00fcr die Softwareentwicklung. So untersuchte eine Studie von Szyma\u0144ski und Ochodek (2023)<\/a> das Wachstum von Open-Source-Code-Repositories und fand heraus, dass 75\u202f% des finalen Codes innerhalb der ersten 25\u202f% der Projektlaufzeit erstellt<\/strong> wurden. Dies deutet auf eine ungleichm\u00e4\u00dfige Verteilung der Entwicklungsaktivit\u00e4t hin, die dem Pareto-Prinzip \u00e4hnelt.<\/p>\n\n\n\n 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<\/a>.<\/p>\n\n\n\n Aus diesem Grund wird in der \u201cScrum-Bibel<\/a>\u201d empfohlen, alle m\u00f6glichen Features aufzuschreiben, dann auf Tasks herunterzubrechen und diese dann im Backlog nach Priorit\u00e4t zu ordnen. Danach werden die wichtigsten Features zuerst angegangen, um schnell zu einem Minimum Viable Product<\/strong> (MVP<\/strong>) zu gelangen. Ein MVP ist die kleinstm\u00f6gliche 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\u00e4ndige Entwicklung investiert wird.<\/p>\n\n\n\n Aus der Erfahrung meiner T\u00e4tigkeit 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\u00fcr unsere Anlagen. Heute wei\u00df ich: F\u00fcr fast alle allt\u00e4glichen 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\u00df, dass es \u00fcberhaupt existiert. Ich w\u00fcrde das Pareto-Prinzip deshalb sogar etwas umformulieren:<\/p>\n\n\n\n \u201cWenn 80 Prozent des Umsatzes von 20 Prozent der Produkte kommen, hast du den Gro\u00dfteil deiner Zeit verbrannt\u201d.<\/strong><\/p>\n\n\n\n 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 \u201cverbrennen\u201d, ist es, Perfektionismus gezielt zu reduzieren.<\/p>\n\n\n\n Wenn man eine Firma aufbaut, muss man gewaltig viele Entscheidungen treffen. Im Falle von Unternehmen mit hohem Entwicklungsanteil fallen darunter folgende Entscheidungen:<\/p>\n\n\n\n Wenn man alle diese Fragen bis ins kleinste Detail analysieren will, um sie \u201coptimal\u201d zu beantworten, wird man vor einer Mammutaufgabe stehen. Vor allem gibt es bei den meisten dieser Fragen auch kein \u201crichtig\u201d oder \u201cfalsch\u201d, sondern manche Ans\u00e4tze sind mehr oder weniger f\u00fcrs 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.<\/p>\n\n\n\n Meine Empfehlung zu all diesen Fragen und Entscheidungen:<\/p>\n\n\n\n \u201cEinfach mal machen!\u201d<\/strong><\/p>\n\n\n\n Ich w\u00fcrde jedem folgende Herangehensweise empfehlen:<\/p>\n\n\n\n Wie schon erw\u00e4hnt: In der Praxis nutzt man von den meisten Tools ohnehin nur einen Bruchteil der Features regelm\u00e4\u00dfig. Wenn ein Tool die Basics gut abdeckt, lohnt es sich kaum, Wochen mit der Suche nach einer vermeintlich noch besseren Alternative zu verbringen.<\/p>\n\n\n\n Gerade in der Gr\u00fcndungsphase ist das ein entscheidender Vorteil gegen\u00fcber gro\u00dfen Unternehmen: Wir k\u00f6nnen schnell entscheiden \u2013 und sollten das auch tun.<\/strong><\/p>\n\n\n\n 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 \u00fcberhaupt: Jeff Bezos, der Gr\u00fcnder von Amazon. Dieser unterscheidet zwischen zwei Arten von Entscheidungen:\u200b<\/p>\n\n\n\n Bezos betont, dass die meisten Entscheidungen vom Typ 2 sind und daher z\u00fcgig getroffen werden sollten. Er warnt davor, in gro\u00dfen Organisationen alle Entscheidungen wie Typ-1-Entscheidungen zu behandeln, da dies zu Langsamkeit, \u00fcberm\u00e4\u00dfiger Risikovermeidung und mangelnder Innovation f\u00fchrt. \u200b<\/p>\n\n\n\n In seinem Aktion\u00e4rsbrief von 2017 f\u00fchrt Bezos weiter aus, dass Entscheidungen oft mit etwa 70\u202f% der gew\u00fcnschten Informationen getroffen werden sollten. Wartet man auf 90\u202f%, ist man in den meisten F\u00e4llen wahrscheinlich zu langsam. Er betont, dass es wichtiger ist, schnell zu entscheiden und bei Bedarf Kurskorrekturen vorzunehmen, da Verz\u00f6gerungen teuer sein k\u00f6nnen. \u200b<\/a>[1]<\/a><\/p>\n\n\n\n [1] Jeff Bezos on Fast, High Quality Decision-Making \u00b7 Rufus Pollock Online<\/a><\/p>\n\n\n\n Ab dem ersten Mitarbeiter war f\u00fcr mich klar: Eine Wissensdatenbank ist unabdingbar. Da wir mechatronische Systeme erst durch Software zum Leben erwecken, gibt es naturgem\u00e4\u00df unz\u00e4hlige Kleinigkeiten, die trivial erscheinen, aber einfach gewusst werden m\u00fcssen. Andernfalls verbrennt man enorm viel Zeit beim Entwickeln oder Debuggen. Dazu z\u00e4hlen etwa Konfigurationseinstellungen f\u00fcr Motion-Anwendungen, spezifische Hardware-Kombinationen oder Eigenheiten in der Ansteuerung.<\/p>\n\n\n\n Reine Wissensdatenbank-Tools sind heute selten, meist sind sie Teil gr\u00f6\u00dferer Plattformen mit Projektmanagement, Git-Integration oder Time-Tracking.<\/p>\n\n\n\n Auf Empfehlung meiner Frau probierte ich zuerst Easy Redmine aus, das sie von ihrem damaligen Arbeitgeber kannte. Zwei Tage sp\u00e4ter zeigte ich es einem Kollegen und wir konnten nicht mal die einfachsten Dinge darin anlegen. Der H\u00f6hepunkt war ein Anruf vom Anbieter, bei dem uns eine mehrt\u00e4gige Schulung angeboten wurde, um das Tool \u00fcberhaupt bedienen zu k\u00f6nnen. 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\u00fcr das Projektmanagement und mit Bitbucket jenes f\u00fcr die Git-Verwaltung. Sofort f\u00fchrten wir alles ein, ohne weitere m\u00f6gliche Tools zu analysieren. Die Entscheidung hat sich bis heute als richtig erwiesen, vor allem da wir f\u00fcr das Time-Tracking sp\u00e4ter auf Tempo setzen konnten. Dies war m\u00f6glich, da Atlassian offene Schnittstellen f\u00fcr 3rd-Party-Plugins bietet.<\/p>\n\n\n\n Trotzdem hatten wir anfangs gro\u00dfe Probleme mit unserer Wissensdatenbank \u2013 nicht wegen Confluence, sondern weil wir es falsch nutzten. Wir f\u00fchrten es ohne Plan ein und legten einfach alles an, was irgendwie nach \u201eWissen\u201c klang.<\/p>\n\n\n\n In unseren fr\u00fchen \u201eKnowledge-Base\u201c-Spaces finden sich heute noch Ordner mit dem Titel \u201eLegacy\u201c, gef\u00fcllt mit v\u00f6llig unn\u00fctzem 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\u00fcrden \u201enoch mal ultra wichtig\u201c. Spoiler: Wurden sie nicht.<\/p>\n\n\n\n Heute halten wir uns an ein paar einfache Prinzipien f\u00fcr unsere Wissensdokumentation:<\/p>\n\n\n\n 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 \u201eDependency Hell\u201c. Die n\u00e4chsten beiden Projekte standen an. Beide mit knackigen Deadlines. F\u00fcr all das war keine Zeit. Aber das Wichtigste konnten wir parallel zur Projektentwicklung einf\u00fchren: Unit-Tests. In einem kleinen Team funktioniert das problemlos \u2013 mit unkomplizierter Kommunikation \u00fcber Teams oder direkt im B\u00fcro. Auch die Versionierung war einfach: War es eine wichtige \u00c4nderung, die Bugs korrigierte oder neue Features brachte, schrieb man in den daf\u00fcr vorgesehenen Teams-Chat. Nur selten gab es \u00c4nderungen, die z.\u202fB. die Signatur von Methoden betrafen und Auswirkungen auf bestehenden Code hatten. Auch das wurde kurz kommuniziert \u2013 und jeder updatete sein Programm entsprechend.<\/p>\n\n\n\n Nat\u00fcrlich ist es sauberer, Libraries zu versionieren und bei Bedarf auf eine Version zu \u201cfreezen\u201d. Fast Forward:<\/strong> Auch hier zeigte sich mal wieder: einfach mal machen! Auch wenn es vielleicht nicht von Anfang an perfekt ist \u2013 perfekt werden kann es mit der Zeit.<\/p>\n\n\n\n Mittlerweile ohnehin Standard. Gerade weil ich mittlerweile auch sehr gerne agil arbeite. Meiner Meinung nach extrem intuitiv, \u00fcbersichtlich und einfach zu bedienen. Git ist ohnehin gesetzt.\n
Pareto-Prinzip in der Softwareentwicklung<\/h1>\n\n\n\n
Perfektionismus vermeiden und \u201ceinfach mal machen\u201d<\/h1>\n\n\n\n
\n
\n
Mut zur Entscheidung: Geschwindigkeit schl\u00e4gt Perfektion<\/h2>\n\n\n\n
\n
Schnell entscheiden, sp\u00e4ter korrigieren \u2013 Beispiele aus meinem Alltag<\/h2>\n\n\n\n
Wissensdatenbank<\/h3>\n\n\n\n
F\u00fcr mich ein No-Go: Projektmanagement-Tools und Wissensdatenbanken sollen das Leben einfacher machen \u2013 nicht komplizierter. Wenn ich zuerst eine Schulung brauche, um ein Taskboard zu bedienen, erh\u00f6ht das nicht die Effizienz, sondern den Frust. Noch heute scherze ich mit meiner Frau \u00fcber – wie ich es nenne – \u201eHard Redmine\u201c.<\/p>\n\n\n\n\n
Abh\u00e4ngigkeiten und Paketversionen<\/h3>\n\n\n\n
Deshalb entwickelten wir parallel zum ersten Projekt eine eigene Standard-Library, in der wir all unsere Basisklassen b\u00fcndelten.
Leider schrieben wir zu diesem Zeitpunkt keine Unit-Tests. Entsprechend viele Bugs hatten wir. Mit M\u00fche und Not konnten wir unser erstes gr\u00f6\u00dferes Projekt mit TwinCAT gerade noch abschlie\u00dfen.
Eine echte \u201eDependency Hell\u201c hatten wir zwar nicht \u2013 wir hatten nur eine einzige Library, die alles enthielt. Aber daf\u00fcr war diese eine Library \u2026 \u201ehell\u201c genug.<\/p>\n\n\n\n
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:<\/p>\n\n\n\n\n
Wir schrieben fast alles neu, aber diesmal in thematisch getrennten Libraries und sauber getestet.
Statt einer automatisierten Pipeline wusste einfach jeder: <\/strong>Bevor du \u00c4nderungen zum Mergen auf den Main-Branch freigibst, l\u00e4sst du alle Tests laufen. Punkt.<\/p>\n\n\n\n
Aber was wir brauchten, war: \u201eausreichend sauber, aber verdammt schnell\u201c<\/strong>. Genau das haben wir mit unserer Methode erreicht. Die Abl\u00e4ufe waren manchmal chaotischer als n\u00f6tig, aber der Code war dieses Mal richtig sauber. Auch hier ist der Code sicherlich jenes \u201eFeature\u201c, dem gem\u00e4\u00df dem Pareto-Prinzip die meiste Aufmerksamkeit gewidmet werden sollte.<\/p>\n\n\n\n
Beide Projekte wurden mit Bravour gemeistert.
Unsere Libraries<\/a> haben wir mittlerweile \u2013 als Beckhoff Solution Partner<\/strong><\/a> \u2013 per OEM-Lizenz herausgegeben. Jede Woche halten wir unser \u201eTwinCAT-Library\u201c-Meeting, in dem die neuesten Features und \u00c4nderungen besprochen werden, und mittlerweile erkennt jeder im Team schon an der Versionsnummer, welchen Grad an \u00c4nderung gemacht wurde.<\/p>\n\n\n\nMeine Tool-Favoriten und warum<\/h2>\n\n\n\n
Kommunikation \u2013 Microsoft Teams<\/h3>\n\n\n\n
Funktioniert einfach, ist weit verbreitet und reicht f\u00fcr unsere Anforderungen v\u00f6llig aus.<\/p>\n\n\n\nProjektmanagement \u2013 JIRA<\/h3>\n\n\n\n
In dem Zusammenhang kann ich \u00fcbrigens das Scrum-Buch<\/a><\/strong> empfehlen.
Nat\u00fcrlich machen wir auch hier nicht alles perfekt \u2013 aber wir probieren es zumindest ernsthaft.<\/p>\n\n\n\nWissensdatenbank \u2013 Confluence<\/h3>\n\n\n\n
Vor allem in Verbindung mit JIRA ideal \u2013 da es aus derselben Tool-Welt kommt und nahtlos integriert ist.<\/p>\n\n\n\nVersionsverwaltung \u2013 Bitbucket<\/h3>\n\n\n\n
Wo genau die Repos gehostet werden, ist mir ehrlich gesagt nicht so wichtig \u2013
Bitbucket war einfach die logische Wahl in der Atlassian-Welt.<\/p>\n\n\n\nTime-Tracking \u2013 Tempo<\/h3>\n\n\n\n