Oft habe ich von verschiedenen Gesetzen in der Softwaretechnik gehört, also habe ich einige Nachforschungen angestellt und versucht, so viele davon wie möglich zu finden.
A QUICK SUMMARY – FOR THE BUSY ONES
TABLE OF CONTENTS
Meiner Meinung nach könnten die Gesetze unterteilt werden in:
So einfach es auch scheint, es ist schwierig, die Gesetze diesen Kategorien zuzuordnen, also habe ich beschlossen, sie nur nach Bereichen (KI, Codierung, Kommunikation, Unternehmen, Schätzung/Zeitmanagement, Hardware, Information, Management, Maßnahme, Netzwerke, Problemlösung, Produkt, Qualitätssicherung, Warteschlangen, Anforderungen, Sicherheit/Kryptografie, Fähigkeiten, Softwarearchitektur, Softwareleistung, Statistik, Technologie, UX) und relativer Bedeutung aus meiner Sicht zu veröffentlichen.
Lassen Sie uns also über einige der wichtigsten empirischen Gesetze sprechen, die jeder Softwareingenieur auswendig kennen sollte.
„Vorzeitige Optimierung ist die Wurzel allen Übels.“
Meiner Meinung nach stimmt das nicht immer. Wenn wir wissen, dass ein bestimmter Teil des Systems für die allgemeine Leistung unerlässlich ist und eine andere Lösung eine um ein paar Mal schnellere Ausführung ermöglichen könnte als die derzeit entwickelte Lösung, sollten wir unseren Ansatz ändern.
Wie dem auch sei, sagen wir, in 95% der Fälle ist dieses Prinzip wahr: Wenn wir versuchen, zu viel zu optimieren, können wir zu viel Zeit damit verbringen, unsere aktuellen Dinge zu implementieren, und die Zukunft kann noch schlimmer sein, weil wir Code ausgewählt haben, der nicht am einfachsten zu verwalten ist.
„Beim Debuggen fügen Anfänger Korrekturcode ein, Experten entfernen defekten Code“
Meiner Meinung nach bedarf es keiner Erklärung.
„Sei konservativ in dem, was du tust, sei liberal in dem, was du von anderen akzeptierst“
Bei der Entwicklung einer Bibliothek, einer HTTP-API, einer Klasse, eines Moduls oder einer Funktion sollten wir für Abwärtskompatibilität sorgen und noch flexibler in Bezug auf die empfangenen Argumente werden. Diese Regel gilt auch im wirklichen Leben — wir sollten uns selbst gegenüber konservativ sein, aber anderen gegenüber liberal/tolerant.
„Alle komplexen Systeme, die funktionieren, haben sich aus einfacheren Systemen entwickelt, die funktioniert haben“
Wenn wir ein neues innovatives System entwickeln, sollten wir mit etwas Einfachem beginnen, das funktioniert, was sich später zu einer komplexeren Lösung entwickeln wird. Wenn wir jedoch an Dingen arbeiten, die denen, an denen wir schon oft gearbeitet haben, sehr ähnlich sind, können wir einen Plan haben und genau nach diesem Plan arbeiten, weil die Wahrscheinlichkeit groß ist, dass er erfolgreich ist.
PS. Dieses Gesetz eignet sich gut für die Herstellung von Produkten mit minimaler Rentabilität. Mehr dazu erfahren Sie im Artikel“Was ist MVP/Minimum Viable Product?“
„Jede Anwendung hat eine inhärente Komplexität, die nicht entfernt oder versteckt werden kann. Stattdessen muss damit umgegangen werden, entweder bei der Produktentwicklung oder bei der Benutzerinteraktion.“
Ich glaube nicht, dass das einer Erklärung bedarf.
„Die Beschleunigung, die durch die Ausführung eines Programms auf einem Parallelcomputer erzielt wird, wird durch den Bruchteil des Programms, der nicht parallelisiert werden kann, stark eingeschränkt.“
Um von der Parallelisierung zu profitieren, muss der größte Teil des Systems parallelisiert werden, und wir sollten die Engpässe reduzieren.
„Die Zeit, die Ihre Lieblingsanwendung benötigt, um eine bestimmte Aufgabe zu erledigen, verdoppelt sich mit jeder neuen Überarbeitung.“
In den meisten Fällen ist es übertrieben, aber meistens stimmt es, weil neue Funktionen erfordern, mehr Bedingungen zu überprüfen oder einfach mehr Code in den RAM zu laden, was die Leistung verringert.
„Wenn die Leute sich selbst öfter zuhören würden, würden sie weniger reden.“
Für eine effiziente Kommunikation ist es aus den folgenden Gründen sehr wichtig, zuzuhören:
„Um zu verstehen, was eine andere Person sagt, müssen Sie davon ausgehen, dass es wahr ist, und versuchen, sich vorzustellen, worauf es zutreffen könnte.“
Selbst wenn Sie mit jemandem anderer Meinung sind, sollten Sie sich vorstellen, dass er Recht hat, um:
„In jedem Streit ist die Intensität des Gefühls umgekehrt proportional zum Wert der Streitfragen.“
Manchmal debattieren wir sehr lange über einige kleinere Themen. Es ist wichtig, mit Kollegen zu sprechen, um eine optimale oder nahezu optimale Lösung zu finden. Manchmal ist es jedoch Zeitverschwendung, z. B. besprechen wir etwas für ein paar Stunden, was die Implementierungszeit nur um eine Stunde reduziert und dem Anwendungsbenutzer nichts bringt. Daher gilt als Faustregel, dass die Diskussionszeit proportional zur Wichtigkeit des Themas ist. Diese kann anhand der Implementierungszeit, des verdienten Geldes oder der Anzahl der Produktionsbenutzer gemessen werden.
„Mitglieder einer Organisation messen trivialen Themen ein unverhältnismäßiges Gewicht bei“
Ähnlich dem Gesetz von Sayre. Eine Erklärung dafür ist, dass ein Entwickler, wenn er die meiste Zeit mit dem Programmieren verbringt, insbesondere mit der Implementierung eines kleinen Teils des Systems wie Microservice, CSS, Deployment, den Zweck des gesamten Systems vergessen kann, sodass er dazu neigt, seine Arbeit zu optimieren, was manchmal das gesamte System optimieren kann.
Sehr oft hat es jedoch keine oder nur eine sehr geringe Auswirkung auf das gesamte System. Ein Beispiel: Ein Entwickler liebt kurzen Code und verbringt daher viel Zeit damit, Code zu verkürzen, und ein anderer Entwickler liebt langen Code, weshalb er viel Zeit damit verbringt, Code zu verlängern. Der Effekt ist, dass sich ihre Arbeit gegenseitig zunichte macht.
„Bei der Diagnose sollte man zuerst das Offensichtliche berücksichtigen“
Sehr nützlich in vielen Arbeits- und Lebensbereichen. Keine Erklärung erforderlich.
„Es funktioniert besser, wenn du es einsteckst.“
Eine weitere Formulierung des Sutton-Gesetzes.
„Die einfachste Lösung ist höchstwahrscheinlich die richtige.“
Ähnlich dem Sutton-Gesetz und dem Sattinger-Gesetz. Der Unterschied besteht darin, dass es sich um die einfachste Lösung aller Lösungen handelt, bei denen viele von ihnen offensichtlich sein können.
„Maschinen sollten funktionieren. Die Leute sollten nachdenken.“
Wir wissen nicht, wie intelligent die KI sein wird, aber derzeit ist sie nicht zu intelligent, also müssen die Entwickler, Geschäftsanalysten und UX-Ingenieure verschiedene Szenarien vorhersagen, und die Maschine sollte die Dinge tun, die leicht programmiert werden können, z. B. sollten Benutzer keine manuellen Suchanfragen in großen Datenmengen durchführen.
„In einer Hierarchie neigt jeder Mitarbeiter dazu, sein Niveau an Inkompetenz zu erreichen.“
Das Peter-Prinzip geht davon aus, dass ein Mitarbeiter nach Erfolg auf jeder Position befördert wird. Schließlich erreicht er eine Position, in der er nicht erfolgreich ist, sodass er dort stecken bleibt. Andererseits geht das Dilbert-Prinzip davon aus, dass ein Mitarbeiter befördert wird, nachdem er eine Inkompetenz gezeigt hat. In einer höheren Position ist er also ebenfalls inkompetent, aber diese höhere Rolle sollte keinen Schaden anrichten, da es sich um eine Managerrolle handelt, für die eigentlich keine Verantwortung besteht.
Vielleicht stimmen diese Regeln manchmal, aber es ist möglich, dass jemand, der eifersüchtig darauf war, dass seine Mitarbeiter befördert wurden, das formuliert hat.
„Man kann nicht in einem Monat ein Baby bekommen, wenn man neun Frauen schwanger macht.“
Sehr oft führt das Hinzufügen neuer Entwickler zu einem Projekt nicht dazu, dass die Arbeit früher abgeschlossen wird, da eine bestimmte Arbeit nicht immer in kleinere Teile aufgeteilt werden kann, die gleichzeitig implementiert werden könnten.
„Wenn Sie einem verspäteten Softwareprojekt Personal hinzufügen, wird es später“
Es geht sogar noch weiter als Frischs Gesetz. Eine Erklärung dafür ist, dass das Hinzufügen neuer Leute dazu führt, dass die alten Entwickler ihre Zeit mit Mentoring verschwenden.
„Es dauert immer länger als erwartet, auch wenn man Hofstadters Gesetz berücksichtigt.“
Ein rekursives und sehr wahres Gesetz, das meiner Meinung nach keiner Erklärung bedarf.
„Die Arbeit dehnt sich aus, um die Zeit auszufüllen, die für ihre Fertigstellung zur Verfügung steht“
Selbst wenn wir sehr sorgfältig abschätzen, können wir unsere Arbeit sehr wahrscheinlich nach der ETA beenden, denn wenn wir wissen, dass wir viel Zeit haben, arbeiten wir so langsam oder wir fangen sehr spät an zu arbeiten, sodass das Ergebnis entweder genau zum Stichtag oder sogar später fertig ist.
Eine Implikation ist, dass wir nicht zu sorgfältig abschätzen sollten, da dies nicht unbedingt die Wahrscheinlichkeit einer Unterschätzung verringert. Eine andere Erklärung ist, wenn wir viel Zeit für etwas haben, auch wenn es fertig ist, können wir es immer noch verbessern, sodass wir bis zum Ablauf der Frist weiter optimieren.
„Die ersten 90 Prozent des Codes machen die ersten 90 Prozent der Entwicklungszeit aus. Die restlichen 10 Prozent des Codes machen die anderen 90 Prozent der Entwicklungszeit aus.“
Die letzten 10% der Arbeit sind in der Regel die schwierigsten, sodass sie sehr lange dauern oder sogar nie vollständig abgeschlossen werden können.
„Erhöhte Erregungswerte können die Leistung bis zu einem bestimmten Punkt verbessern“
Ein nützliches Gesetz für die Personen, die für das Arbeitsumfeld verantwortlich sind. Keine Erklärung erforderlich.
„Menschen unter Zeitdruck denken nicht schneller“
Ähnlich dem Yerkes-Dodson-Gesetz. Menschen, die unter Zeitdruck stehen, können schneller arbeiten, wenn es möglich ist, die Arbeit vor Ablauf der Frist zu erledigen.
1. Schätzungen sind Verschwendung
2. Schätzungen sind nicht übertragbar
3. Schätzungen sind falsch
4. Schätzungen sind vorübergehend
5. Schätzungen sind notwendig
Sie mögen widersprüchlich erscheinen, aber die erste Regel besagt, dass die Zeit, die für Schätzungen aufgewendet wird, keine neuen Funktionen mit sich bringt, sodass wir nicht zu viel Zeit damit verbringen können. Die fünfte Regel besagt jedoch, dass sie nur notwendig sind, also sollten wir alle Aufgaben schätzen, aber nicht zu viel Zeit mit Schätzungen verbringen.
„Wenn die Häufigkeit von Fehlwarnungen zunimmt, sinkt das Vertrauen der Bediener in nachfolgende Warnungen oder ihr Vertrauen in sie.“
Es ist sehr wichtig, DevOps-Warnungen zu haben, z. B. wenn ein bestimmter Microservice ausgefallen ist oder die Bereitstellung fehlgeschlagen ist, aber es ist auch wichtig, nicht zu viele Warnungen zu haben, da sie, wenn sie sehr häufig sind, zu Spam werden. Noch schlimmer sind Fehlalarme, die die Alarme unglaubwürdig machen.
„Ein System zum Abrufen von Informationen wird in der Regel nicht verwendet, wenn es für einen Kunden schmerzhafter und schwieriger ist, Informationen zu haben, als wenn er sie nicht hat.“
Es ist wichtig, ein gewisses Gleichgewicht zwischen der Speicherung von Informationen und ihren Kosten herzustellen, z. B. das Speichern des gesamten Änderungsverlaufs von Dokumenten oder das Speichern von Protokollen.
„Ein Mann mit einer Uhr weiß, wie spät es ist. Ein Mann mit zwei Uhren ist sich nie sicher.“
Es ist wichtig, eine einzige Informationsquelle zu haben.
„Wenn eine Maßnahme zu einem Ziel wird, ist sie keine gute Maßnahme mehr.“
Ein sehr wichtiges Gesetz. Wenn wir versuchen, eine bestimmte Kennzahl zu optimieren (wie Anzahl der Commits, fertige User Stories, Anzahl der Bugs), optimieren wir sie, aber der gemessene Wert (der direkt wie Arbeitsmenge und Qualität unermesslich ist) wird nicht unbedingt optimiert.
Meiner Meinung nach ist das einzig gute Maß Geld, denn wenn mir jemand Geld gibt, hat er weniger, also Geld für etwas auszugeben bedeutet normalerweise, dass es wichtig ist.
„Wenn dieselben Tests immer wieder wiederholt werden, werden dieselben Testfälle irgendwann keine neuen Fehler mehr finden.“
Es ähnelt Goodharts Gesetz über Tests — wenn wir Testfälle repariert haben, kann sich der Produktionscode so weiterentwickeln, dass er nur die Testfälle erfüllt, aber für die meisten Szenarien nicht funktioniert. Daher ist es wichtig, dass sowohl der Produktionscode als auch die Tests vom selben Team geschrieben und der Code überprüft wird.
„Technologie wird von zwei Arten von Menschen dominiert: von denen, die verstehen, was sie nicht verwalten, und von denen, die das verwalten, was sie nicht verstehen.“
Es ist wichtig, sowohl Entwickler zu haben, die das Produkt verstehen, als auch einen Product Owner, der die Entwicklung versteht. Mindestens eine Person sollte sowohl das Produkt als auch die Entwicklung gut verstehen. Andernfalls werden die Anforderungen sehr wahrscheinlich nie erfüllt, manchmal, weil die Technologie es uns nicht ermöglicht, die Anforderungen zu erfüllen.
„Reihenfolge der Prioritäten: Funktionalität, Treue, Effizienz“
Zuerst sollten wir die funktionierenden Funktionen implementieren (arbeiten bedeutet natürlich nicht, in 20% der Szenarien zu arbeiten, sondern in 90% der Szenarien zu arbeiten), dann sollten wir Fehler beheben (um in 99,9% der Szenarien funktionierende Funktionen zu haben) und schließlich die Leistung verbessern.
„Wenn es einen falschen Weg gibt, etwas zu tun, dann wird es jemand tun.“
Es ist normalerweise wahr und meiner Meinung nach bedarf es keiner Erklärung.
„Wenn etwas schief gehen kann, wird es schief gehen“
Eine weitere Formulierung von Murphys Gesetz.
„Alles, was schief gehen kann, wird schief gehen — im schlimmsten Moment.“
Ähnlich wie Murphys Gesetz und Sods Gesetz, aber es geht noch weiter.
„Leistungsträger sind nicht in der Lage, die Fähigkeiten und Kompetenzen anderer Menschen zu erkennen, was einer der Gründe dafür ist, dass sie sich selbst immer wieder als besser, fähiger und sachkundiger betrachten als andere.“
Nachdem die Menschen zunächst sehr schnell neue Fähigkeiten erworben haben, neigen sie dazu, sich selbst als hochqualifiziert zu betrachten, aber später stellen sie fest, dass sie viele Fehler haben.
„Einige der wichtigsten Schritte für geistiges Wachstum basieren nicht nur auf dem Erwerb neuer Fähigkeiten, sondern auch auf dem Erwerb neuer administrativer Methoden, um das, was man bereits weiß, zu nutzen.“
Normalerweise müssen wir uns nicht alles merken, sondern wissen nur, wo wir eine bestimmte Information erhalten können. Wenn wir bestimmte Tools jedoch häufig verwendet haben, ist es gut, sich daran zu erinnern, wie man sie benutzt, aber selbst in dieser Situation kann es ausreichen, sie einfach zu benutzen und wir können sie auswendig lernen, ohne dass wir zusätzlich lernen müssen.
„Bei vielen Ereignissen sind ungefähr 80% der Auswirkungen auf 20% der Ursachen zurückzuführen“
Es erklärt viele Arbeits- und Lebensbereiche.
„Benutzer verbringen die meiste Zeit auf anderen Websites. Das bedeutet, dass die Nutzer es vorziehen, dass Ihre Website genauso funktioniert wie alle anderen Websites, die sie bereits kennen.“
Selbst wenn Sie Google oder Facebook sind, verbringen die Nutzer im Durchschnitt die meiste Zeit auf anderen Websites, sodass Sie Überraschungen vermeiden sollten. Dies gilt auch für die Erstellung einer HTTP-API oder einer API einer Bibliothek, Klasse, eines Moduls oder einer Funktion.
„Für ein neues Softwaresystem werden die Anforderungen erst vollständig bekannt sein, nachdem die Benutzer es verwendet haben.“
Für Geschäftsanalysten ist es unmöglich, alle möglichen Szenarien vorherzusagen, da es nur wenige davon gibt und es Millionen von Produktionsbenutzern geben kann.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Ein Serienunternehmer, leidenschaftlicher Forschungs- und Entwicklungsingenieur mit 15 Jahren Erfahrung in der Technologiebranche. Teilt sein Expertenwissen über Technologie, Startups, Geschäftsentwicklung und Marktanalysen.
Ein Serienunternehmer, leidenschaftlicher Forschungs- und Entwicklungsingenieur mit 15 Jahren Erfahrung in der Technologiebranche. Teilt sein Expertenwissen über Technologie, Startups, Geschäftsentwicklung und Marktanalysen.
Read next
Popular this month
previous article in this collection
It's the first one.
