In der Software-Entwicklung gibt es zahlreiche Richtlinien und Beobachtungen, die als Gesetze oder Prinzipien bezeichnet werden. Dies sind zwar keine strengen Formeln, die in allen Situationen universell gelten, aber sie bieten wichtige Rahmenbedingungen, die den Entwicklungsprozess beeinflussen. Diese Prinzipien können sich erheblich auf die Produktivität von Organisationen, Teams und Einzelpersonen auswirken. Es ist wertvoll für jeden, der mit Software zu tun hat, sich mit diesen 9 Gesetze vertraut zu machen.
- Das Brookssche Gesetz sagt uns, dass mehr Leute im Team nicht immer mehr Spaß bringen – im Gegenteil, man kann schnell in einer Verzögerungsfalle landen.
- Goodharts Gesetz ist wie das Spiel „Ich sehe was, was du nicht siehst“ – irgendwann wird eine Metrik so manipuliert, dass das ursprüngliche Ziel in den Hintergrund gerät.
- Hyrums Gesetz zeigt uns, dass API-Benutzer genauso stur sein können wie Katze, die den Wassertropfen auf dem Boden ignoriert, obwohl der Entwickler sie ihm nicht beigebracht hat.
- Conway’sches Gesetz bringt uns dazu, uns selbst zu hinterfragen: Spiegeln die Kommunikationsstrukturen in unserem Team die Architektur wider oder haben wir uns in ein Code-Labyrinth verirrt?
- Linus’sches Gesetz ist wie der „Crowdsourcing-Heldenmodus“ – je mehr Augen auf den Code schauen, desto wahrscheinlicher ist es, dass jemand den Fehler findet, bevor der Chef es tut.
- Hofstadter’sches Gesetz mahnt uns daran, immer etwas mehr Zeit einzuplanen – alles dauert länger, selbst wenn wir es schon wissen.
- Kernighans Gesetz macht uns klar, dass komplexer Code wie ein ungeschicktes Puzzle ist, bei dem wir nie wissen, wie viele Teile fehlen – es ist besser, es gleich einfach zu halten.
- Das Peter-Prinzip ist der Klassiker, der uns erinnert: Der beste Entwickler ist nicht immer der beste Teamleiter. Und hey, das geht allen so – sogar beim Pizza-Bestellen!
- Das Pareto-Prinzip schließlich – es erklärt, warum wir nach 10 Meetings trotzdem nur 20 % der Aufgaben erledigt haben. Aber keine Sorge, 80 % der Resultate kommen eh von nur 20 % der Anstrengung, oder? 😅
Das Brookssche Gesetz
„Wenn man [Personal] zu einem späten Softwareprojekt hinzufügt, wird es später.“
Fred Brooks
Aufgrund von Koordinationskosten erhöhen mehr Entwickler, die zu einem Projekt hinzugefügt werden, nicht immer die Produktivität. Dieses Gesetz unterstreicht die Risiken, wenn man ohne angemessene Planung „mehr Leute in ein verzögertes Projekt wirft“.
Außerdem ist es wichtig, ein Gleichgewicht zwischen einem zu großen Team und einem kleinen Team zu finden, das aus Mitgliedern besteht, die mehrere Hüte tragen.
Goodharts Gesetz
„Wenn eine Maßnahme zu einem Ziel wird, hört sie auf, eine gute Maßnahme zu sein.“
Charles Goodhart
Das bedeutet, dass, sobald eine bestimmte Metrik in ein Ziel umgewandelt wird, die Menschen beginnen, ihr Verhalten zu optimieren, um diese Metrik zu erreichen, oft auf Kosten des zugrunde liegenden Ziels, das sie darstellen sollte. Wir streben oft Ergebnisse an, die schwer zu quantifizieren sind, und verlassen uns daher auf Metriken, die unsere Bemühungen in eine Richtung lenken, die wir nicht beabsichtigt haben. Es könnte sein:
- Anzahl der Codezeilen (zur Messung der Produktivität)
- Abgeschlossene Story Points pro Sprint (zur Messung der Teamgeschwindigkeit)
- Codeabdeckung (zur Messung der Testqualität)
Um diese Falle zu vermeiden, müssen wir den datengesteuerten Ansatz nicht aufgeben. Wir brauchen jedoch zumindest einige Metriken, die unsere Bemühungen antreiben. Wir müssen Metriken ständig verfeinern und neu bewerten und vermeiden in einigen Fällen auch qualitative Ansätze nicht.
Hyrums Gesetz
„Bei einer ausreichenden Anzahl von Nutzern einer API spielt es keine Rolle, was Sie im Vertrag versprechen: Auf alle beobachtbaren Verhaltensweisen Ihres Systems wird sich jemand verlassen.“
Hyrum Wright
Wenn Ihre API mehr Benutzer gewinnt, werden sich die Leute auf Verhaltensweisen verlassen, die die Designer nicht beabsichtigt oder dokumentiert haben. Im Laufe der Zeit werden selbst kleine, undokumentierte Macken oder Grenzfälle zu „Funktionen“, auf die Benutzer angewiesen sind und die Änderungen oder Verbesserungen an der API komplexer machen, ohne dass jemand etwas kaputt macht.
Dieses Gesetz unterstreicht die Herausforderungen, die mit der Aufrechterhaltung der Abwärtskompatibilität und dem Management von Erwartungen verbunden sind, wenn Systeme wachsen und sich weiterentwickeln.
Conway’sches Gesetz
„Jede Organisation, die ein System (im weitesten Sinne) entwirft, wird ein Design erstellen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.“
Melvin Conway
Die Struktur der Software spiegelt oft die Organisationsstruktur wider, in der sie erstellt wurde. Wenn Sie den bestehenden Team- oder Abteilungsgrenzen blind folgen, kann es sein, dass Sie am Ende Subdomains haben, die nicht gut auf die gewünschte Architektur oder die gewünschten Geschäftsfähigkeiten abgestimmt sind.
Das inverse Conway-Manöver ist die proaktive Anwendung des Conwayschen Gesetzes. Es legt nahe, dass wir, wenn wir wollen, dass unsere Softwarearchitektur eine bestimmte Form oder Struktur annimmt, zuerst unsere Teams und Kommunikationsmuster so organisieren sollten, dass sie die gewünschte Architektur widerspiegeln.
Linus’sches Gesetz
„Wenn man genügend Augäpfel hat, sind alle Käfer oberflächlich.“
Eric Raymond
Es fängt die Essenz der Open-Source-Zusammenarbeit ein, bei der eine breite Beteiligung der Community dazu beiträgt, Fehler effektiver zu identifizieren und zu beheben als in geschlossenen Systemen. Die Idee dahinter ist, dass je mehr Personen den Code überprüfen, desto höher ist die Wahrscheinlichkeit, dass jemand Fehler bemerkt und behebt, die andere möglicherweise übersehen.
Hofstadter’sches Gesetz
Es dauert immer länger, als man denkt, selbst wenn man das Hofstadtsche Gesetz berücksichtigt.
Douglas Hofstadter
Das Hofstadtersche Gesetz dient als Erinnerung daran, wie durchweg ungenau wir sind, wenn wir den Zeitaufwand für Aufgaben schätzen, insbesondere in der Softwareentwicklung.
Es unterstreicht die Bedeutung der Pufferzeit und des Managements von Erwartungen.
Kernighans Gesetz
„Jeder weiß, dass das Debuggen doppelt so schwer ist wie das Schreiben eines Programms. Wenn Sie also so schlau sind, wie Sie es beim Schreiben sein können, wie werden Sie es jemals debuggen?“
Brian Kernighan
Das Schreiben von zu komplexem Code kann für die Systemwartung gefährlich sein. Wenn der Code mit übermäßiger Komplexität geschrieben ist, wird das Debuggen noch schwieriger, da Sie zuerst die Logik entschlüsseln müssen, bevor Sie Probleme beheben können. Einfachheit in der Codierung ist der Schlüssel – das Schreiben von klarem, wartbarem Code erleichtert das Debuggen und Verbessern auf lange Sicht.
Peter-Prinzip
„Menschen in einer Hierarchie neigen dazu, sich zu einer ‚Stufe der jeweiligen Inkompetenz‘ zu erheben.“
Laurence Peter
Erfolg hat oft seinen Preis. In vielen Fällen werden Einzelpersonen aufgrund ihrer Leistungen in immer höhere Positionen befördert. Es kommt jedoch ein Punkt, an dem die Anforderungen der Rolle ihre Fähigkeiten übersteigen können.
In der Softwarebranche ist dies häufig zu beobachten, wenn erfolgreiche Entwickler in Führungspositionen befördert werden. Oft wird davon ausgegangen, dass Führungsqualitäten und Soft Skills mit technischem Know-how auf natürliche Weise wachsen, aber das stimmt nicht immer. Ein erfahrener Programmierer hat nicht unbedingt die gleiche Begabung für das Management von Menschen, die Führung von Teams oder den Umgang mit den strategischen Anforderungen der Führung, was in seiner neuen Rolle zu Herausforderungen führen kann.
Pareto-Prinzip
„Bei vielen Ergebnissen ergeben sich etwa 80 % der Folgen aus 20 % der Ursachen.“
Joseph Juran
Das Pareto-Prinzip, auch als 80/20-Regel bekannt, besagt, dass in vielen Fällen etwa 80 % der Ergebnisse durch nur 20 % der Ursachen oder Anstrengungen erzielt werden. Der Name stammt von dem italienischen Ökonom Vilfredo Pareto, der feststellte, dass 80 % des Landbesitzes in Italien von nur 20 % der Bevölkerung gehalten wurden. Das Pareto-Prinzip ist weithin anwendbar, und eine seiner wichtigsten Erkenntnisse ist, dass die Bemühungen selektiv sein sollten. Die Schlussfolgerung ist, dass die Konzentration auf die wirkungsvollsten Bereiche – in der Regel die 20 %, die 80 % der Ergebnisse liefern – zu einem größeren Erfolg führt als eine zu dünne Streuung. Dies unterstreicht auch, dass Qualität wichtiger ist als Quantität und dass wahre Ergebnisse wichtiger sind als nur das Volumen der generierten Leistung. Die Priorisierung dessen, was die Nadel wirklich bewegt, trägt dazu bei, aussagekräftigere und nachhaltigere Ergebnisse zu erzielen.
Fazit
Die Software-Entwicklung ist wie eine Party: Es gibt immer diese Prinzipien, die als „Gesetze“ auftreten, aber manchmal sind sie genauso unberechenbar wie der DJ, der ständig das Tempo ändert. Die gute Nachricht: Wenn man den „Wahnsinn“ der verschiedenen Gesetze und Prinzipien versteht, kann man seine Projekte mit einem Lächeln (und ein bisschen Pufferzeit) durchsteuern.
Insgesamt: Softwareentwicklung ist ein Balanceakt zwischen der perfekten Mischung von Prinzipien, Teams und Metriken – und manchmal hilft ein bisschen Humor, um durch den Code-Dschungel zu navigieren!