"Ein guter Programmierer kann zehnmal produktiver sein als ein mittelmäßiger" [geschlossen]

Ich hatte ein Interview mit einem großartigen Programmierer gelesen (es ist nicht auf Englisch) und darin sagte er, dass "ein großartiger Programmierer zehnmal so gut sein kann wie ein mittelmäßiger" und begründete, warum gute Programmierer sehr gut bezahlt werden und warum Programmierunternehmen bieten ihren Mitarbeitern viele Möglichkeiten. Die Idee war, dass es aus dem oben genannten Grund eine sehr große Nachfrage nach guten Programmierern gibt, und deshalb zahlen Unternehmen sehr viel, um sie zu bringen.

Stimmen Sie dieser Aussage zu? Kennen Sie objektive Fakten, die dies unterstützen könnten?

Edit: Die Frage hat nichts mit Erfahrung zu tun; Wenn Sie von einem großartigen Programmierer mit 1 Jahr Erfahrung sprechen, sollte er / sie 10-mal produktiver sein als ein mittelmäßiger Programmierer mit 1 Jahr Erfahrung. Ich bin damit einverstanden, dass sich die Dinge ab bestimmten Erfahrungsjahren allmählich auflösen, aber das ist nicht der Zweck der Frage.

Eine ziemlich gründliche Übersicht und Analyse der Forschung zu Produktivitätsunterschieden finden Sie in zwei Artikeln von Steve McConnell :

• Produktivitätsunterschiede zwischen Softwareentwicklern und Teams: Der Ursprung von "10x"

• Ursprünge von 10X - Wie valide ist das zugrunde liegende Research?

Der erste Artikel ( Produktivitätsunterschiede ... ) lautet:

... Die ursprüngliche Studie, in der große Unterschiede in der individuellen Programmproduktivität festgestellt wurden, wurde Ende der 1960er Jahre von Sackman, Erikson und Grant (1968) durchgeführt. Sie untersuchten professionelle Programmierer mit einer durchschnittlichen Erfahrung von 7 Jahren und stellten fest, dass das Verhältnis der anfänglichen Kodierungszeit zwischen den besten und schlechtesten Programmierern etwa 20 zu 1 betrug. das Verhältnis der Debugging-Zeiten über 25 zu 1; von Programmgröße 5 bis 1; und der Programmausführungsgeschwindigkeit ungefähr 10 zu 1. Sie fanden keine Beziehung zwischen der Menge an Erfahrung eines Programmierers und der Codequalität oder Produktivität.

Eine detaillierte Untersuchung der Ergebnisse von Sackman, Erickson und Grant zeigt einige methodische Mängel auf. Doch auch nach Berücksichtigung der Mängel weisen ihre Daten immer noch einen mehr als zehnfachen Unterschied zwischen den besten und den schlechtesten Programmierern auf.

In den Jahren seit der ursprünglichen Studie wurde die allgemeine Feststellung "Es gibt Unterschiede in der Größenordnung zwischen Programmierern" durch viele andere Studien von professionellen Programmierern bestätigt (Curtis 1981, Mills 1983, DeMarco und Lister 1985, Curtis et al. 1986) , Card 1987, Boehm und Papaccio 1988, Valett und McGarry 1989, Boehm et al 2000) ...

^{Dieser Artikel hat auch eine interessante Randnotiz:}

^{Dieser Variationsgrad gilt nicht nur für Software. Eine Studie von Norm Augustine ergab, dass in einer Vielzahl von Berufen - Schreiben, Fußball, Erfindung, Polizeiarbeit und anderen Berufen - die oberen 20 Prozent der Menschen etwa 50 Prozent des Outputs produzierten, unabhängig davon, ob es sich um Touchdowns oder Patente handelt , gelöste Fälle oder Software (Augustine 1979).}

Der zweite Artikel ( ... Wie gültig ist das zugrunde liegende Research? ) Wurde hauptsächlich geschrieben, um die kritische Überprüfung des ersten Artikels durch Laurent Bossavit zu behandeln :

• Originalkritik auf Französisch: Folklore ou fait scientifique, Kommentar les différencier
• Englische Übersetzung: Fakten und Folklore in der Softwareentwicklung .

