it-swarm.com.de

"Ein guter Programmierer kann zehnmal produktiver sein als ein mittelmäßiger."

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?

Bearbeiten: Die Frage hat nichts mit Erfahrung zu tun; Wenn Sie über einen 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 stimme zu, dass sich die Dinge ab bestimmten Erfahrungsjahren auflösen, aber das ist nicht der Zweck der Frage.

54
m3th0dman

Einen ziemlich gründlichen Überblick und eine Analyse der Forschung über Produktivitätsunterschiede bieten zwei Artikel von Steve McConnell :

Der erste Artikel ( Produktivitätsvariationen ...) besagt:

... Die ursprüngliche Studie, in der große Unterschiede in der Produktivität einzelner Programme festgestellt wurden, wurde Ende der 1960er Jahre von Sackman, Erikson und Grant (1968) durchgeführt. Sie studierten professionelle Programmierer mit einer durchschnittlichen Erfahrung von 7 Jahren und stellten fest, dass das Verhältnis der anfänglichen Codierungszeit zwischen den besten und den 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 etwa 10 zu 1. Sie fanden keine Beziehung zwischen der Erfahrung eines Programmierers und der Codequalität oder Produktivität.

Eine detaillierte Untersuchung der Ergebnisse von Sackman, Erickson und Grant zeigt einige Mängel in ihrer Methodik ... Selbst nach Berücksichtigung der Mängel zeigen ihre Daten immer noch einen mehr als zehnfachen Unterschied zwischen den besten und den schlechtesten Programmierern.

In den Jahren seit der ursprünglichen Studie wurde die allgemeine Feststellung, dass "es Unterschiede in der Größenordnung zwischen Programmierern gibt", durch viele andere Studien professioneller Programmierer 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, Polizei Arbeit und andere Berufe - die besten 20 Prozent der Menschen produzierten etwa 50 Prozent des Outputs, unabhängig davon, ob es sich um Touchdowns, Patente, gelöste Fälle oder Software handelt (Augustine 1979).


Zweiter Artikel (... Wie gültig ist die zugrunde liegende Forschung?) wurde hauptsächlich geschrieben, um die kritische Überprüfung der ersten von Laurent Bossavit :

Im zweiten Artikel im Abschnitt Ein tieferes Eintauchen in die Forschung, die „10x“ unterstützt überprüft McConnell die im ersten Artikel verwendeten Referenzen erneut und kommt zu dem Schluss:

... 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 zwischen Programmierern 10-fache Produktivitätsunterschiede gibt. An den Studien waren Hunderte von professionellen Programmierern aus einem Spektrum von Programmieraktivitäten beteiligt.

... die Forschung, die die 10-fache Behauptung stützt, ist so solide wie jede Forschung, die in der Softwareentwicklung durchgeführt wurde. Studien, die die 10x-Behauptung stützen, unterliegen in einzigartiger Weise nicht der in 1 beschriebenen methodischen Einschränkung, da sie die individuelle Variabilität selbst untersuchen (d. H. Nur die linke Seite der Figur). Bossavit zitiert nicht einmal eine Studie - fehlerhaft oder auf andere Weise -, die der 10-fachen Behauptung widerspricht, und ich habe auch keine solchen 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 suggestiv, sondern auch schlüssig - was in der Software-Engineering-Forschung selten ist.


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

Verweise

Augustine, N. R. 1979. "Augustines Gesetze und wichtige Systementwicklungsprogramme." Management Review für Verteidigungssysteme: 50-76.

Boehm, Barry W. und Philip N. Papaccio. 1988. "Softwarekosten verstehen und kontrollieren." IEEE-Transaktionen zur Softwareentwicklung SE-14, Nr. 10 (Oktober): 1462-77.

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

Böhm, Barry W., T. E. Gray und T. Seewaldt. 1984. "Prototyping versus Specifying: Ein Multiprojekt-Experiment." IEEE-Transaktionen zur Softwareentwicklung SE-10, Nr. 3 (Mai): 290-303. Auch in Jones 1986b.

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

Curtis, Bill. 1981. "Substantiating Programmer Variability." Verfahren des IEEE 69, Nr. 7: 846.

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

DeMarco, Tom und Timothy Lister. 1985. "Programmiererleistung und die Auswirkungen des Arbeitsplatzes." Vorträge der 8. Internationalen Konferenz für Software Engineering. Washington, D. C .: 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., W. J. Erikson und E. E. Grant. 1968. "Explorative experimentelle Studien zum Vergleich der Online- und Offline-Programmierleistung." Mitteilungen des ACM 11, Nr. 1 (Januar): 3-11.

Valett, J. und F. E. 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.

41
gnat

