6 Minuten
Linus Torvalds, der Schöpfer des Linux‑Kernels, hat eine gängige, aber umstrittene Methode zur Beurteilung von Entwicklerleistung deutlich kritisiert: das Zählen von Codezeilen (engl. lines of code, LOC). In einem ausführlichen Interview auf dem YouTube‑Kanal Linus Tech Tips bezeichnete Torvalds diese Praxis nicht nur als fehlgeleitet, sondern als regelrechte „Inkompetenz“. Seine scharfen Äußerungen haben eine breit geführte Debatte in Entwickler‑Communities wieder entfacht: Was misst echte Softwarekompetenz und wie lässt sich Entwicklerproduktivität sinnvoll bewerten?
Warum das Zählen von Codezeilen eine gefährliche Abkürzung ist
Im Interview brachte der Moderator ein altes, aber immer noch verbreitetes Maß ins Spiel: die Gesamtzahl der geschriebenen Codezeilen. In Berichten über den Eigentümerwechsel bei Twitter (heute X) hieß es, Ingenieure seien angewiesen worden, ihre Quelltextdateien auszudrucken – und wer weniger gedruckte Zeilen vorlegte, galt offenbar als gefährdeter Kandidat für Entlassungen. Torvalds sparte nicht mit klaren Worten: Er nannte die Verwendung von LOC zur Bewertung von Ingenieuren „reine Inkompetenz“ und fügte hinzu: „Wer so denkt, ist zu dumm, in einem Tech‑Unternehmen zu arbeiten.“
Diese harte Einschätzung traf einen Nerv, weil das zugrundeliegende Problem leicht zu verstehen ist: Quantität ist nicht gleich Qualität. Wenn Produktivität anhand der Anzahl der geschriebenen Zeilen gemessen wird, fördert das oftmals unnötige Wortfülle, fragile Implementierungen und komplexe, schwer wartbare Architekturen. Gut entworfene Software erfüllt Anforderungen mit möglichst wenig und klar strukturiertem Code. Diese Ökonomie ist kein Zeichen von Nachlässigkeit, sondern ein Indikator für handwerkliches Können, architektonische Reife und ein tiefes Verständnis des Problems sowie der Plattform.
Darüber hinaus übergeht eine reine LOC‑Metrik zahlreiche Aspekte moderner Softwareentwicklung: Testautomatisierung, Continuous Integration und Delivery (CI/CD), Modultests, Integrationstests, Code‑Reviews und Dokumentation. Viele dieser Aktivitäten führen nicht zu einer hohen Anzahl an Quellzeilen, sind aber entscheidend für Zuverlässigkeit, Skalierbarkeit und Wartbarkeit. Ein Entwickler, der viel Zeit in Refactoring, Testabdeckung und Architekturentscheidungen investiert, kann dieselbe Produktivität liefern wie ein Kollege, der ständig neue Zeilen schreibt, aber technische Schuld und Bugrisiken anhäuft.
Entwickler reagieren: ein nahezu einheitliches Augenrollen
In Entwicklerforen wie Reddit, Hacker News und spezialisierten Slack‑/Discord‑Channels stieß Torvalds' Kritik auf starke Zustimmung. Viele Kommentare reichten von amüsiert bis wütend. Ein häufig gehörter Einwand lautete sinngemäß: „Bereits ein Erstsemester in Informatik weiß, dass LOC die dümmste aller Metriken ist.“ Die Community argumentiert, dass eine derartige Regel zu aufgeblähten Lösungen führt, mehr Fehler produziert und damit genau das Gegenteil von dem bewirkt, was Unternehmen beim Skalieren von Produkten oder Stabilisieren einer Plattform erreichen möchten.
Beispiele, die den Punkt veranschaulichen
- Ein prägnanter Algorithmus mit 100 Zeilen kann eine 1.000‑Zeilen‑Änderung übertreffen, wenn diese nur Logik dupliziert und die Absicht verschleiert. Die kürzere Variante ist oft leichter zu testen und zu verändern; die längere Variante birgt redundante Stellen, die bei Änderungen inkonsistent bleiben können.
- Refactoring reduziert häufig die Anzahl der Zeilen und erhöht gleichzeitig Lesbarkeit und Wartbarkeit. Eine strikte LOC‑Politik würde aber genau dieses positive Verhalten bestrafen, weil weniger Zeilen fälschlich als geringere Leistung interpretiert werden.
- Automatisches Formatieren, ausführliche Logs oder generierter Boilerplate‑Code können die LOC‑Zahl künstlich aufblähen, ohne die eigentliche Funktionalität zu verbessern. Solche Artefakte verfälschen jede Auswertung, die allein auf LOC basiert.
Stellen Sie sich vor, man würde Autoren für die Länge ihrer Essays belohnen, nicht für die Klarheit ihres Arguments. Dasselbe fehlerhafte Prinzip liegt einer Bewertung von Programmierern nach Masse statt nach Handwerk zugrunde. Darüber hinaus erzeugt eine auf LOC beruhende Kultur perverse Anreize: Entwickler könnten in trügerischer Sicherheit mehrzeilige „Lösungen“ implementieren statt eleganter, robuster Designs. Langfristig führt das zu erhöhter technischer Schuld, höheren Betriebskosten und langsamerer Innovationsgeschwindigkeit.
Was Unternehmen stattdessen messen sollten
Wenn nicht Codezeilen, welche Kennzahlen sind dann sinnvoll? Gute Metriken sind solche, die Qualität, Zuverlässigkeit und Geschwindigkeit der Wertschöpfung abbilden. Dazu gehören beispielsweise Code‑Review‑Feedback (Anzahl und Art der Review‑Kommentare), Fehlerraten (Bugs pro Release), Lead Time for Changes (Zeit vom Commit bis zur produktiven Auslieferung), Testabdeckung (Unit, Integration, End‑to‑End) und die Fähigkeit, verlässliche Features pünktlich zu liefern. Diese Kennzahlen sind zwar nicht perfekt, liefern aber wesentlich robustere Hinweise auf nachhaltige Produktivität und Softwarequalität als reine LOC‑Zahlen.
Neben quantitativen Indikatoren spielen qualitative Faktoren eine große Rolle: Zusammenarbeit im Team, architektonisches Denken, die Fähigkeit, komplexe Probleme zu vereinfachen, Mentoring von Junior‑Entwicklern, Wissenstransfer und die Pflege von Dokumentation. Solche Soft Skills lassen sich nicht allein durch Zahlen messen, sind aber entscheidend für langfristigen Erfolg. Manager sollten daher ein ausgewogenes Portfolio von Metriken verwenden und dabei toxische Anreizsysteme vermeiden, die kurzfristiges Verhalten belohnen, aber langfristig schaden.
Technische Führungskräfte können darüber hinaus auf Instrumente und Prozesse setzen, die messbare Verbesserungen fördern: regelmäßige Code‑Reviews mit qualitativen Bewertungen, automatisierte Tests und Metriken zur Teststabilität, Metriken für Build‑ und Release‑Zuverlässigkeit, sowie MTTD/MTTR‑Messungen (Mean Time to Detect / Mean Time to Recover) für Produktionsvorfälle. Diese Indikatoren zeigen, wie schnell ein Team Probleme erkennt und behebt und wie resilient das System insgesamt ist.
Ein weiterer Aspekt ist die Messung des tatsächlichen Geschäftswerts: Wie viele Benutzerprobleme wurden gelöst? Wie viele Kunden‑Feedback‑Items konnten in funktionsfähige Features umgesetzt werden? Wie hoch ist die Kundenzufriedenheit oder Retention nach einer Änderung? Solche Outcome‑orientierten Kennzahlen verbinden technische Arbeit mit geschäftlichem Nutzen und verhindern, dass Entwicklung allein als Zweck in sich selbst missverstanden wird.
Die Auswahl der richtigen Metriken verlangt Balance, Transparenz und regelmäßige Überprüfung. Metriken sollten in Absprache mit Entwicklern und Architekten definiert werden, damit sie sinnvolle Verhaltensanreize setzen. Ein iterativer Ansatz hilft: Man misst, bewertet die Auswirkungen der Metriken auf Verhalten und Outcome und passt sie an, um unbeabsichtigte Nebenwirkungen zu minimieren. Letztlich geht es darum, eine Kultur aufzubauen, die Sauberkeit, Robustheit und langfristige Wartbarkeit honoriert.
Torvalds' Kritik ist deshalb eine Mahnung an technologische Führungskräfte: Wählen Sie Messgrößen, die Wartbarkeit und durchdachtes Design fördern. Andernfalls belohnen Sie genau das Verhalten, das technische Schuld anwachsen lässt und die Produktstabilität untergräbt — ein kostspieliger Fehler für jedes technologiegetriebene Unternehmen.
Quelle: smarti
Kommentar hinterlassen