Im zweiten Artikel, in Abschnitt A Deeper Dive Into the Research Supporting "10x", überprüft McConnell die im ersten Artikel verwendeten Referenzen noch einmal und zieht folgende Schlussfolgerungen:

... Als ich diese Zitate beim Schreiben dieses Artikels noch einmal überprüfte, kam ich erneut zu dem Schluss, dass sie die allgemeine Feststellung stützen, dass es 10-fache Produktivitätsunterschiede zwischen Programmierern gibt. An den Studien haben Hunderte von professionellen Programmierern aus einem breiten Spektrum von Programmieraktivitäten teilgenommen.

... die Forschung, die die 10x Behauptung stützt, ist so solide wie jede Forschung, die im Bereich Software Engineering durchgeführt wurde. Studien, die die 10x-Behauptung stützen, unterliegen in keiner Weise der in Abbildung 1 beschriebenen methodischen Einschränkung, da sie die individuelle Variabilität selbst untersuchen (dh nur die linke Seite der Abbildung). Bossavit zitiert nicht einmal eine - fehlerhafte oder sonstige - Studie, die der 10-fachen Behauptung widerspricht, und ich habe auch keine derartigen Studien gesehen. Die Tatsache, dass keine Studien Ergebnisse erbracht haben, die der 10x-Behauptung widersprechen, gibt noch mehr Vertrauen in die 10x-Behauptung. Wenn ich die Anzahl der durchgeführten Studien betrachte, finde ich die Forschung insgesamt nicht nur aussagekräftig, sondern auch schlüssig - was in der Software-Engineering-Forschung selten vorkommt.

Der Vollständigkeit halber wird im Folgenden auch eine Liste der Referenzen aufgeführt, die in den Produktivitätsvarianten verwendet werden:

Verweise

Augustine, NR 1979. "Augustines Gesetze und wichtige Programme zur Systementwicklung." Managementbewertung der Verteidigungssysteme: 50-76.

Boehm, Barry W. und Philip N. Papaccio. 1988. "Verstehen und Steuern von Softwarekosten." IEEE-Transaktionen zu Software Engineering SE-14, No. 10 (Oktober): 1462-77.

Böhm, Barry, et al., 2000. Softwarekostenschätzung mit Cocomo II, Boston, Mass .: Addison Wesley, 2000.

Böhm, Barry W., TE Gray und T. Seewaldt. 1984. "Prototyping Versus Specifying: Ein Multiprojekt-Experiment." IEEE-Transaktionen zu Software Engineering SE-10, No. 3 (Mai): 290-303. Auch in Jones 1986b.

Card, David N. 1987. "Ein Software-Technologie-Evaluierungsprogramm." Informations- und Softwaretechnik 29, nr. 6 (Juli / August): 291-300.

Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.

Curtis, Bill et al. 1986. "Software-Psychologie: Die Notwendigkeit eines interdisziplinären Programms." Verfahren der IEEE 74, Nr. 8: 1092 & ndash; 1106.

DeMarco, Tom und Timothy Lister. 1985. "Programmiererleistung und die Auswirkungen des Arbeitsplatzes." Tagungsband der 8. Internationalen Konferenz für Software Engineering. Washington, DC: IEEE Computer Society Press, 268-72.

DeMarco, Tom und Timothy Lister, 1999. Peopleware: Produktive Projekte und Teams, 2d Ed. New York: Dorset House, 1999.

Mills, Harlan D. 1983. Softwareproduktivität. Boston, Mass .: Little, Brown.

Sackman, H., WJ Erikson und EE Grant. 1968. "Explorative experimentelle Studien zum Vergleich der Online- und Offline-Programmierleistung." Mitteilungen der ACM 11, Nr. 1 (Januar): 3-11.

Valett, J. und FE McGarry. 1989. "Eine Zusammenfassung der Erfahrungen mit Softwaremessungen im Software Engineering Laboratory." Journal of Systems and Software 9, No. 2 (Februar): 137–48.

Weinberg, Gerald M. und Edward L. Schulman. 1974. "Ziele und Leistung in der Computerprogrammierung." Human Factors 16, No. 1 (Februar): 70-77.