Ein wirklich schrecklicher Programmierer kann eine Produktivität unter Null haben (die Fehler, die sie einführen, brauchen länger, um sie zu beheben, als es nötig wäre, nur ihre gesamte Arbeit für sie 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.

Die Sache, an die man sich erinnern sollte, ist jedoch, dass die meisten Arbeitgeber von Programmierern nicht die 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 klügsten Code schreiben kann.

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

92
Carson63000

Fakten und Irrtümer der Softwareentwicklung Zustände (Fakt 2, verfügbar in der Amazon-Vorschau):

Die besten Programmierer sind laut Untersuchungen zu "individuellen Unterschieden" bis zu 28-mal besser als die schlechtesten Programmierer. Da ihre Bezahlung niemals angemessen ist, sind sie die größten Schnäppchen im Softwarebereich.

(siehe Quellenliste dort für Recherchen)

Wenn Sie die Produktivität eines Nicht-Programmierers (oder eines sehr schlechten Programmierers) mit der guten (in Bezug auf Erfahrung und Wissen) vergleichen, kann der Unterschied natürlich unendlich groß sein (n/0 == infinity für jedes positive n), aber es ist weder ein fairer noch ein vernünftiger Vergleich.

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

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

zusammen mit Ihrem persönlichen ...

  • produktivität
  • wissen und Erfahrung
  • beteiligung am Geschäft des Unternehmens (für Startups)
  • verhandlungsgeschick
  • sexuelle Attraktivität und Fähigkeiten, lol (na ja, Intelligenz ist sexy)
30
scriptin

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

Ein Programmierer, der, sagen wir, optimal funktioniert, schafft Funktionalität und verursacht weniger Fehler, die behoben werden müssen, als seine leistungsschwächeren Brüder. Es fällt mir nicht schwer zu glauben, dass diese Leute die 10-fache Produktivität anderer erzielen können, insbesondere wenn man bedenkt, dass eine einzelne gute oder schlechte Wahl 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 gesehen habe, in denen nahezu jede bekannte Metrik etwas nicht berücksichtigt, das ich für die Teamproduktivität als entscheidend erachte. Daher hasse ich im Allgemeinen so harte Zahlen für "Produktivität". Hier einige Beispiele:

  • Lines of Code (LOC) - eine allgemein verhasste Metrik, da ein gedankenloser Programmierer viele schreckliche, ausführliche, ineffiziente und schwer zu debuggende Codezeilen generieren kann, während ein guter Programmierer einige elegante, leicht zu reparierende, selten unterbrochene Codezeilen erstellt in mehr Zeit, aber die sind insgesamt eine bessere Wahl.
  • Generierte Fehler und/oder Zeit zum Beheben - Jeder generiert einige Fehler, und häufig werden die teuersten Fehler durch eine Reihe von Fehlentscheidungen generiert, für die der Generator des Problems lediglich der letzte im Dominoeffekt ist. Außerdem sind Ihre großartigen Debugger nicht immer Ihre großartigen Designer - Sie brauchen beides.
  • Nach fast jeder Metrik gibt es großartige Entwickler, die in einem Team so schmerzhaft sind, dass 1 "superproduktiver" Entwickler 10 grundsätzlich gute Entwickler vertreibt, und ich sehe selten jemanden, der alles kann Nun, wir brauchen also mehr als eine Person für das Projekt.
  • Es gibt keine Möglichkeit, diese wunderbaren Menschen, die die Probleme sehen, bevor sie ernst werden, einfach zu erklären und sie abzulenken, insbesondere wenn das Problem eine Lücke in einem Prozess ist - fehlerhaftes CM, ineffizienter Build, eine Lücke beim Testen, eine Sicherheitslücke - diese Oft sieht es nach großer Zeitverschwendung aus, bis Sie feststellen, dass sie Sie vor einer Katastrophe bewahren - das lässt sich nicht messen.
  • Es gibt auch Leute, die ich für notwendig halte, in einem Team einer bestimmten Größe, die ich als "Kohäsionsbauer" bezeichnen würde - selten die absolute Spitze der Produktivität, sie liegen normalerweise immer noch in den oberen 20% und leisten den unschätzbaren Beitrag zum Hochfahren Neue Leute, die die Punkte verbinden und sicherstellen, dass die richtigen Fragen gestellt und die richtigen Leute auf dem Laufenden gehalten werden, schreiben (unaufgefordert!) die Schlüsseldokumentation, auf die sich jeder bezieht, weil es nicht nur das richtige Dokument ist, sondern es ist genau richtig zusammengestellt. Wenn Sie möchten, dass 10 Personen mit maximaler Effizienz arbeiten, brauchen Sie unbedingt einen dieser Leute, und Sie werden es nicht bekommen, wenn Sie 10 Superentwickler in einen Raum stellen.

Viele Messsysteme haben versucht, diese Faktoren zu berücksichtigen, aber ich habe noch nicht gesehen, dass es eines gibt, das 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 eins ", weil ich mich fragen muss, ob die Metrik wirklich die gesamte Arbeit ausmacht, die für ein erfolgreiches laufendes Produkt oder ein erfolgreiches, florierendes Team erforderlich ist.

Meine große Einschränkung ist also - was machen Sie mit dieser Metrik? Ich werde so etwas verwenden, um mir bewusst zu werden, dass die richtigen Tools und Talente einen großen Unterschied in der Art und Weise bewirken können, wie die Arbeit erledigt wird. Wenn Sie jedoch versuchen, ein Team zu optimieren, in dem jeder Einzelne das 10-fache der "typischen" Ausgabe produziert, sind Sie verpflichtet ein Fall von Frustration. Besser ist es, einen Weg zu finden, Ihr Team dazu zu bringen, 2-3X das zu tun, was es zuvor getan hat, indem Sie besser zusammenarbeiten.

20
bethlakshmi

Laurent Bossavit beschreibt in seinem Buch The Leprechauns of Software Engineering die Erforschung des 10-fachen Produktivitätsanspruchs. Er entdeckte, dass keine soliden Zahlen dahinter stecken - die Behauptung ist durch ein Telefonspiel von sukzessive konkreteren Behauptungen von Spekulationen zu "festgestellten Tatsachen" übergegangen in Zitat. Der Blog-Beitrag, der das Kapitel über den 10x-Anspruch enthält und die relevanten Zitate und falschen Zitate enthält, lautet Fakten und Folklore in der Softwareentwicklung .

Was er fand, ist ungefähr so: Jemand hat 1968 eine Studie durchgeführt, in der Leute verglichen wurden, die ein bestimmtes Debugging-Problem gelöst haben, und festgestellt, dass einige von ihnen es 10x schneller machten als andere. Daraus könnten wir schließen, dass einige Leute 10x besser darin sind , dieses Problem zu lösen , oder wir könnten daraus schließen, dass einige Leute hatte Glück 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" und schließlich "es ist allgemein bekannt, dass die Produktivität von Programmierern zwischen Individuen um das 10-fache variiert". Dann sammelt jemand all diese Zitate und zitiert eine Originalquelle falsch, um 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 auf 11 und darüber hinaus auch.

10
user4051

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

Dieser Schlüsselpunkt in Verbindung mit den Punkten von bethlakshmi macht einen großen Punkt. Ein großartiger Entwickler kann in seinem einen Stück Realität großartig sein, aber auseinander brechen, sobald sich die Welt verändert. Es ist weitaus wichtiger als alles andere, mit den geschäftlichen Anforderungen Schritt halten zu können. Letztendlich kümmert sich das Unternehmen nicht um Technologie, es sei denn, Ihr Unternehmen ist Technologie. Sie brauchen Lösungen. Mit Designmustern großartig umzugehen bedeutet also nicht, dass Endbenutzer, die nur einen Datendump benötigen, um auf einer Webseite angezeigt zu werden, in die Hocke gehen. Ich habe mittelmäßige Entwickler gesehen, die sich einen Job gesichert haben, indem sie sich um das Geschäft gekümmert haben, das sie unterstützt, während großartige Entwickler sich langweilen und auf der Suche nach einer unendlichen Herausforderung davonlaufen. Abhängig von Ihrer Organisation und Ihren Projekten ist es möglich, diese herausfordernden Entwickler zu versorgen, aber wahrscheinlich wird es einen Zeitpunkt geben, an dem Sie einfach nicht so viel Rechenleistung benötigen. Diese Entwickler sitzen nicht gerne wie ein Prozessor im Leerlauf. Sie werden heruntergefahren und an anderer Stelle neu gestartet.

Zuletzt werde ich sagen, dass es in Ordnung ist zu wissen, wer Ihre "Hauptdarsteller" sind, aber ein Entwicklungsteam ist immer noch ein Team. Um bethlakshmi zu wiederholen: " was machst du mit dieser Metrik? " Wenn du ein Team brauchst, das sich wie ein Team verhält, würde ich mich nicht konzentrieren auf Metriken wie diese. Ich würde erkennen, dass selbst der kleinste Spieler immer noch ein wichtiger Teil des Teams ist. Selbst bei 60% weniger Produktivität Ihres Schlüsselspielers kann dieser eine Spieler Ihrem Team etwas geben, das es benötigt. 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, und finden Sie auch Möglichkeiten, seine Leistung zu vervielfachen, indem Sie die anderen Spieler mit dieser Größe kontaminieren. Dies erfordert ein wenig Kreativität, nicht nur Zahlen. Am Ende werden Sie vielleicht lernen, dass das, was einen guten Programmierer ausmacht, nicht einmal dieser Programmierer ist, sondern seine Kollegen, seine Möglichkeiten am Arbeitsplatz oder sogar Sie.

2
Draghon