Von Murphy bis Knuth: Die Gebote der Softwareentwicklung

Jakob’s Law

“Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”

Benutzer sind an bestimmte Designelemente und Interaktionen gewöhnt, die sie beim Verwenden verschiedener Websites und Anwendungen erleben. Durch die Verwendung vertrauter Design Patterns können Sie eine intuitivere und benutzerfreundlichere Erfahrung für Ihre Zielgruppe schaffen.

Hofstadter’s Law

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

"Wie lange wird es dauern?“ ist eine der gefürchtetsten Fragen in der Softwareentwicklung. Hofstadters Gesetz beschreibt die Tendenz, dass Projekte und Aufgaben häufig mehr Zeit in Anspruch nehmen als ursprünglich angenommen. Sogar wenn bereits Verzögerungen und Puffer für Unvorhersehbarkeiten eingeplant wurden.

In Software-Projekte gibt es zahlreiche Gründe für Verzögerungen: Unseriöse Angebote und Aufwandschätzungen, falsche Annahmen, unklare Spezifikationen, Fokus auf unwesentliche Dinge, Legay Code, permanente Change-Requests, Angst Entscheidungen zu treffen, etc.

The 90-90 Rule

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Die 90-90-Regel spiegelt (etwas überspitzt) wider, dass Softwareprojekte oft länger dauern als erwartet. Die ursprünglich geplante Entwicklungsdauer wird aus diversen Gründen (siehe Hofstadter’s Law) überschritten. Auch wenn man zu Beginn große Schritte macht und die Entwicklung wie geplant voranschreitet, kann es – je näher der Go-Live Termin kommt – zu Verzögerungen kommen.

Brooks’s law

“Adding manpower to a late project makes it later.”

Das Gesetz stammt aus Fred Brooks' Buch "The Mythical Man Month" von 1975. Es befasst sich mit der Annahme, dass Teammitglieder und benötigte Monate austauschbar sind. Dies ist jedoch insbesondere in der Softwareentwicklung nicht zwingend der Fall. Warum? Aufgrund der Zeit, die benötigt wird, um Personen über den aktuellen Stand des Projekts auf dem Laufenden zu halten und sie in den Prozess zu integrieren. Zudem gibt es nicht immer die Aufgaben, die in kleinere Subtasks aufgeteilt werden können und gleichzeitig abgearbeitet werden.

Murphy's Law

“If there is a wrong way to do something, then someone will do it.”

Dies ist das bekannteste und universellste Gesetz auf dieser Liste. Murphys Gesetz ist in allen Bereichen des Projektmanagements, der Softwareentwicklung und des Lebens im Allgemeinen sichtbar.

Pareto Principle

"80% of the effects come from 20% of the causes."

Ein Klassiker! Das Paretoprinzip kann auf viele Bereiche der Arbeit und des Lebens angewandt werden. In der Softwareentwicklung können bedeutende Verbesserungen erzielt werden, indem man den Fokus auf die Funktionen legt, die dem User einen Mehrwert liefern. Zu früh und zu oft verliert man sich im Detail.

Sollte das Paretoprinzip immer berücksichtigt werden. Nein! Es gibt Fälle, in denen es von Vorteil ist, wenn man frühzeitig alle Eventualität berücksichtigt.

Dunning–Kruger Effect

"Low performers often struggle to recognize the skills and competence of others, leading them to consistently view themselves as better, more capable, and more knowledgeable than others."

Der Dunning-Kruger-Effekt besagt, dass Menschen mit geringen Fähigkeiten oft ihre eigenen Fähigkeiten überschätzen und die Tiefe des benötigten Fachwissens nicht erkennen. Weniger kompetente Personen halten sich oft für sehr kompetent, während kompetentere Personen ihre Fähigkeiten realistischer einschätzen können. In der Softwareentwicklung trifft man häufig auf dieses Phänomen.

Segal’s Law

“A man with a watch knows what time it is. A man with two watches is never sure.”

Hier geht es um die Daten und die Datenqualität – genauer gesagt das Konzept „Single source of truth“ (SSOT). Ein Unternehmen sammelt alle Daten an einem Ort. Dieser allgemeingültige Datenbestand liefert korrekte und verlässliche Daten.

Mehrere Datenquellen ohne SSOT können u.a. zu Verwirrung und Inkonsistenzen führen.