Ein wirklich schrecklicher Programmierer kann eine Produktivität unter Null haben (die Fehler, die er einführt, brauchen länger, um sie zu beheben, als es nötig wäre, um nur all seine Arbeit für ihn zu erledigen).

Und ein wirklich großartiger Programmierer kann Dinge tun, die arme und durchschnittliche Programmierer einfach nie erreichen würden, unabhängig davon, wie viel Zeit Sie ihnen gegeben haben.

Aus diesen Gründen ist es schwierig, von "10x so produktiv" oder "100x so produktiv" zu sprechen.

Das Wichtigste ist jedoch, dass die meisten Arbeitgeber von Programmierern keine Notwendigkeit haben, die schwierigen Aufgaben zu erledigen, die durchschnittliche Programmierer nicht bewältigen konnten. Der meiste Code, der geschrieben wird, sind Websites, Branchen-Apps, Intranet-Apps usw., ein Großteil davon ist wirklich nicht so schwierig. Der produktive Programmierer in dieser Umgebung ist derjenige, der die Bedürfnisse der Benutzer am besten versteht und umsetzt, und nicht derjenige, der den cleversten Code schreiben kann.

In der Tat wären die meisten Arbeitgeber von Programmierern mit einem guten Programmierer besser dran als mit einem großartigen, denn der großartige wird sich einfach langweilen und gehen. Ich muss eine gute Übereinstimmung zwischen Programmierern und Jobs finden.

Fakten und Irrtümer der Software-Engineering- Staaten (Fakt 2, verfügbar in Amazon Preview):

Die besten Programmierer sind 28-mal besser als die schlechtesten Programmierer, wie aus Untersuchungen zu "individuellen Unterschieden" hervorgeht. Angesichts der Tatsache, dass ihre Bezahlung niemals angemessen ist, sind sie die größten Schnäppchen auf dem Gebiet der Software.

(siehe Quellenliste für Recherchen)

Wenn Sie die Produktivität eines Nicht-Programmierers (oder eines sehr schlechten Programmierers) mit der eines guten (in Bezug auf Erfahrung und Wissen) vergleichen, kann der Unterschied natürlich unendlich groß sein ( n/0 == infinityfür alle positiven n), aber er ist weder gerecht noch gerecht noch sinnvoller Vergleich.

Ihr Gehalt kann von mehreren Faktoren abhängen (in zufälliger Reihenfolge):

• Verwendete Technologien
• Land / Bundesstaat, in dem Sie arbeiten
• Reichtum des Unternehmens
• Geschäftsart des Unternehmens
• Anzahl der Entwickler im Unternehmen
• Wie lange arbeiten Sie in der Firma?
• Büropolitik

zusammen mit Ihrem persönlichen ...

• Produktivität
• Wissen und Erfahrung
• Beteiligung am Unternehmen (für Startups)
• Verhandlungsgeschick
• sexuelle Attraktivität und Fähigkeiten, lol (na ja, Intelligenz ist sexy)

Meine Antwort lautet "Ja, aber seien Sie vorsichtig, wie Sie diese Metrik verwenden".

Ein Programmierer, der, wie wir sagen, optimal funktioniert, schafft Funktionalität und verursacht weniger Fehler, die behoben werden müssen, als seine leistungsschwächeren Kollegen. Es fällt mir nicht schwer zu glauben, dass diese Leute die 10-fache Produktivität anderer leisten können, besonders wenn man bedenkt, dass eine einzige gute oder schlechte Entscheidung in einer Stunde ohne Weiteres 10 Stunden Wirkung haben kann und Programmierer viele solcher Entscheidungen treffen die meisten Tage.

Aber...

Sie müssen vorsichtig sein, wenn Sie dies messen. Ich vertraue den meisten Produktivitätsmessungen wirklich nicht, da ich endlose Fälle erlebt habe, in denen fast jede bekannte Metrik etwas nicht berücksichtigt, was ich für die Teamproduktivität für wichtig halte. Deshalb hasse ich solche harten Zahlen für "Produktivität". Hier sind einige Beispiele:

• Codezeilen (LOC) - eine allgemein verhasste Metrik, da ein gedankenloser Programmierer viele schreckliche, ausführliche, ineffiziente und schwer zu debuggende Codezeilen erzeugen kann, während ein guter Programmierer einige elegante, leicht zu reparierende, selten unterbrochene Codezeilen erzeugt in mehr zeit, aber die sind insgesamt eine bessere wahl.
• Generierte Fehler und / oder Zeit zur Behebung - Jeder wird einige Fehler generieren, und häufig werden die teuersten Fehler durch eine Reihe von Fehlentscheidungen generiert, für die der Auslöser des Problems lediglich der letzte im Domino-Effekt ist. Außerdem sind Ihre großartigen Debugger nicht immer Ihre großartigen Designer - Sie brauchen beides.
• Nach fast allen Maßstäben gibt es großartige Entwickler, die es so schwer haben, in einem Team zu arbeiten, dass 1 "superproduktiver" Entwickler 10 im Grunde gute Entwickler verdrängt und ich selten jemanden sehe, der alles gut kann, also werden wir es brauchen mehr als 1 Person am Projekt.
• Es gibt keine Möglichkeit, diese wunderbaren Leute, die die Probleme sehen, bevor sie ernst werden, einfach zu berücksichtigen und sie zu überwinden, insbesondere dann, wenn das Problem eine Lücke in einem Prozess ist - fehlerhafter CM, ineffizienter Build, Lücke beim Testen, Sicherheitslücke - diese Sieht oft wie eine große Zeitverschwendung aus, bis Sie feststellen, dass sie Sie vor einer Katastrophe bewahren - das lässt sich nicht messen.
• Es gibt auch Leute, die ich als notwendig für ein Team einer bestimmten Größe erachte, die ich als "Kohäsionsbildner" bezeichnen würde - selten die absolute Spitze der Produktivität, sie sind normalerweise immer noch bei den oberen 20% und sie leisten die unschätzbare Hilfe beim Hochfahren Neue Leute, die die Punkte verbinden und sicherstellen, dass die richtigen Fragen gestellt und die richtigen Leute auf dem Laufenden gehalten werden. Sie schreiben (ungefragt!) das Schlüsseldokument, auf das sich jeder bezieht, weil es nicht nur das richtige Dokument ist, sondern auch es ist genau richtig zusammengestellt. Wenn Sie möchten, dass 10 Personen mit maximaler Effizienz arbeiten, brauchen Sie unbedingt einen dieser Mitarbeiter, und Sie werden es nicht bekommen, wenn Sie 10 Superentwickler in einen Raum stecken.

Viele Messsysteme haben versucht, diese Faktoren zu berücksichtigen, aber ich muss erst noch feststellen, dass es einen gibt, der all diese Probleme berücksichtigt. Daher bin ich nie übermäßig beeindruckt von Faktoren wie "Ein guter Entwickler ist 10-mal produktiver als ein mittelmäßig ", weil ich mich fragen muss, ob die Metrik wirklich die ganze Arbeit ausmacht, die für ein erfolgreiches laufendes Produkt oder ein erfolgreiches, florierendes Team erforderlich ist.

Also meine große Einschränkung ist - was wirst du mit dieser Metrik machen? Ich werde so etwas nutzen, um mir bewusst zu machen, dass die richtigen Tools und Talente einen großen Unterschied in der Arbeitsweise bewirken können. Wenn Sie jedoch versuchen, ein Team zu optimieren, bei dem jeder Einzelne das 10-fache der "typischen" Leistung erbringt, sind Sie auf der sicheren Seite ein Fall von Frustration. Besser ist es, einen Weg zu finden, um Ihr Team dazu zu bringen, das 2-3-fache dessen zu tun, was es zuvor getan hat, indem es besser zusammenarbeitet.

Laurent Bossavit beschreibt in seinem Buch The Leprechauns of Software Engineering die Erforschung des 10-fachen Produktivitätsanspruchs. Er stellte fest, dass dahinter keine stichhaltigen Zahlen stecken - die Behauptung hat sich durch ein Telefonspiel mit immer konkreteren Behauptungen zu einer "festen Tatsache" entwickelt . Der Blogbeitrag, der das Kapitel zum 10x-Claim enthält und die relevanten Zitate und Falschzitate enthält, ist Fakt und Folklore in der Softwareentwicklung .

