- Hinter der geringeren Wertschätzung einfacher Ansätze bei Paper-Reviews oder Beförderungsbeurteilungen steht ein Komplexitätsbias, weil komplexe Ergebnisse so wirken, als enthielten sie mehr Aufwand, Können und Innovation.
- Systeme mit vielen Optionen und Komponenten wirken flexibel, doch im tatsächlichen Betrieb werden Erklärung, Tests und Fehlerbehebung schwieriger, und Fehler sowie Ineffizienz können zunehmen.
- Einfache Ideen und Systeme sind leichter zu verstehen, zu nutzen, zu feedbacken und zu erweitern; Instagram bediente zum Zeitpunkt der Übernahme 2012 mit einem Team von 13 Personen zig Millionen Nutzer und hielt an bewährten Technologien wie PostgreSQL und Redis fest.
- Auch im Machine Learning sind komplexe Verfahren nicht immer überlegen: Bei 45 mittelgroßen tabellarischen Datensätzen waren baumbasierte Modelle besser als tiefe neuronale Netze, und bei Empfehlungen sowie Suche gibt es Fälle, in denen das Skalarprodukt (dot product) besser ist als neural collaborative filtering.
- Wenn Komplexität an sich belohnt wird, fördert das unnötige Verkomplizierung und eine not invented here-Haltung. Je komplexer ein Problem ist, desto eher sollte man daher zuerst prüfen, ob eine einfache Lösung möglich ist und ob die Kosten der Komplexität gerechtfertigt sind.
Warum Komplexität attraktiver wirkt
- Komplexität wird leicht als Signal für Aufwand wahrgenommen
- Paper mit schwierigen Ideen und vielen technischen Details wirken so, als steckten viel Zeit und Mühe darin.
- Systeme mit vielen Komponenten und Funktionen werden eher als sorgfältiger ausgearbeitete Ergebnisse bewertet als kleinere Systeme.
- Der Eindruck, dass etwas schwer zu bauen ist, funktioniert schnell wie ein Signal für Wert und Qualität.
- Sie wird auch als Signal für Können interpretiert
- Systeme mit vielen beweglichen Teilen vermitteln den Eindruck, dass ihre Designer die einzelnen Teile verstehen und integrieren können.
- Paper mit vielen Fachbegriffen und Beweisen sind schwer zugänglich, wirken aber gerade dadurch wie ein Nachweis von Themenexpertise.
- Auch die Praxis, in Interviews Algorithmen und Datenstrukturen abzufragen, die in der Praxis kaum verwendet werden, hängt mit diesem Signal zusammen.
- Es gibt auch die Wahrnehmung als Signal für Innovation
- Ein Paper, das eine völlig neue Modellarchitektur entwickelt, wird eher als neuartig bewertet als ein Paper, das ein bestehendes Netzwerk modifiziert.
- Systeme mit vielen von Grund auf neu gebauten Komponenten wirken origineller als Systeme, die bestehende Bausteine wiederverwenden.
- Die Einschätzung „nur eine Sache geändert, der Rest ist wie in bestehender Forschung“ kann den Wert einer einfachen Idee mindern.
- Je mehr Funktionen vorhanden sind, desto eher entsteht die Illusion größerer Vollständigkeit
- Systeme, die sowohl SQL- als auch NoSQL-Datenspeicher unterstützen oder sowohl Batch- als auch Streaming-Pipelines ermöglichen, wirken so, als deckten sie alle Fälle ab.
- Je mehr Lego-Bausteine vorhanden sind, desto eher glaubt man, besser auf Veränderungen reagieren zu können.
- Solche Urteile führen zu einem complexity bias, der Komplexes gegenüber einfachen Ideen und Systemen übermäßig bevorzugt.
Wo Einfachheit in der Praxis zum Vorteil wird
- Einfache Ideen und Funktionen sind leichter zu verstehen und zu nutzen
- Die Chance auf Adoption und tatsächliche Wirkung steigt.
- Sie lassen sich auch leichter vermitteln und mit Feedback verbessern.
- Komplexe Systeme sind schwer zu erklären und zu verwalten, sodass Nutzer schwer erkennen, was sie wie tun sollen.
- Gibt es zu viele Stellschrauben, nehmen Fehler zu; gibt es zu viele Schritte, entsteht Ineffizienz.
- Einfache Systeme sind leichter zu bauen und zu skalieren
- Weniger Komponenten erleichtern die Implementierung.
- Wer standardisierte, bewährte Technologien nutzt, findet leichter Menschen für Implementierung und Wartung.
- Weniger Code und interne Wechselwirkungen senken auch den Aufwand für Verständnis und Tests.
- Unnötig komplexe Systeme verbrauchen mehr Zeit und Ressourcen beim Aufbau und erzeugen Verschwendung.
- Das Beispiel Instagram zeigt die Vorteile einfacher Technologieentscheidungen
- Zum Zeitpunkt der Übernahme 2012 bediente Instagram mit einem Team von 13 Personen zig Millionen Nutzer.
- Statt neuer Trendtechnologien hielt das Team an bewährten Technologien fest und senkte so die operative Last pro Engineer.
- Während andere Startups trendige NoSQL-Datenspeicher einführten und damit Schwierigkeiten hatten, nutzte Instagram das leicht verständliche PostgreSQL und Redis.
Betriebskosten und Wartbarkeit
- Die Bereitstellung eines Systems ist nicht das Ende, sondern der Anfang
- Der größte Teil des Aufwands entsteht nach dem Gang in die Produktion.
- Der Betrieb wird wahrscheinlich von anderen Personen übernommen als vom ursprünglichen Team.
- Einfache Systeme können Wartungskosten senken und die Lebensdauer verlängern.
- Je weniger bewegliche Teile es gibt, desto zuverlässiger und leichter reparierbar ist ein System
- Es gibt weniger Teile, die ausfallen können.
- Weniger interne Wechselwirkungen erleichtern es, einzelne Komponenten zu aktualisieren oder zu ersetzen.
- Komplexe Systeme erhöhen die Wartungskosten, weil ein begrenztes Team viele Komponenten verstehen muss.
- Viele voneinander abhängige Teile erschweren auch die Fehlerbehebung.
- Thomas Paine sagte in 『Common Sense』: „Je einfacher etwas ist, desto geringer ist die Wahrscheinlichkeit, dass es in Unordnung gerät, und desto leichter lässt es sich wieder in Ordnung bringen, wenn es doch geschieht.“
Fälle, in denen einfache Verfahren auch im Machine Learning nicht unterlegen sind
- Ausgefeiltere Verfahren liefern nicht immer bessere Performance
- Tree-based models > deep neural networks: Bei 45 mittelgroßen tabellarischen Datensätzen schneiden baumbasierte Modelle besser ab als tiefe neuronale Netze.
- Greedy algorithms > graph neural networks: Bei kombinatorischen Graphproblemen sind Greedy-Algorithmen besser als graph neural networks.
- Simple averaging ≥ complex optimizers: Bei Multi-Task-Learning-Problemen ist einfaches Mitteln mindestens so gut wie komplexe Optimizer.
- Simple methods > complex methods: Über 32 Paper hinweg sind einfache Methoden bei der Vorhersagegenauigkeit besser als komplexe Methoden.
- Dot product > neural collaborative filtering: Bei Item-Empfehlungen und Suche ist das Skalarprodukt besser als neural collaborative filtering.
Probleme, die entstehen, wenn Komplexität belohnt wird
- Wenn Komplexität belohnt wird, haben Menschen einen Anreiz, unnötig komplexe Dinge zu bauen
- Einfache Methoden oder Systeme können als weniger wertvoll bewertet werden, nur weil sie leicht aussehen.
- Wird ein System verkompliziert, um Belohnungen zu erhalten, ist die einfachste Lösung nicht mehr die naheliegende Wahl.
- Komplexität erzeugt weitere Komplexität und kann schließlich zu einem Punkt führen, an dem Arbeit unmöglich wird.
- Auch die not invented here-Haltung wird verstärkt
- Obwohl sich durch Wiederverwendung bestehender Komponenten Zeit und Aufwand sparen lassen, entsteht die Tendenz, alles von Grund auf selbst zu bauen.
- Das kann Zeit und Ressourcen verschwenden und zu schlechteren Ergebnissen führen.
- Auch in Beförderungsprozessen und ML-Paper-Reviews kann Komplexität übermäßig betont werden
- Bryan Liles weist darauf hin, dass einfache Lösungen leichter zu implementieren und zu skalieren sind als komplexe, Beförderungen aber oft an Personen gehen, die komplexe Lösungen gebaut haben.
- Micah Goldblum sagt, in ML-Reviews sei der Hinweis verbreitet, eine Methode sei zu einfach oder aus bestehenden Bausteinen zusammengesetzt; Einfachheit sei jedoch keine Schwäche, sondern eine Stärke.
- Auch Innovationen wie Kalman Filters, PageRank, SVM, LSTM, Word2Vec und Dropout wurden schon abgelehnt.
Ein besserer Umgang mit Komplexität
- Ziel ist es, komplexe Probleme mit möglichst einfachen Lösungen zu lösen
- Der Fokus sollte auf der Komplexität des Problems liegen, nicht auf der Komplexität der Lösung.
- Eine einfache Lösung zeigt tiefes Verständnis des Problems und die Fähigkeit, stärker verhedderte und kostspieligere Lösungen zu vermeiden.
- Das hängt mit Albert Einsteins Aussage zusammen: „Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher.“
- Statt einer komplexen Lösung, die alles abdeckt, kann man mehrere fokussierte Lösungen in Betracht ziehen
- One-size-fits-all-Lösungen können weniger flexibel und weniger wiederverwendbar sein als erwartet.
- Wenn mehrere Use Cases und Stakeholder gleichzeitig unterstützt werden, entsteht starke Kopplung, und Planung sowie Migration erfordern mehr Abstimmung.
- Systeme mit einem einzelnen Zweck sind leichter zu betreiben und bei Bedarf auch leichter abzuschaffen.
- Als Methode zur Verringerung des Komplexitätsbias lässt sich Occam’s razor anwenden
- Das ist das Prinzip, dass die einfachste Lösung oder Erklärung in der Regel richtig ist.
- Man sollte einfache Ideen nicht zu schnell verwerfen und keine unnötige Komplexität hinzufügen, nur um ihren Wert zu rechtfertigen.
- Unter Berücksichtigung der Kosten von Komplexität sollte man fragen: „Ist es das wert?“
Der gegenteilige Bias: vertraute Komplexität wiederverwenden
- Auf der anderen Seite von „not invented here“ gibt es auch einen Bias, bestehende Komponenten automatisch zu bevorzugen
- Weil man sie bereits kennt, sie aus persönlicher Erfahrung einfacher wirken und die eigene Zeit sowie den eigenen Aufwand reduzieren können.
- Wenn die bestehende Komponente selbst jedoch sehr komplex ist, kann sie im Vergleich zum Neubau einer einfacheren Lösung Zeit und Ressourcen verschwenden und zu schlechteren Ergebnissen führen.
- Wenn es keine einfache Option gibt, kann es nötig sein, etwas neu zu bauen
- Es kann auch passieren, dass das neu Gebaute tatsächlich nicht einfacher wird, sondern nur ein anderes Objekt ist, das genauso komplex ist wie das bestehende.
- Manche Probleme sind ihrem Wesen nach komplex und besitzen essential complexity, die sich tatsächlich nicht entfernen lässt.
- ORM wird als Negativbeispiel behandelt
- ORMs werden immer wieder neu gebaut und beginnen zunächst einfach, doch am Ende explodiert die Komplexität.
- Der object/relational impedance mismatch ist gut bekannt, und die Idee eines ORM ist an sich inhärent komplex.
- Was so aussieht, als habe es Einfachheit bewahrt, ist wahrscheinlich kein ORM, sondern ein query builder oder data mapper.
- Die PSR Cache API ist ein Beispiel für entfernbare Komplexität
- Nach der PSR-6 Cache API erschien die einfachere PSR-16 Cache API.
- PSR-16 reduziert Komplexität und die Zahl der Konzepte und macht die API kleiner und weniger meinungsstark.
- Dass man einen PSR-6-Adapter für PSR-16-Implementierungen und einen Adapter in die Gegenrichtung bauen kann, zeigt, dass die in PSR-16 entfernte Komplexität nicht essenziell war.
- Manche Bibliotheken und Frameworks können unter dem Namen Developer Experience über die essenzielle Komplexität hinaus anwachsen
- Tatsächliche Einfachheit hat Eigenschaften, die sich mit Kennzahlen wie Zeilenzahl, Anzahl öffentlicher Methoden und Kopplung messen lassen.
- Es gibt Fälle, in denen eine Bibliothek innerhalb weniger Jahre auf das Zehnfache ihrer ursprünglichen Größe wächst und alle 6 bis 12 Monate große Breaking Changes veröffentlicht.
- Auch der Antrieb, eine Bibliothek ohne Wachstum als „tot“ zu betrachten und zu einem „aktiveren“ Paket zu wechseln, kann ein Symptom von Komplexitätsbias sein.
- Um sich ausbreitende Komplexität zu vermeiden, kann es manchmal nötig sein, neu zu bauen
- Wenn man Anforderungen fixieren und ausuferndes Wachstum des Scopes vermeiden kann, kann eine neue Implementierung die einfachere Wahl sein.
- Man sollte darauf achten, keinen der beiden Biases zu verstärken.
1 Kommentare
Hacker-News-Meinungen
Ich habe in einer der FAANG-Firmen gearbeitet, als dort das Lösen komplexer Probleme als Kriterium für Beförderungen galt: Je komplexere Probleme man löste, desto höher stiegen Level, Vergütung und Status.
Ganz natürlich begannen die Leute, nach komplexen Problemen zu suchen, die sich lösen ließen; und als andere Unternehmen die Ideen dieser Firma kopierten, bekamen offenbar selbst kleinere Firmen, die gar keine komplexen Lösungen brauchten, ähnliche Tech-Stacks.
Bei heutigen Auto-UIs, besonders bei den komplexen und schwer zu bedienenden UIs von Elektroautos, hatte ich ähnliche Gedanken; das geht so weit, dass es mich davon abhält, ein Auto zu kaufen, das so etwas verlangt.
Mein Fazit: anspruchsvolle Verbraucher und aspirative Verbraucher sind sehr unterschiedlich, und von Letzteren gibt es viel mehr.
Daher ist es wirtschaftlich rational, anspruchsvolle Verbraucher zugunsten aspirativer Verbraucher zu opfern.
Aspirative Verbraucher akzeptieren Mängel und Augenwischerei, weil sie sie wie Symbole ihres Konsumerfolgs behandeln.
Grob gesagt: Sie sind so begeistert davon, ein „Luxus“-Auto zu fahren, dass sie den mitgelieferten Müll nicht sehen; und als jemand, der seit Jahrzehnten Luxusautos kauft, möchte ich einfach, dass der Schalthebel leicht verständlich ist.
Touch-Ziele wurden ohne Grund viel zu klein, und es wirkt, als hätten Entwickler die UI an feststehenden Displays auf Schreibtischen oder in einem nicht fahrenden Auto entworfen und getestet.
In einem fahrenden Auto bricht alles zusammen.
Neuere Autos ohne Schalthebel, Blinkerhebel, Scheibenwischerhebel und Lichthebel sind ein Chaos.
Wenn man vom Fahrersitz aus auf einem Bildschirm, auf dem man die Hand nirgends ablegen kann, kleine Ziele treffen muss, machen indirekte Bedienung, Verwirrung, Ungenauigkeit und Ablenkung alle zu schlechteren Fahrern.
Sie automatisiert lästige Dinge wie Ver- und Entriegeln, Fenster schließen, Vorheizen und Vorkühlen, morgens automatisch die Navigation zur Arbeit und abends nach Hause einstellen sowie Sitz und Einstellungen je nach verwendetem Handyschlüssel anpassen.
Dank kostenloser Konnektivität funktioniert auch die Navigation richtig; alle eingebauten GPS-Systeme, die ich früher benutzt habe, waren nutzlos.
Die Musikauswahl und der Wiedergabebildschirm sind ebenfalls gut, und Sprachbefehle funktionieren für die Musikauswahl ziemlich ordentlich.
Es ist nicht perfekt, aber ich finde es besser als jedes Auto mit Verbrennungsmotor, das ich bisher gefahren bin.
Morgens zur Arbeit loszufahren besteht aus zwei Schritten: Tür öffnen, Fahrmodus einlegen.
Bei einem Verbrenner im Winter waren es mehr als zehn Schritte: Schlüssel suchen, Auto aufschließen, Tür öffnen, nach der Fahrt meiner Frau den Sitz einstellen, Startknopf, Frontscheibe enteisen, Heckscheibenheizung, Eis von der Frontscheibe kratzen, im GPS die Arbeit auswählen, Parkbremse lösen, Kupplung, Gang einlegen.
Leute, die selbst keinen haben, beklagen online ständig den Touchscreen, aber Tesla-Besitzer bleiben der Marke treu, weil sie unabhängig vom Touchscreen besser ist als andere Autos.
Technology Connections sagte kürzlich in einem Video, dass man einen hässlichen Hebel im 90er-Jahre-Stil vier Sekunden lang gedrückt halten musste, um die Scheibenwischer zu wechseln, und dass man die Bedienungsanleitung lesen musste, um das herauszufinden.
Bei Autos, die aus separat angeflanschten Teilen bestehen, ist so ein Mistverhalten sehr verbreitet.
Mein Auto hingegen schickt mir Benachrichtigungen mit Live-Überwachungsvideo aufs Handy, fährt mich auf dem Arbeitsweg, und beim Schalten ist es meist so, dass das Auto die Richtung selbst wählt, sobald ich angeschnallt bin und die Bremse trete.
Wichtige Funktionen sind nicht über 50 Tasten, sondern kontextbezogen über das Lenkrad zugänglich.
Es ist einfach und zugleich leistungsstark; das Problem liegt darin, dass die Umsetzung bei den erwähnten Luxusautos miserabel ist.
Ich schaue gelegentlich einen YouTuber namens Theo Browne; er ist hauptsächlich Frontend-Entwickler.
Wenn ich sehe, wie er Lösungen erklärt, fühlt es sich an, als hätte mich jemand mit einem Baseballschläger auf den Kopf geschlagen, und die Zahl der Elemente in seinen Demos ist zum Heulen groß.
Auch die Menge an schwer verständlichen React-Begriffen, die in einem einzigen Video vorkommen, erstaunt mich.
Ich will nicht gezielt eine bestimmte Person kritisieren, aber ich frage mich, ob nicht genau diese Komplexität seine Popularität aufrechterhält.
Im Gegensatz dazu schiebt Pieter Levels rohes PHP direkt in Production, ohne über Suspense, serverseitiges Rendering oder Hydration zu sprechen.
Beide erreichen am Ende dasselbe Ziel, aber Pieter Levels dürfte deutlich mehr Geld verdienen, und die Komplexitätslücke ist groß.
Tatsächlich halte ich etwas wie Nomad List für deutlich funktionsreicher als das, was ich bei Theo sehe.
Später erkannte ihn jemand anders, und ich sah, wie Theo eine freundliche, lautstarke Debatte über ein Thema führte, zu dem er sich auf seinem Kanal sehr entschieden geäußert hatte.
Seine Persönlichkeit schien perfekt darauf ausgelegt, Medien-Engagement durch unnötige Komplexität zu maximieren.
Je komplexer etwas ist, desto mehr Stoff für Streit gibt es, und man kann auf Leute, die mit obskuren Optionen nicht vertraut sind, klüger wirken.
Die Menge an Libraries und Code, die in spielzeughaften Beispielen verwendet wird, ist viel größer als das, was man in Production sieht, und ich habe auch schon ziemlich monströse Systeme gesehen.
Ich weiß nicht, wie lange das noch so weitergeht.
Es steckt jede Menge Kram darin, den man nicht nutzen wird, und der behindert ausgerechnet die Teile, die man nutzen will.
Wenn ein Problem auftritt, muss man nun nicht nur die Programmiersprache und den eigenen Code verstehen, sondern auch den Code im Framework entlang des Pfads, den man darin nimmt.
Dieser Pfad kann leicht 10 bis 20 Funktionen tief gehen, und nur äußerst selten ist ausreichend konkret dokumentiert, was in den verschiedenen Edge Cases passiert.
Die Menge an Werkzeugen, die man verwendet, um etwas relativ Einfaches zu bauen, ist enorm, und im DevOps-Bereich scheint etwas Ähnliches zu passieren.
Dieses Problem scheint von den „Frontend-Entwicklern“ in Unternehmen geschaffen worden zu sein.
Eine Art Minderwertigkeitsgefühl gegenüber dem „echten Engineering“ von Full-Stack- oder Backend-Entwicklern scheint im Frontend den Wunsch geweckt zu haben, ebenfalls Probleme für „echtes Engineering“ zu schaffen.
Nach Jahrzehnten in der Entwicklung von Legacy-Systemen habe ich oft erlebt, dass bestimmte Kunden komplexe und fehleranfällige Software bevorzugten – mal durch Designs unserer Firma, mal durch Auftragsarbeiten für Kunden.
Der Grund ist, dass man sich dahinter verstecken kann.
Nach dem Motto: „Die Software hatte Bugs, deshalb wurde ich nicht rechtzeitig fertig“, „Die Software unterstützt Y nicht, deshalb konnte ich X nicht machen“, „Der Hund hat meine Hausaufgaben gefressen“.
In vielen Fällen hätte man eine einfache, leichte und deutlich weniger fehleranfällige Lösung entwerfen können, aber dann wäre es für die Nutzer schwieriger geworden zu verbergen, dass ein bestimmtes Scheitern vielleicht nicht an der Software lag, sondern an ihrer eigenen Unfähigkeit.
Deshalb bevorzugen Manager besonders in Unternehmen mit starkem Druck von oben tatsächlich Software, die sie nicht vollständig verstehen und von der bekannt ist, dass sie Bugs und Probleme hat.
Als ich mit 27 nach fünf Jahren meinen ersten Job wechselte, ersetzte ich ein extrem komplexes GUI-Programm durch eine kleine GUI, die zwei CLI-Programme umhüllte.
Sie funktionierte jedes Mal, auch bei falschen Eingaben, und gab in den seltenen Fällen eines Fehlers hilfreiche Fehlermeldungen aus.
Die drei Frauen, die sie benutzten, hassten mich wirklich.
Erst etwa ein Jahr, nachdem ich die Firma verlassen hatte, verstand ich warum, und damals war ich nicht besonders schlau.
Mit der Zeit kam ich zu der Ansicht, dass Menschen Dinge wie Microsoft Teams wollen, weil sie sich damit bei Bedarf herausreden können.
Bei physischen UIs nennen wir das in unserer Gruppe das Mikrowellenproblem.
Die 20 zusätzlichen Tasten an einer Mikrowelle benutzt niemand, und die meisten verwenden nur ein oder zwei Tasten, aber niemand kauft eine Mikrowelle mit weniger Tasten.
Ich mag meine Samsung ME82V seit zehn Jahren, und zwei Drehregler reichen.
Deshalb bedeutet heimliches Snacken um 2 Uhr morgens, die Mikrowelle zu bewachen wie 1999.
Alles, was man will, sind ein Geschwindigkeitsregler, ein Pulse-Schalter und ein Netzschalter, und alle wollen genau das; aus irgendeinem Grund kommen aber mit jeder Generation haufenweise Funktionen dazu, die niemand nutzt.
Man benutzt nicht unbedingt immer nur dieselben zwei Tasten, also gefällt mir die Möglichkeit, andere Tasten verwenden zu können.
Und wenn es viele Tasten gibt, kommen ziemlich oft auch bessere Spezifikationen dazu.
Weniger Bedienelemente und weniger Funktionen, aber eine hervorragende User Experience.
Ich erinnere mich an die Klarheit des iPod im Vergleich zu Konkurrenzprodukten, die überladen und kompliziert waren.
Solches Lamentieren nervt, weil es voller abgedroschener Maximen steckt
Einstein und Dijkstra zu zitieren lässt einen leicht klug wirken, und mit dem Vorteil der Rückschau sowie Unkenntnis der tatsächlichen Anforderungen ist es ebenso leicht, komplexe Lösungen zu verallgemeinern und mit dem Finger darauf zu zeigen
„So einfach wie möglich, aber nicht einfacher“ ist immer richtig
Wenn eine Lösung chaotisch ist, hätte man sie einfacher machen sollen; wenn eine primitive Lösung Probleme verursacht, hätte man sie eben nicht zu einfach machen dürfen
Es klingt, als hätte man einfach daran denken sollen, es perfekt zu machen
In der Realität ist es schon sehr schwierig, sich überhaupt darauf zu einigen, was einfach ist, wenn eine Lösung mehrere Trade-offs hat
Eine komplexe Datenbank zu betreiben kann „einfacher“ sein, als drei „einfache“ Datenbanken zu haben, den Verwaltungsaufwand zu verdreifachen und am Ende Synchronisierung oder verteilte Transaktionen zu implementieren
Was jetzt leicht zu implementieren ist, kann später komplexe Probleme schaffen, und eine fertige Lösung, die das Problem nicht vollständig löst, erzeugt komplizierte Workarounds für nicht unterstützte Fälle und fügt am Ende noch die Komplexität einer Migration zu etwas Geeignetem hinzu
Der Rat „mach es einfach simpel“ verkennt oft, dass solche Lösungen kein Allheilmittel sind und dass es in der Realität selten eine klare Wahl zwischen komplex und einfach gibt
Projekte haben Zwänge wie bestehende chaotische Systeme, uneinheitliche rechtliche Anforderungen und sich ändernde Geschäftsanforderungen, und vielleicht haben Time-to-Market oder die verfügbaren Kompetenzen bei der Einstellung Vorrang
Auch die Wirtschaftlichkeit ist gnadenlos: Selbst wenn das Erstellen des Jahresberichts wie eine Rube-Goldberg-Maschine wirkt, wird es nur einmal im Jahr genutzt, und ein Rewrite würde sich womöglich nicht einmal in 50 Jahren amortisieren
Diskussionen über Komplexität erkennen kaum an, dass Projekte und Anforderungen wachsen
Was heute vollkommen einfach ist, kann später auf völlig rationale Weise komplex werden, nicht aus Inkompetenz oder böser Absicht
Anfangs ist es wunderbar simpel, Daten in einer Plain-Text-Datei zu speichern, später kann daraus aber eine miserable NIH-Datenbank werden
Umgekehrt ist es Overengineering, für drei Datenzeilen von Anfang an eine Datenbank zu verwenden
Refactoring hat Kosten; immer die ideale Lösung zu verwenden ist also auch nicht so simpel
Viel weniger ist tatsächlich offensichtlich, als man denkt
Die Interpretation, „so einfach wie möglich, aber nicht einfacher“ verlange Perfektion, folgt logisch nicht daraus
In der Praxis weiß man: Iteration schlägt Planung
Wenn es schwierig ist, sich darauf zu einigen, was einfach ist, bittet man nicht um Erlaubnis, sondern um Verzeihung
Das ist eine Regel, die in dieser Branche gilt, und vielleicht auch in vielen anderen
Es gibt definitiv eine bestimmte Art zufälliger Komplexität, die man bei Träumern und Frontend-Entwicklern sieht
Komplexität ist kompliziert
Komplexere Systeme haben außerdem den Sekundäreffekt, dass sie viele Begleitmaterialien wie Tutorials und Videos hervorbringen
Außerdem geben sie den Leuten, die sie gelernt haben, Arbeitsplatzsicherheit, weil sie dadurch zu Personen mit den im Unternehmen benötigten Fähigkeiten und Verantwortlichkeiten werden, statt dass etwas einfach gut funktioniert und solche Leute gar nicht nötig sind
In der IT gibt es sehr viele Jobs, die es nicht gäbe, wenn Software so gebaut wäre, dass sie simpel ist und einfach funktioniert
In einfachen Fällen „funktioniert es einfach“, aber nur, solange man nicht hineinschaut oder versucht, etwas Nichttriviales zu tun
Die Analogie passt vielleicht ziemlich gut
Wenn es um Peer Review von Papers geht: Als Reviewer suche ich in einem Paper weder nach Einfachheit noch nach Komplexität, und auch nicht nach „Neuheit“
Ich suche nach einer gründlichen, zum Nachdenken anregenden empirischen Analyse eines Problems
Unter den Einreichungen gibt es viele, die 1) ein Frankenstein-System vorschlagen, das ein Dutzend bestehender Ideen zusammenflickt, ohne die Fehlermodi der einzelnen Teile gründlich zu analysieren, und mit möglichst vielen aktuellen Spielzeugen, die gerade greifbar sind, erfolgreich „fette Zahlen“ erzielen, oder 2) eine bestehende Methode einfach ein wenig verändern, wodurch die Leistung zufällig besser wird, ohne eine angemessene empirische oder theoretische Begründung dafür, warum es hilft
Der zweite Typ kann für die Community oder die Leser vielleicht einen winzigen Wert haben, aber ich halte ihn größtenteils für nutzlos
Wertvoll für Leser ist es, wenn ein Doktorand ein Problem lange betrachtet hat, seine Intuition in quantitative und überprüfbare Bestätigung überführt und reproduzierbare Beobachtungen mit Vorhersagekraft gewonnen hat
Zum Beispiel: „Wir haben experimentell in allen Fällen verifiziert, dass X über den in diesem Paper beschriebenen Mechanismus Z Y beeinflusst; dadurch wurde die Metrik A um B % verbessert, was mit Z konsistent ist“
Unabhängig von Komplexität reicht ein „Wir haben X gemacht und A ist um B % gestiegen“ nicht aus
Leider stimmen dem nicht alle Reviewer zu
Mein Geschichtslehrer in der Oberstufe gab uns die Aufgabe, einen Essay über die Ereignisse zu schreiben, die zum Zweiten Weltkrieg führten
Die erste Frage war, wie lang er sein müsse, und der Lehrer antwortete, er würde die volle Punktzahl geben, wenn jemand dieses komplexe Thema auf einer A4-Seite behandeln könne, bezweifle aber ernsthaft, dass es in einem so kurzen Text möglich sei
Alle waren von dieser Logik schockiert
Niemand hatte je gehört, dass ein Lehrer so etwas sagte, und es zeigt, dass uns von klein auf beigebracht wird: Mehr ist immer besser
Eine Erklärung kann immer länger oder kürzer gemacht werden, indem man eine Abstraktionsebene wählt, und Menschen wählen diese Ebene normalerweise anhand von Kontext und sozialen Konventionen
Zum Beispiel kann man „wie ein Tastendruck zu einem Zeichen auf dem Bildschirm führt“ in einem Satz erklären, oder man kann daraus mehrere lange Bücher machen, wenn man Firmware, Software-Stack, Elektronik, Materialwissenschaft und Fertigungsprozesse einbezieht
Auch vom Zweiten Weltkrieg kann man sagen, er habe begonnen, als Hitler Poland und France angriff; man kann beim Vertrag von Versailles ansetzen; oder man kann bis zur Evolution des Lebens auf der Erde zurückgehen
Letzteres ist pedantisch, aber technisch gesehen tatsächlich ein Ereignis, das zum Zweiten Weltkrieg führte
Ich empfehle den Vortrag Simple Made Easy von Rich Hickey sehr
Komplexität verkauft sich keineswegs gut, aber Einfaches verkauft sich gut
Wenn ein Unternehmen viele Leute einstellen kann, die mit „foo“ umgehen können, und die Branche ständig über „foo“ spricht, wird es sich für foo entscheiden, selbst wenn foo ein völliges Chaos ist
Man denke an Lambda-Architektur, die meisten Apache-Projekte, Container usw.