DRY (Don't Repeat Yourself)

"Every piece of knowledge must have a single, unambiguous representation within a system."

Das DRY-Prinzip besagt, dass in einem Softwareprojekt dieselbe Information oder Logik nicht an mehreren Stellen dupliziert werden sollte. Stattdessen sollte sie an einer einzigen Stelle verwaltet werden. Dies fördert die Wartbarkeit, reduziert das Risiko von Fehlern und vereinfacht Änderungen, da Aktualisierungen nur an einer Stelle vorgenommen werden müssen.

Gall’s law

“A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.”

Wenn man ein neues System entwickelt, sollte man schrittweise vorgehen. Galls Gesetz liefert einen guten Grund, die Entwicklung von Softwareprodukten in unterschiedliche Etappen zu unterteilen. In der Praxis setzt man dabei auf Werkzeuge wie Prototyping, PoCs und MVPs. Wenn alles funktioniert, kann man schrittweise weiterentwickeln und neue Funktionen hinzufügen.

KISS (Keep it Simple, Stupid)

"Simplicity is the ultimate sophistication."

Dieses Prinzip rät dazu, Software so einfach wie möglich zu halten, um unnötige Komplexität zu vermeiden. Einfache Lösungen sind oft leichter zu verstehen, zu warten und zu debuggen. Klingt simple oder?

Eagleson’s law

“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

Mit sechs Monaten zählt Eagleson zu den Optimisten. Wie dem auch sei. Sein Gesetz unterstreicht die Notwendigkeit von Clean-Code, Standards und Kommentaren. Nach einer Weile kann selbst der ursprüngliche Programmierer seinen Code nicht mehr entwirren. Ich spreche da aus eigener Erfahrung…

Lubarsky’s law

“There’s always one more bug.”

Trotzt aller Bemühung und einhalten von Best-Practice-Ansätzen: Man wird immer noch einen Bug oder eine vermeintliche Optimierung finden. Die Arbeit ist nie abgeschlossen. Was lehrt uns das Gesetz: Nimm dich in Acht vor Perfektionismus! Es kann Zeit, Geld und Nerven kosten.

Knuth’s Optimization Principle

“Premature optimization is the root of all evil.”

Meiner Meinung nach trifft das nicht immer zu. Beispiel: Wenn wir wissen, dass ein bestimmter Teil eines Systems entscheidend für die Leistung ist und es einen besseren Ansatz als die aktuelle Implementierung gibt, sollte man zumindest über die Alternative diskutieren.

So oder so, in etwa 90 % der Fälle trifft dieses Prinzip zu: Wenn wir zu früh und zu stark optimieren, besteht die Gefahr, dass man das große Ganze aus den Augen verliert und wertvolle Zeit verschwendet.

YAGNI (You Aren't Gonna Need It)

"Always implement things when you actually need them, never when you just foresee that you need them."

“Nur für den Fall, dass wir sie brauchen” oder “irgendwann wird uns das Helfen”. Stop! YAGNI rät davon ab, Funktionalität oder Features vorzeitig hinzuzufügen. Stattdessen sollte man sich auf die aktuellen Prioritäten fokussieren.

Sayre’s Law

“In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake.”

Intensive Diskussionen sind wichtig. Manchmal wird zu viel Zeit für Nebenschauplätze verschwendet. Wenn man stundenlang über Dinge debattiert, die keinen Mehrwert bringen, ist das Zeitverschwendung. Daher gilt die Faustregel: Die Diskussionszeit sollte proportional zur Wichtigkeit des Problems sein.

Parkinson’s Law of Triviality

"The time spent on any agenda item will be in inverse proportion to the sum involved."

Ähnlicher Ansatz wie Sayre’s Law. Das Gesetz besagt, dass Menschen tendenziell mehr Zeit und Energie für unwichtige Angelegenheiten verschwenden. In der Softwareentwicklung kann es zu ausgeschweiften Diskussionen über Details wie Formatierungen kommen, während bei tiefgreifende Architektur- oder Designentscheidungen wenig Input geliefert wird.

Fazit

Wenn einem diese Gesetze und Prinzipien geläufig sind, wird man in der Praxis immer wieder auf sie stoßen. Sie bieten nicht nur Einsichten, sondern auch bewährte Leitfäden für erfolgreiche Projekte. Ob Reduktion der Komplexität, kluge Entscheidungen oder Fokussierung auf das Wesentliche – diese Regeln können als Anhaltspunkte dienen.

Trotz ihrer scheinbaren Strenge sollten wir im Hinterkopf behalten, dass ihre Anwendung oft flexibel ist. Ob und wie sehr man sich an diese Regeln hält, hängt von der jeweiligen Situation ab.

Fakt ist, diese Prinzipien sind ausgezeichnete Orientierungshilfen. Nutzen wir die Weisheiten, für unsere Softwareprojekte und heben diese auf das nächste Level – Code für Code.