- In der Software-Engineering-Kultur hält sich eine Struktur, in der Menschen, die komplexe Systeme bauen, mehr Anerkennung bekommen, während diejenigen, die einfache Lösungen wählen, kaum gewürdigt werden
- Bei Beförderungsbewertungen, Interviews und Design-Reviews wird Komplexität oft mit „Impact“ verwechselt, was die Tendenz verstärkt, unnötige Abstraktionen und Erweiterbarkeit hinzuzufügen
- Eine einfache Implementierung bleibt als „unsichtbare Leistung“ zurück, während sich komplexe Strukturen mit glänzenden Beschreibungen und Dokumentation leichter in Beförderungsunterlagen darstellen lassen
- Wahre Kompetenz zeigt sich nicht darin, mehr Tools einzusetzen, sondern in Urteilsvermögen und Selbstvertrauen, zu wissen, wann Komplexität ausgeschlossen werden sollte
- Sowohl Engineers als auch Führungskräfte müssen Einfachheit sichtbar machen und Bewertungs- und Belohnungssysteme schaffen, die sie offiziell anerkennen
Einfachheit vs. Komplexität: die Asymmetrie der Beförderungsnarrative
- Beispiel von zwei Engineers im selben Team: Engineer A liefert ein Feature in wenigen Tagen mit 50 Zeilen prägnantem Code aus, Engineer B führt eine neue Abstraktionsschicht, ein pub/sub-System und ein Konfigurations-Framework ein und ist nach 3 Wochen fertig
- Die Arbeit von Engineer B lässt sich in einem Beförderungspaket als „Entwurf einer skalierbaren ereignisgesteuerten Architektur, Einführung einer wiederverwendbaren Abstraktionsschicht, Aufbau eines Konfigurations-Frameworks“ beschreiben
- Die Arbeit von Engineer A lässt sich dagegen nur mit drei Worten beschreiben: „Feature X implementiert“
- Tatsächlich war es die bessere Arbeit, aber gerade weil sie schlicht wirkte, wurde sie zu einem unsichtbaren Beitrag
- Für „vermiedene Komplexität“ wird niemand befördert — Komplexität wirkt deshalb klug, weil Bewertungssysteme so aufgebaut sind, dass sie sie belohnen
Wie Komplexität in Interviews und Design-Reviews verstärkt wird
- Wenn man in einem System-Design-Interview eine einfache Lösung vorschlägt (eine einzelne Datenbank, eine intuitive API, eine Caching-Schicht), drängt der Interviewer mit „Was, wenn 10 Millionen Nutzer kommen?“
- Je mehr Services, Queues und Sharding man hinzufügt, desto eher hat man die Erfahrung, dass der Interviewer zufriedener wirkt
- Die Lektion, die Kandidaten daraus lernen: „Die einfache Antwort hat nicht gereicht“
- Dass Interviewer Druck machen, kann nachvollziehbare Gründe haben (Denken unter Druck, Prüfung des Verständnisses verteilter Systeme), aber die Botschaft, die bei Kandidaten ankommt, lautet: „Komplexität beeindruckt“
- Auch in Design-Reviews wiederholt sich das Muster, dass auf die Frage „Sollten wir das nicht future-proof machen?“ hin unnötige Schichten und Abstraktionen ergänzt werden
- Nicht weil das Problem es erfordert, sondern weil der Besprechungsraum es erwartet
- Es gibt viele Fälle, in denen eine Abstraktion, die nur ein paar Zeilen doppelten Code vermeiden sollte, das Verständnis und die Wartung am Ende erschwert
- Der Code wirkte zwar „professioneller“, aber die Nutzer bekamen das Feature nicht schneller, und der nächste Engineer verbrachte vor einer Änderung einen halben Tag damit, die Abstraktion zu verstehen
Angemessene Komplexität vs. unnötige Komplexität (Unearned Complexity)
- Komplexität an sich ist nicht das Problem — für die Verarbeitung von Millionen Transaktionen braucht es verteilte Systeme, und wenn 10 Teams am selben Produkt arbeiten, braucht es Service-Grenzen
- Das Problem ist unnötige Komplexität: der Unterschied zwischen „Wir brauchen Sharding, weil wir an die Grenzen der Datenbank gestoßen sind“ und „Wir könnten in 3 Jahren an diese Grenze stoßen, also machen wir jetzt schon Sharding“
- Der Code und die Architektur von Engineers, die das verstanden haben, fühlen sich an wie „na klar“ — ohne Magie, ohne demonstrative Cleverness und ohne das Gefühl, dumm zu sein, weil man es nicht versteht
- Der eigentliche Weg zum Senior-Level besteht nicht darin, mehr Tools und Muster zu lernen, sondern zu wissen, wann man sie nicht einsetzt — Komplexität hinzufügen kann jeder, aber sie wegzulassen erfordert Erfahrung und Selbstvertrauen
Konkrete Ansätze für Engineers
- Einfachheit muss sichtbar gemacht werden — die Arbeit spricht nicht für sich selbst, weil Bewertungssysteme nicht darauf ausgelegt sind, sie zu hören
- Statt „Feature X implementiert“ lieber „Drei Ansätze evaluiert, darunter eine ereignisgesteuerte Architektur und eine benutzerdefinierte Abstraktionsschicht; entschieden, dass eine einfache Implementierung die aktuellen und erwarteten Anforderungen erfüllt; in 2 Tagen ausgerollt und 6 Monate störungsfrei betrieben“
- Sich bewusst dagegen zu entscheiden, etwas zu bauen, ist ebenfalls eine Entscheidung — und eine wichtige; entsprechend sollte sie dokumentiert werden
- In Design-Reviews auf die Frage „Sollten wir das nicht future-proof machen?“ nicht einfach nachgeben, sondern sagen: „So viel Aufwand wäre nötig, um es später hinzuzufügen, so hoch sind die Kosten, wenn wir es jetzt einbauen, und deshalb ist Warten besser“
- Es geht nicht um Widerspruch, sondern darum zu zeigen, dass die Abwägung bereits erfolgt ist
- Das Gespräch mit dem Manager direkt suchen: „Ich möchte, dass die Art, wie ich meine Arbeit dokumentiere, nicht nur den Code, sondern auch die von mir getroffenen Entscheidungen widerspiegelt“
- Aus Sicht des Managers liefert das zugleich die Sprache, mit der sich diese Arbeit vertreten lässt
- Wenn trotz all dieser Bemühungen in einem Team nur die Person befördert wird, die das ausgefeilteste System gebaut hat, dann ist auch das eine nützliche Information — manche Organisationen schätzen Einfachheit wirklich, andere behaupten das nur und belohnen in Wahrheit das Gegenteil
Konkrete Ansätze für Engineering-Führungskräfte
- Anreize zu setzen, ist Aufgabe von Führungskräften — die meisten Beförderungskriterien sind so gestaltet, dass sie Komplexität belohnen, und „Impact“ wird oft an Größe und Umfang dessen gemessen, was gebaut wurde
- Bewertet werden sollte nicht nur, was gebaut wurde, sondern auch, was vermieden wurde
- In Design-Reviews statt „Habt ihr Skalierbarkeit berücksichtigt?“ lieber fragen: „Was ist die einfachste Version, die wir ausliefern können, und welche konkreten Signale würden zeigen, dass wir etwas Komplexeres brauchen?“
- Diese eine Frage verändert das Spiel: Einfachheit wird zum Standard, Komplexität muss sich erst rechtfertigen
- In Beförderungsdiskussionen sollte man bei Paketen, die aus Listen beeindruckender Systeme bestehen, zurückfragen: „War das alles wirklich nötig? Brauchten wir das pub/sub-System tatsächlich, oder sah es nur auf dem Papier gut aus?“
- Wenn ein Teammitglied etwas Sauberes und Einfaches ausliefert, sollte man helfen, das Narrativ dazu zu formulieren — „mehrere Ansätze bewertet und den einfachsten gewählt, der das Problem löst“ wird nur dann zu einem überzeugenden Beförderungsbeispiel, wenn Führungskräfte es auch so behandeln
- Führungskräfte sollten darauf achten, wem sie in Team-Channels öffentlich gratulieren — wenn nur große, komplexe Projekte gelobt werden, optimieren sich Menschen genau darauf
- Anerkennung verdienen auch Engineers, die Code gelöscht haben, und diejenigen, die gesagt haben „Das brauchen wir noch nicht“ und damit richtig lagen
Noch keine Kommentare.