FORSCHUNGS_CHRONIK
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.
Wie sich die Wissenschaft verändert hat · 1968–2022
- 1968
Sackman, Erikson und Grant veröffentlichen die Studie, die zum Ursprung des '10x-Programmierers' wurde: 12 professionelle Programmierer bei der Lösung eines einzigen Problems zeigten eine 28:1-Ratio bei der Debugging-Zeit und etwa 10:1 beim Code-Volumen — weithin zitierte Befunde, die aber selten auf ihr enges, auf eine Aufgabe beschränktes Design hin geprüft wurden. ↗
- 2001
Magne Jørgensens Übersicht über Studien zur individuellen Produktivitätsvariation findet, dass die Ratio zwischen Programmierern real ist, aber kontextabhängig — Studien mit unterschiedlichen Aufgaben, Sprachen und Teamkontexten produzierten Ratios von 2:1 bis über 20:1, und warnen davor, irgendeine einzelne Ratio als universell zu behandeln. ↗
- 2019
Storey und Zimmermann befragen 2.000 Microsoft-Entwickler und stellen fest, dass der häufigste Schmerzpunkt für Entwickler nicht langsames Tippen oder Werkzeug-Performance ist, sondern Unterbrechungen und Aufgabenwechsel — und lenken damit den Blick auf Workflow und Umgebung als wichtige Produktivitätshebel, die in Geschwindigkeitsvergleichen unsichtbar sind. ↗
- 2019
Murphy-Hill und Kollegen bei Google veröffentlichen Befunde, dass die individuelle Entwicklerleistung stärker mit Team- und Organisationsfaktoren korreliert — Code-Review-Kultur, psychologische Sicherheit, On-Call-Last — als mit individuellem Einsatz oder roher Ausgabegeschwindigkeit. ↗
- 2020
McConnells Überprüfung der ursprünglichen Sackman/Grant-Studie von 1968 verfolgt genau nach, wie das '10x'-Label in den Volksglauben überging: Die ursprüngliche Ratio bezog sich auf die Debugging-Zeit bei einer Aufgabe für 12 Personen, nicht auf allgemeine Produktivität — und spätere Wiederholungen haben den Befund über fünf Jahrzehnte aufgeblasen und aus dem Kontext gerissen. ↗
- 2021
Forsgren, Storey, Maddila, Zimmermann, Houck und Nagappan stellen das SPACE-Framework in ACM Queue vor: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow — fünf Dimensionen der Entwicklerproduktivität, von denen keine auf Geschwindigkeit allein reduzierbar ist. ↗
- 2022
Tulili, Capiluppi und Rastogi veröffentlichen eine systematische Kartierungsstudie zu Burnout in der Softwareentwicklung, die 74 Primärstudien synthetisiert: Überlastung und hohe Arbeitsbelastung erweisen sich als die in der Literatur am häufigsten berichteten Vorläufer von Burnout, während Engagement und Autonomie als Schutzfaktoren wirken. ↗