Warum fähige Ingenieure in Großunternehmen schlechten Code schreiben
(seangoedecke.com)- In großen Tech-Unternehmen arbeiten viele Ingenieure aufgrund kurzer Betriebszugehörigkeit und häufiger Reorganisationen an Codebasen, mit denen sie nicht vertraut sind
- Ein erheblicher Teil der Codeänderungen wird in der Praxis von Ingenieuren auf „Anfänger“-Niveau innerhalb der ersten 6 Monate nach dem Einstieg vorgenommen
- Einige erfahrene „Old Hands“ gleichen Qualitätsprobleme aus, stoßen aber wegen Überlastung und informeller Verantwortung an ihre Grenzen
- Unternehmen priorisieren Mobilität der Belegschaft und Lesbarkeit/Überschaubarkeit (legibility) stärker als Fachwissen, und die daraus entstehende Qualitätsminderung ist ein bewusster Preis
- Letztlich ist die Grundursache für schlechten Code unabhängig von den individuellen Fähigkeiten einzelner Ingenieure ein strukturelles Problem: Arbeit in unbekannten Systemen unter hohem Lieferdruck
Die Struktur, durch die in Großunternehmen schlechter Code entsteht
- Große Tech-Unternehmen stellen mit hohen Gehältern fähige Ingenieure ein, doch die Betriebszugehörigkeit liegt oft nur bei 1 bis 2 Jahren
- Aktienvergütungen (share grants) werden oft erst nach 4 Jahren vollständig unverfallbar, wodurch das Gehalt danach faktisch auf die Hälfte sinkt
- Es gibt teils jährliche Refreshes, diese sind aber nicht garantiert, weshalb sich Ingenieure häufig für einen Wechsel entscheiden
- Rechnet man interne Wechsel mit ein, bleiben Ingenieure selten länger als 3 Jahre in derselben Codebasis
- Reorganisationen (re-orgs) finden jährlich oder sogar noch häufiger statt
- Gleichzeitig bestehen Codebasen oft über 10 Jahre oder länger, sodass die meisten Ingenieure ein neues System gerade erst kennenlernen
- Dadurch wird ein erheblicher Teil der Codeänderungen von Anfängern innerhalb der ersten 6 Monate nach dem Einstieg vorgenommen
Die Rolle und die Grenzen der „Old Hands“
- Einige Ingenieure bleiben lange genug in einem bestimmten System, um tiefes Fachwissen aufzubauen
- Sie können Probleme im Code Review früh erkennen
- Diese Struktur ist jedoch informell und nicht institutionalisiert
- Unternehmen haben wenig Interesse daran, langfristige Expertise zu erhalten, und versetzen erfahrene Kräfte oft in andere Teams
- Erfahrene Kräfte sind dauerhaft überlastet
- Ihnen fehlt die Zeit, alle Änderungen selbst zu prüfen
- Wenn ihre eigene Arbeitsleistung sinkt, drohen ihnen im Zweifel sogar Nachteile
Die Realität des durchschnittlich produktiven Ingenieurs
- Der durchschnittlich produktive Ingenieur in einem Großunternehmen hat typischerweise folgende Merkmale
- Er ist gut genug, um den Einstellungsprozess zu bestehen, kennt sich aber mit einer neuen Codebasis oder Sprache noch nicht gut aus
- Gleichzeitig arbeitet er unter überlappenden Deadlines mehrerer Projekte
- Das Ergebnis ist eine Struktur, in der Menschen in einem termingetriebenen Umfeld statt in einem qualitätsgetriebenen Umfeld ihr Bestes geben
- Beispiel: Ein Anfänger behebt einen Bug in unbekanntem Code mit einem Workaround, ein erfahrener Ingenieur schaut kurz darauf und gibt die Änderung frei
- Jahre später taucht dieser Code wieder auf und man fragt sich: „Warum wurde so etwas geschrieben?“
Warum Unternehmen diese Struktur aufrechterhalten
- Großunternehmen gewichten interne Sichtbarkeit/Überschaubarkeit (legibility) höher als Produktivität
- Sie bevorzugen eine Struktur, in der jederzeit erkennbar ist, wer woran arbeitet und wer beliebig umsetzbar ist
- Das ist eine bewusste Entscheidung zulasten von Expertise und Codequalität
- Unternehmen nehmen den Verlust an Erfahrung in Kauf, um bei Problemen Personal schnell neu zu verteilen und flexibel zu bleiben
- Gerade in einer Situation, in der schnelle Pivots in neue Bereiche wie AI wichtig geworden sind, funktioniert diese Strategie aus Unternehmenssicht vorteilhaft
- In einem solchen Umfeld lässt es sich jedoch kaum vermeiden, dass viele Ingenieure unter Zeitdruck in ihnen unbekannten Systemen arbeiten
Die Grenzen des einzelnen Ingenieurs und „reines/unreines“ Engineering
- Einzelne Ingenieure haben keine Macht, diese Struktur zu verändern
- Stand 2025 hat sich das Machtzentrum von Ingenieuren zum Management verschoben
- Das Beste, was Einzelne tun können, ist, in einem bestimmten Bereich zu einem „Old Hand“ zu werden und ein Mindestmaß an Qualität zu sichern
- Zu starkes Eingreifen birgt jedoch das Risiko, wegen zu geringer Leistung (PIP) bewertet zu werden
- Der Text stellt den Unterschied zwischen „reinem (pure)“ und „unreinem (impure)“ Engineering heraus
- Reines Engineering: unabhängige technische Projekte, etwa die Entwicklung von Programmiersprachen
- Unreines Engineering: die reale Arbeitsumgebung, in der man in unbekannten Systemen terminorientiert arbeitet
- Die meisten Ingenieure in Großunternehmen gehören zum unreinen Engineering, und in diesem Kontext ist schlechter Code ein unvermeidliches Nebenprodukt
- Wenn das System ausreichend funktioniert, gilt das Projekt als Erfolg
Fazit: Die unbekannte Codebasis als strukturelle Ursache
- Großunternehmen haben die Macht, Ingenieure frei zu versetzen, und das ist eine bewusste Unternehmensentscheidung trotz des Verlusts an Expertise
- Die Verantwortung für schlechten Code liegt nicht bei Einzelnen, sondern in der Organisationsstruktur und der Art des Personaleinsatzes
- Selbst wenn sich die Fähigkeiten aller Ingenieure verdoppeln würden, würden Fehler in unbekannten Codebasen weiterhin auftreten
- Die eigentliche Grundursache ist eine Struktur, in der „die meisten Ingenieure den Großteil ihrer Arbeit in Code erledigen müssen, mit dem sie nicht vertraut sind“
- Auf Beispiele für schlechten Code hinzuweisen kann bei Verbesserungen helfen, doch nicht die Ingenieure, sondern das System ist das eigentliche Ziel von Kritik
5 Kommentare
Meiner Erfahrung nach schreiben Menschen mit soliden Kenntnissen in CS, insbesondere in PLT, am Ende in nahezu jeder Umgebung vergleichsweise besseren Code.
Auch ohne besonders herausragendes Wissen liefert jemand, der nur die grundlegendsten Prinzipien versteht, mit genügend Zeit und in vertrautem Code immerhin eine gewisse Codequalität ab. Wenn man
n-mal refaktoriert, sieht selbst von einer KI geschriebener Code irgendwann einigermaßen plausibel aus.Es gibt aber auch viele, die selbst dann, wenn sie sich ewig an einer Codebasis festbeißen, trotz angeblich 20 Jahren Berufserfahrung nichts anderes können, als Spaghetti-Code zu produzieren, und nicht einmal verstehen, warum man das nicht tun sollte.
Solange man nicht in einer perfekten Umgebung mit unbegrenzter Zeit und unbegrenztem Budget arbeitet, wirkt das auf mich wie eher leeres Gerede ohne große praktische Bedeutung. Ist das nicht in jeder Epoche und in jedem Beruf im Grunde dasselbe?
Im selben System besseren Code zu schreiben, ist ganz offensichtlich tatsächlich die Fähigkeit eines Engineers.
Es wäre gut, wenn ein System so mit ausreichend Spielraum und flexibel aufgebaut wäre, dass es eine gute Qualität liefern kann. Und verglichen mit einer Zeit, in der Organisationsentwicklung und Entwicklungsmethodik deutlich weniger ausgereift waren als heute, ist das im Durchschnitt sicherlich auch so.
Für mich klingt das allerdings so, als würde jemand mit einem übersteigerten Selbstbild als Ingenieur, aber mit zu wenig Verantwortungsbewusstsein als Mitglied einer Organisation, all das damit entschuldigen, dass nicht er selbst schuld sei, sondern das Management.
Haben Bauingenieure, Industriedesigner und Animatoren keine Deadlines und werden nicht nach Produktivität, sondern nur nach Kreativität und Qualität bewertet, während ausgerechnet nur Programmierer Deadlines haben?
Was für ein verdammter Unsinn das alles ist ... Von schlechtem Code oder gutem Code zu reden, ist etwas, worüber Junioren schwätzen; viel wichtiger ist doch, ob es einen Senior gibt oder nicht, der Softwarearchitektur passend zu der jeweiligen Branche wirklich gut kann..
Die hier geposteten Beiträge bewegen sich meist in einem etwas anderen Umfeld als bestimmte Perspektiven oder Erfahrungen des heimischen SI-Marktes, in dem sogar das OCP oft ignoriert wird.
Wie dem auch sei, Linus Torvalds ist kein Junior ...
Hacker-News-Meinung
Ich habe die Texte dieser Person mehrmals gelesen, und es blieb immer ein gewisses Unbehagen zurück.
Jetzt glaube ich den Grund zu kennen. Die Analyse im Text selbst ist zwar logisch, aber darunter scheint eine Art Nihilismus zu liegen.
Wahrscheinlich war das jemand, der einmal Idealist war, aber durch schlechte Erfahrungen nun erklären will, dass es sinnlos ist, an irgendetwas zu glauben.
Deshalb drängen sich Fragen auf — warum müssen Großunternehmen so handeln, warum quält schlechter Code Ingenieure, ist dieses Gefühl wirklich falsch, oder liegt es an der Wirtschaftsstruktur, in der wir leben, oder gilt Anpassung an große Kräfte als Reife?
Weil ich für die Folgen verantwortlich bin.
Der Zeitplan gerät ins Rutschen, weil ich den chaotischen Code anderer Leute reparieren muss, und dadurch fällt sogar meine Jahresbewertung schlechter aus.
Dann werde ich gefragt: „Warum hat das so lange gedauert?“, aber nur weil ich mich durch einen Müllhaufen wühlen musste, um das Problem zu finden.
Ich habe jahrelang versucht, dem Management solche Probleme verständlich zu machen, aber es fühlte sich am Ende wie Sisyphusarbeit an.
So wie ein Architekt unter einem schlampigen Gebäude leidet oder ein Regisseur unter einem schlecht gemachten Film, strebt ein guter Ingenieur nach Qualität.
Reife bedeutet meiner Meinung nach nicht, sich der Ohnmacht zu fügen, sondern so weit wie möglich dagegen anzukämpfen.
Interessanterweise wird der Autor als Nihilist bezeichnet, aber schon die Vorstellung, dass „die Welt nicht kontrollierbar ist“, ist an sich nihilistisch.
Früher dachte ich auch, alles, was nicht perfekt ist, sei schlechter Code, aber nach mehreren Stationen in verschiedenen Firmen hat sich mein Blick verändert.
Inzwischen finde ich Code akzeptabel, wenn er die Business-Ziele erfüllt und eine grundlegende Qualitätslinie überschreitet.
Letztlich hat fast jeder Code Raum für Verbesserungen.
Ich konnte mich damit identifizieren, weil dort die nüchterne Realität von Staff+-Engineering offen ausgesprochen wurde.
Die Behauptung „Mach, was das Unternehmen will, auch wenn es nicht richtig ist“ ist zynisch, aber ich denke, das ist immer noch besser, als sich von den Zahnrädern des Unternehmens zermahlen zu lassen.
Er glaubt einfach nicht an deine Ideale; das macht ihn nicht automatisch zum Nihilisten.
Das Problem ist nicht die Betriebszugehörigkeit, sondern Motivation.
Es erinnert an die Zeile aus dem Film Office Space: „Wenn harte Arbeit nicht belohnt wird, entsteht keine Motivation.“
Aber das Management legt mehr Wert auf Ergebnisse als auf guten Code.
Da es den Wert von Wartbarkeit nicht beurteilen kann, wird diese Arbeit nicht anerkannt.
Am Ende wird die Person befördert, die schlampigen Code ausgeliefert hat.
Ich habe mein Team und den Code geschätzt und sehr sorgfältig gearbeitet, wurde am Ende aber nach simplen Kennzahlen wie der Anzahl der PRs bewertet.
Die Schwierigkeit des Codes oder mein Beitrag fürs Team wurden ignoriert, wichtig waren nur „sichtbare Zahlen“.
Schließlich wurde sogar der Vorgesetzte, der mich bewertet hatte, ein paar Monate später entlassen.
Ironischerweise hätte mich das alles wohl weniger verletzt, wenn es mir egal gewesen wäre.
Großunternehmen behandeln Ingenieure als austauschbare Ressourcen.
Das ist nicht bloß eine Frage der Effizienz, sondern eine Strategie, das Machtgleichgewicht zugunsten des Managements zu verschieben.
Dahinter steht die Absicht, zu verhindern, dass Kernprojekte von einer bestimmten Gruppe von Ingenieuren abhängen.
Es will, dass alle Arbeitskräfte austauschbar sind.
Viel häufiger versuchen sie, gute Ingenieure zu halten.
Das heißt, diese Kultur ist nicht nur ein Problem des Managements.
Ich sehe oft Fälle, in denen Syntax und Struktur des Codes lehrbuchmäßig sind, der grundlegende Ansatz aber falsch ist.
Code Reviews konzentrieren sich nur auf die Syntax, während über das Business-Problem oder die Komplexität nicht gesprochen wird.
Kurzfristig scheint das okay, langfristig explodiert aber die technische Schuld.
Das Ergebnis ist, dass PRs wegen kleiner Debatten über Codequalität tagelang blockiert werden.
Alle fixieren sich nur auf oberflächliche Code-Sauberkeit.
Logische Tragfähigkeit oder das große Ganze zu beurteilen ist schwierig, und oft kennen die Reviewer den Kontext gar nicht.
Wenn die Organisation insgesamt keinen Spielraum hat, solches Feedback aufzunehmen, verlässt man sich am Ende auf „ein System, das irgendwie läuft“.
Größere Entwürfe sollten vor dem Code Review geprüft werden.
Im Grunde automatisieren wir damit langfristige Kosten.
Großunternehmen interessieren sich nicht für den Code an sich.
Code ist nur das Mittel, das das Unternehmen am Laufen hält.
Entscheidend ist letztlich nicht der Code, sondern der Prozess.
Wenn das System ausfällt, ist die zentrale Frage, ob es Verfahren gibt, um es wiederherzustellen.
Alle Branchen gehen mit wachsender Größe ähnliche Kompromisse ein.
Nicht Perfektion, sondern „gut genug“ erzeugt Gewinn.
Wie beim Unterschied zwischen einem IKEA-Stuhl und einem Herman-Miller-Stuhl sind nur die Rahmenbedingungen andere.
Wahres Können ist die Fähigkeit zu wissen, wo man Kompromisse eingehen muss.
Die Struktur von Großunternehmen zwingt Ingenieure zu solchen Abwägungen.
Gute Senior-Ingenieure schreiben nicht von Anfang an schlechten Code.
Das Problem sind Druck auf kurzfristige Ergebnisse und fehlende Grundlagen.
Das Auslassen von Reviews oder unzureichendes Nachdenken über die Architektur sind die eigentlichen Ursachen.
Wie in diesem Kommentar beschrieben, lässt sich auf einem Codeberg aus Millionen Zeilen angesammelter Hacks trotz aller Bemühungen nichts wirklich sauber machen.
Am Ende ist es, als würde man den ganzen Spaghetti-Haufen anheben.
Seniors stehen ständig vor dem Dilemma zwischen „es richtig machen“ und „es schnell fertig machen“.
Man kann eine komplexe Codebasis nicht über Nacht verstehen, und wenn eine Organisation Wissensaufbau nicht wertschätzt, leidet die Qualität.
Es ist sinnvoll, neuen Mitarbeitern Dokumentations- oder Aufräumarbeiten zu geben, damit sie die Struktur der Codebasis kennenlernen.
Selbst wenn es viel zusammengehackten Legacy-Code gibt, kann man ihn nicht anfassen, weil man ihn nicht kaputtmachen darf.
Selbst die beste Architektur bricht zusammen, wenn das Fundament aus Sand besteht.
Die Schlussfolgerung des Autors, dass „Lesbarkeit Vorrang vor Qualität hat“, würde bedeuten, dass in allen Großunternehmensprojekten statische Analysetools und automatische Formatter Pflicht sein müssten.
In der Realität ist das aber nicht so.
Die Einführung solcher Tools ist eine Entscheidung nichttechnischer Manager, und sie mögen keine kurzfristigen Kosten.
Am Ende überlagert der Release-Zeitplan alles.
Als ich einmal für einen großen Fertigungskonzern beraten habe, gab es im gesamten Code eine seltsame Pattern bei der Objektmodellierung.
Bei der Ursachenanalyse stellte sich heraus, dass das vom Designer beabsichtigte Konzept (Blaupause–Form–Produkt) vom Entwicklungsteam völlig missverstanden worden war.
Ich schlug vor, das zu korrigieren, aber die Antwort lautete: „Dafür ist es schon zu spät.“
Das Ergebnis war, dass über mehr als zehn Jahre hinweg ein falsches Modell bestehen blieb und enorme technische Schuld erzeugte.
Die Statistik zur kurzen Betriebszugehörigkeit in Großunternehmen ist irreführend.
Der Median ist nur deshalb kurz, weil die Belegschaft so stark gewachsen ist.
Eigentlich muss man auf die Werte derjenigen schauen, die das Unternehmen verlassen haben.
Früher gab es schlicht weniger Entwickler.