Was er fand, war ungefähr so: Jemand führte 1968 eine Studie durch, in der Leute verglichen wurden, die ein bestimmtes Debugging-Problem lösten, und stellte fest, dass einige von ihnen es 10x schneller taten als andere. Daraus können wir den Schluss ziehen, dass einige Leute das Problem zehnmal besser lösen können , oder dass einige Leute Glück haben oder eine Vielzahl verschiedener Dinge. Einige Leute zitierten dies als (dies sind alles Paraphrasen) "eine Studie (Sackman et al., 1968) ergab, dass einige Programmierer 10x schneller arbeiten als andere". Dann wurde es "Studien haben gezeigt, dass gute Programmierer 10x besser als der Durchschnitt sind", dann schließlich "ist es allgemein bekannt, dass die Produktivität von Programmierern zwischen Individuen 10x variiert". Dann sammelt jemand all diese Zitate und zitiert dabei eine Originalquelle falsch zu sagen "viele Forscher glauben ...".

Natürlich wäre es kein Telefonspiel, wenn sich nur die Richtigkeit der Behauptung ändern würde: Der Multiplikator geht auch auf 11 und darüber hinaus .

" Der produktive Programmierer in dieser Umgebung ist derjenige, der die Bedürfnisse der Benutzer am besten versteht und umsetzt, und nicht derjenige, der den cleversten Code schreiben kann. " (Von Carson63000 Antwort)

Dieser Schlüsselpunkt gepaart mit BethlakshmiDie Punkte von machen einen riesigen Punkt. Ein großartiger Entwickler kann in seinem einen Teil der Realität großartig sein, sich aber auflösen, sobald sich die Welt verändert. Es ist weitaus wichtiger als alles andere, mit den Anforderungen des Unternehmens Schritt zu halten. Letztendlich interessiert sich das Geschäft nicht für Technologie, es sei denn, Ihr Unternehmen ist Technologie. Sie brauchen Lösungen. Mit Designmustern großartig umzugehen, bedeutet also nicht, Endbenutzern, die nur einen Datendump benötigen, um ihn auf einer Webseite anzuzeigen, in die Hocke zu gehen. Ich habe mittelmäßige Entwickler gesehen, die sich einen Job sichern, indem sie sich um das Unternehmen kümmern, das sie unterstützt, während großartige Entwickler sich gelangweilt fühlen und auf der Suche nach einer nie endenden Herausforderung davonlaufen. Abhängig von Ihrer Organisation und Ihren Projekten ist es möglich, diese herausfordernden Entwickler zu unterstützen, aber wahrscheinlich gibt es einen Zeitpunkt, an dem Sie einfach nichts tun. Ich brauche nicht so viel Rechenleistung. Diese Entwickler sitzen nicht gern wie ein Prozessor im Leerlauf. Sie werden an anderer Stelle heruntergefahren und neu gestartet.

Zum Schluss sage ich, es ist in Ordnung zu wissen, wer Ihre "Hauptdarsteller" sind, aber ein "Entwicklungsteam" ist immer noch ein Team. Um Bethlakshmi noch einmal zu wiederholen: " Was werden Sie mit dieser Metrik tun?"Wenn Sie ein Team benötigen, das sich wie ein Team verhält, würde ich mich nicht auf solche Kennzahlen konzentrieren. Ich würde erkennen, dass auch der kleinste Spieler immer noch ein wichtiger Teil des Teams ist. Selbst bei 60% weniger Produktivität Ihres Schlüssels." Spieler, dass ein Spieler Ihrem Team etwas gibt, das es braucht. Finden Sie heraus, was es ist und versuchen Sie es zu multiplizieren. Brennen Sie Ihren Schlüsselspieler nicht aus, indem Sie davon ausgehen, dass er das Team führen sollte. Wenn Sie die anderen Spieler mit dieser Größe kontaminieren, erfordert dies ein wenig Kreativität und nicht nur Zahlen. Am Ende werden Sie vielleicht feststellen, dass ein guter Programmierer nicht nur dieser Programmierer ist, sondern auch seine Kollegen und seine Möglichkeiten am Arbeitsplatz oder es könntest sogar du sein.