TESTE_DEIN_WISSEN
Die Wissenschaft des Entwicklungstempos: Warum Velocity-Vergleiche die falsche Kennzahl sind
«Sie liefert doppelt so schnell wie ich — ich bin wohl nicht dafür gemacht» ist die Art von Gedanken, die Software-Ingenieure ständig durchspielen, meistens um 23 Uhr vor einem halbfertigen PR. Was die Forschung zeigt: Dieser Vergleich steht auf wackligem Fundament. Der ursprüngliche Befund des '10x-Programmierers' stammt aus 12 Personen in einer Studie von 1968, die die Zeit für eine einzelne Aufgabe unter Bedingungen maß, die kaum mit moderner Softwarearbeit vergleichbar sind. Ein halbes Jahrhundert später dokumentierte das SPACE-Framework, dass Entwicklerproduktivität mehrdimensional ist — Geschwindigkeit ist ein Ausschnitt eines viel größeren Bildes, und die anderen Ausschnitte sind in Peer-Vergleichen oft unsichtbar. Eine systematische Kartierung der Burnout-Literatur stellte derweil fest, dass chronische Überlastung ein verlässlicher Prädiktor für Ingenieur-Burnout ist — kein Zeichen außergewöhnlicher Hingabe. Das alte Skript — 'arbeite schneller, beweise deinen Wert' — steht im Widerspruch zu dem, was die Evidenz über gutes Ingenieurwesen zeigt.
TESTE_DICH · Wie gut kennst du diese Forschung?
01 Wie viele Programmierer nahmen an der Sackman/Grant-Studie von 1968 teil, die als Ursprung der '10x-Programmierer'-Behauptung zitiert wird?
McConnells Überprüfung von 2020 verfolgte das '10x'-Label zu einer Studie von 1968 mit nur 12 professionellen Programmierern, die eine einzige Aufgabe abschlossen. Die Ratio maß Debugging-Zeit, nicht allgemeine Produktivität, und die kleine Stichprobe und das Einzelaufgaben-Design wurden selten erwähnt, wenn der Befund später zitiert wurde. Quelle ↗
02 Wofür steht das 'S' im SPACE-Framework?
Das SPACE-Framework von Forsgren et al. steht für Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow. Mit Zufriedenheit zu beginnen spiegelt das Argument der Autoren wider, dass Wohlbefinden sowohl eine Dimension der Produktivität als auch eine notwendige Bedingung für die anderen ist. Quelle ↗
03 Was war laut der systematischen Kartierungsstudie von Tulili, Capiluppi und Rastogi der am häufigsten berichtete Vorläufer von Burnout bei Softwareingenieuren?
Über 74 Primärstudien in der systematischen Kartierung waren Überlastung und hohe Arbeitsbelastung die häufigsten Vorläufer von Software-Ingenieur-Burnout. Die Übersicht identifizierte auch Engagement und Autonomie als die häufigsten Schutzfaktoren — was darauf hindeutet, dass 'mehr arbeiten' keine nachhaltige Produktivitätsstrategie ist. Quelle ↗
04 DORAs Forschung zu hochleistungsfähigen Entwicklungsteams misst vier Schlüsselkennzahlen. Welche Kombination ist korrekt?
DORAs Forschung etablierte Deployment-Frequenz, Lead-Time für Änderungen, Change-Failure-Rate und Time-to-Restore als die vier Schlüsseldimensionen der Software-Delivery-Performance. Diese Metriken balancieren Geschwindigkeit gegen Zuverlässigkeit — Teams, die nur Geschwindigkeit auf Kosten der anderen drei maximieren, erzielen konsequent schlechtere Ergebnisse beim systemweiten Durchsatz. Quelle ↗
05 Was fanden Murphy-Hill und Kollegen als stärksten Prädiktor für individuelle Entwicklerleistung bei Google?
Murphy-Hill und Kollegen fanden, dass Team- und Organisationsfaktoren — einschließlich Code-Review-Last, Meeting-Kultur, On-Call-Belastung und psychologische Sicherheit — die individuelle Entwicklerleistung stärker vorhersagten als individueller Einsatz oder technische Fähigkeiten allein. Das bedeutet, dass zwei gleich fähige Ingenieure in verschiedenen Teams aus strukturellen Gründen dramatisch unterschiedliche Output-Geschwindigkeiten zeigen können. Quelle ↗