Solange ich in der Softwarebranche tätig bin, spricht man vom 10x-Entwickler. Das sind die Leute, von denen Sie wollen, dass sie Ihre Probleme lösen; sie werden es in einem Zehntel der Zeit und mit einem Zehntel der Anzahl der Codezeilen tun. Sie klingen fantastisch.
Aber woher stammt der Begriff? Gibt es sie? Und selbst wenn, würden Sie überhaupt einer sein wollen?
Tom DeMarco und Tim Lister haben seit 1977 die „Coding War Games“ durchgeführt. Dabei handelt es sich um eine öffentliche Produktivitätsstudie, bei der Teams von Softwareentwicklern aus verschiedenen Unternehmen gegeneinander antreten, um eine Reihe von Benchmarks in kürzester Zeit und mit minimalen Fehlern abzuschließen. Über 600 Entwickler haben daran teilgenommen.
Was haben sie gelernt?
- Die Wahl der Programmiersprache hatte wenig Einfluss – ob es sich um COBOL/Fortran oder eine Hochsprache wie Pascal handelte, die Streuung der Ergebnisse war in etwa die gleiche. Die einzige Ausnahme war Assembler.
- Es gab keinen Zusammenhang zwischen Erfahrung und Leistung, außer dass diejenigen, die weniger als sechs Monate Erfahrung mit einer Sprache hatten, nicht so gut abschnitten wie die anderen.
- Die Entwickler von Null-Fehler-Lösungen zahlten keine Leistungseinbußen dafür, dass sie präziser arbeiteten (sie brauchten sogar etwas weniger Zeit!).
Sie fanden heraus, dass es große Unterschiede zwischen den Organisationen gab. Die beste Organisation arbeitete 11,1 Mal schneller als die schlechteste. Darüber hinaus entwickelten diejenigen, die am schnellsten arbeiteten, einen Code, der die Abnahmeprüfung bestand. Fall abgeschlossen?
Nun, nicht ganz. In der Studie wird dann ein Zusammenhang zwischen der Arbeitsplatzumgebung (die von Unternehmen zu Unternehmen unterschiedlich ist) und der Leistung hergestellt. Es stellte sich heraus, dass die Gruppe mit ruhigem, privatem und eigenem Arbeitsbereich deutlich bessere Leistungen erbrachte.
Lesson learned – sorgen Sie zuerst für die richtige Arbeitsumgebung, bevor Sie sich Gedanken darüber machen, ob Sie 10x Entwickler finden können oder nicht!
Der netto negativ produzierende Programmierer
Schulmeyer stellt fest, dass einige Entwickler „netto negativ produzierende Programmierer“ (NNPP) sind, d.h. sie produzieren so viele Fehler, dass ihre Entfernung aus dem Team die Produktivität erhöht. Dies ist fast das Gegenteil des 10x-Entwicklers – es ist möglich, jemanden im Team zu haben, der es schlechter macht.
Wenn es negative Produzenten gibt (- Nx-Entwickler?), dann ist es eindeutig möglich, einen 10-fachen Entwickler zu haben (abgesehen von der Mathematik).
Das ist allerdings nicht das beste Argument für den 10-fachen Programmierer, oder? Wenn ich ein Schulkind bitten würde, in einem Team mitzuarbeiten, wäre es dann ein Netto-Negativ-Produzent? Wahrscheinlich, wenn ich sie in einer Ecke sitzen und Code eintippen lasse (und wenn sie es irgendwie in die Produktion schaffen!). Wenn Sie die Art von Unternehmen sind, die Leute in der Ecke sitzen lässt, ihnen kein Feedback gibt und sie in die Produktion drängen lässt, dann denke ich, dass Sie es wahrscheinlich verdienen, NNPPs in Ihrem Team zu haben!
Realistischer betrachtet hoffe ich, dass Sie in einem normalen Unternehmen, wenn Sie jemanden einstellen, ihm alle Unterstützung geben, die er braucht, um in seiner Rolle großartig zu sein (Code-Review durch Kollegen, Feedback, einen Mentor, automatische Code-Analyse für Feedback, Lernmaterial usw.)
Ich schätze, es ist immer noch möglich, dass Sie mit einem NNPP enden, aber ich vermute, es ist sehr unwahrscheinlich. Dies scheint jedenfalls nicht die beste Geschichte für die Existenz von 10x-Entwicklern zu sein.
Exploratory experimental studies comparing online and offline programming performance
Sackman, Erikson, Grant veröffentlichten 1968 eine Arbeit mit dem Titel „Exploratory experimental studies comparing online and offline programming performance“. In einem der Zitate am Ende geht es um individuelle Unterschiede und die Studien „zeigten große individuelle Unterschiede zwischen hoher und niedriger Leistung, oft um eine Größenordnung“. Könnte dies das magische Papier sein, das diesen 10-fachen Unterschied beschreibt?
Es lohnt sich, die ganze Studie zu lesen und etwas Kontext zu schaffen. Erstens wurden bei diesen Tests sowohl die Leistung mit Stift und Papier als auch online mit einem IBM AN/FSQ-32 verglichen. Die Programmierer schrieben ihren Code (entweder auf Stift/Papier, um ihn einem Operator zu geben, oder direkt in den Computer) unter Verwendung einer Sprache namens JTS (ein ALGOL-Derivat).
Sie hatten zwei Aufgaben zu lösen, die erste bestand darin, algebraische Gleichungen mit einer einzigen abhängigen Variablen zu interpretieren. Sie bekamen das Papier von Samelson und Bauer, um die Lösung zu implementieren. Ein Bild aus dem Papier ist unten abgebildet:
Die zweite Aufgabe bestand darin, ein 20×20 großes Labyrinth zu lösen, das genau einen Pfad hat. Das Labyrinth wurde durch eine Nachschlagetabelle mit 400 Elementen beschrieben, wobei jeder Eintrag Informationen über die Ausgänge der einzelnen Zellen enthielt. Für diese Aufgabe wurde kein Begleitmaterial zur Verfügung gestellt. Das Lösen von Labyrinthen ist ein faszinierendes Problemfeld, und ich würde vermuten, dass diejenigen, die vor kurzem einen Graphentheoriekurs absolviert hatten, einen großen Vorteil hatten!
Wenn man diese Aufgaben kennt, überrascht es mich nicht, dass es große individuelle Unterschiede gibt. Im Jahr 1968 war die Softwaretechnik als Disziplin gerade erst geboren. Die Aufgaben sind mathematischer Natur und es ist nicht klar, welchen Hintergrund die Teilnehmer hatten. Sicherlich werden diejenigen bevorzugt, die höhere Mathematikkurse besucht haben.
Ich denke, dass die 10-fache Person, die man hier finden würde, begabt ist, diese Probleme zu lösen. Ich kann mir vorstellen, dass es im Problembereich „Lösen eines Labyrinths und linearer Gleichungen“ einen 10x-Entwickler geben kann, aber es ist schwierig, dass sich das auf jeden anderen Bereich übertragen lässt.
Sollte ich ein 10x-Entwickler sein?
Wahrscheinlich. Aber wahrscheinlich 10x besser im Schreiben von Code.
Eine viel bessere Diskussion über die Forschungsmethoden, die hinter dem Mythos des 10x-Entwicklers stehen, gibt es in diesem ausgezeichneten Buch. Selbst wenn es einen 10-fachen Entwickler gibt, sollten Sie wahrscheinlich nicht danach streben, einer zu sein; selbst wenn Sie den Code auf Anhieb perfekt implementieren können, werden Sie wahrscheinlich feststellen, dass Sie von Anfang an das falsche Problem gelöst haben.
Selbst wenn diese Studien wahr wären, hat sich die Softwaretechnik weiterentwickelt (zumindest in meinem Bereich der Produktentwicklung).
In den alten Zeiten haben wir vielleicht eine einzige große Version pro Jahr herausgebracht, hatten einige Anforderungen und verbrachten das Jahr damit, sie zu implementieren. Das hat sich zu einem agilen Ansatz gewandelt, bei dem es einen kontinuierlichen Zyklus von Erfassen, Vorstellen, Implementieren und Überprüfen gibt. In diesem Modell ist die Umsetzung (normalerweise) nicht der Engpass
Eine Stunde, die am Nicht-Engpass eingespart wird, ist eine Fata Morgana. (Eliyahu Goldratt)
Was sollte man also stattdessen tun? Nun, konzentrieren Sie sich darauf, wertvoller für Ihr Unternehmen zu sein. Können Sie:
- Wichtige Probleme für Ihr Unternehmen identifizieren?
- Eine Lösung entwerfen, die Menschen nutzen können?
- Feedback einholen, um zu beurteilen, ob sie wertvoll ist?
- Software schreiben, die für echte Menschen einen echten Unterschied macht?
- Sich auf die wirklichen Probleme konzentrieren und nicht auf die interessanten?
- Mitglieder im Team zu großartigen Menschen machen?
Und eine Million anderer Dinge, die wertvoller sind, als perfekten Code in Rekordzeit zu schreiben (siehe t-förmig!).
Das soll nicht heißen, dass Programmieren nicht wichtig ist. Coding ist wichtig! Code wird 4x öfter gelesen als geschrieben, wenn man also einen leicht verständlichen Code schreibt, zahlt sich das in der Zukunft dramatisch aus (vielleicht ist da irgendwo eine 10x-Geschichte drin, aber das lasse ich für einen anderen Tag). Zeit in Ihr Handwerk zu investieren (sei es Programmierung, Design oder Projektmanagement) ist ein Muss, aber denken Sie daran, dass Ihr Handwerk nicht isoliert existiert, sondern einem höheren Ziel dient.
Konzentrieren Sie sich nicht nur darauf, der beste Entwickler der Welt zu sein, sondern auf das Gesamtbild (denken Sie an Product over Project!). Lernen Sie ein breites Spektrum an Fähigkeiten (vor allem die, die mit Menschen zu tun haben) und Sie werden viel wertvoller und viel näher an einem echten 10x „Entwickler“ sein.