„Dobry programista może być 10-krotnie bardziej produktywny niż mierny” [zamknięty]

Przeczytałem wywiad ze świetnym programistą (nie jest to po angielsku), w którym powiedział, że „świetny programista może być 10 razy tak dobry, jak przeciętny”, podając powód, dla którego dobrzy programiści są bardzo dobrze opłacani i dlaczego firmy programistyczne zapewniają swoim pracownikom wiele udogodnień. Pomysł polegał na tym, że istnieje bardzo duże zapotrzebowanie na dobrych programistów, z powyższych powodów i dlatego firmy płacą za nie bardzo dużo.

Czy zgadzasz się z tym stwierdzeniem? Czy znasz jakieś obiektywne fakty, które mogłyby to poprzeć?

Edycja: pytanie nie ma nic wspólnego z doświadczeniem; jeśli mówisz o jednym świetnym programatorze z rocznym doświadczeniem, to powinien on być 10 razy bardziej wydajny niż mierny programista z rocznym doświadczeniem. Zgadzam się, że od niektórych lat doświadczeń rzeczy zaczynają się rozpraszać, ale nie o to chodzi w tym pytaniu.

Całkiem dokładny przegląd i analiza badań nad różnicami wydajności znajdują się w dwóch artykułach napisanych przez Steve'a McConnella :

• Różnice produktywności wśród programistów i zespołów: geneza „10x”

• Początki 10X - jak ważne są badania leżące u podstaw?

Pierwszy artykuł ( zmiany produktywności ... ) stwierdza:

... Oryginalne badanie, które wykazało ogromne różnice w wydajności indywidualnego programowania, zostało przeprowadzone pod koniec lat 60. XX wieku przez Sackmana, Eriksona i Granta (1968). Przebadali profesjonalnych programistów ze średnio 7-letnim doświadczeniem i stwierdzili, że stosunek początkowego czasu kodowania między najlepszymi i najgorszymi programistami wynosił około 20 do 1; stosunek czasów debugowania powyżej 25 do 1; o rozmiarze programu od 5 do 1; i szybkości wykonywania programu około 10 do 1. Nie znaleźli związku między ilością doświadczenia programisty a jakością kodu lub produktywnością.

Szczegółowe badanie ustaleń Sackmana, Ericksona i Granta pokazuje pewne wady ich metodologii ... Jednak nawet po uwzględnieniu wad, ich dane wciąż wykazują ponad 10-krotną różnicę między najlepszymi programistami a najgorszymi.

Po latach od oryginalnego badania ogólne odkrycie, że „istnieją różnice w rzędach wielkości między programistami” zostało potwierdzone przez wiele innych badań profesjonalnych programistów (Curtis 1981, Mills 1983, DeMarco i Lister 1985, Curtis i in. 1986 , Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm i in. 2000) ...

^{Ten artykuł ma również ciekawą notatkę:}

^{Ten stopień zmienności nie jest unikalny dla oprogramowania. Badanie przeprowadzone przez Norm Augustine wykazało, że w różnych zawodach - pisaniu, piłce nożnej, wynalazkach, pracach policyjnych i innych zawodach - 20% osób wytwarzało około 50% produkcji, niezależnie od tego, czy chodzi o przyziemienia, patenty , rozwiązane sprawy lub oprogramowanie (Augustine 1979).}

Drugi artykuł ( ... Jak ważne są badania podstawowe? ) Został napisany głównie w celu omówienia krytycznej recenzji pierwszego Laurenta Bossavita :

• oryginalna krytyka w języku francuskim: Folklore ou fait scientifique, komentarz les différencier
• Tłumaczenie na język angielski: Fakty i folklor w inżynierii oprogramowania .

W drugim artykule, w sekcji A Głębsze zanurzenie w badaniach, wspierających „10x” McConnell ponownie sprawdza bardziej szczegółowo odniesienia użyte w pierwszym artykule i stwierdza:

... Po ponownym przejrzeniu tych cytatów na piśmie w tym artykule ponownie doszedłem do wniosku, że potwierdzają one ogólne stwierdzenie, że istnieją 10-krotne różnice produktywności między programistami. W badaniach łącznie wzięły udział setki profesjonalnych programistów z całego spektrum działań programistycznych.

... zbiór badań, które potwierdzają 10-krotność twierdzenia, jest tak solidny, jak każde badanie przeprowadzone w inżynierii oprogramowania. Badania, które potwierdzają twierdzenie 10x, w szczególny sposób nie podlegają ograniczeniom metodologicznym opisanym na rycinie 1, ponieważ badają samą indywidualną zmienność (tj. Tylko lewą stronę figury). Bossavit nie cytuje ani jednego badania - wadliwego lub innego - które sprzeciwia się 10-krotnemu twierdzeniu, a także nie widziałem takich badań. Fakt, że żadne badania nie wykazały ustaleń sprzecznych z twierdzeniem 10x, zapewnia jeszcze większe zaufanie do twierdzenia 10x. Biorąc pod uwagę liczbę przeprowadzonych badań, podsumowuję, że badania są nie tylko sugestywne, ale rozstrzygające - co jest rzadkością w badaniach inżynierii oprogramowania.

Dla kompletności lista odnośników użytych w wariantach Produktywność ... jest również cytowana poniżej:

Bibliografia

Augustine, NR 1979. „Prawa Augustyna i główne programy rozwoju systemu”. Przegląd zarządzania systemami obrony: 50–76.

Boehm, Barry W. i Philip N. Papaccio. 1988. „Zrozumienie i kontrola kosztów oprogramowania”. Transakcje IEEE dotyczące inżynierii oprogramowania SE-14, nr. 10 (październik): 1462–77.

Boehm, Barry i in., 2000. Szacowanie kosztów oprogramowania z Cocomo II, Boston, Mass .: Addison Wesley, 2000.

Boehm, Barry W., TE Gray i T. Seewaldt. 1984. „Prototypowanie a określanie: eksperyment z wieloma projektami”. Transakcje IEEE dotyczące inżynierii oprogramowania SE-10, nr. 3 (maj): 290–303. Również w Jones 1986b.

Card, David N. 1987. „Program oceny technologii oprogramowania”. Technologia informacyjna i programowa 29, nr 6 (lipiec / sierpień): 291–300.

Curtis, Bill. 1981. „Zasadnicza zmienność programisty”. Postępowanie IEEE 69, nr. 7: 846.

Curtis, Bill i in. 1986. „Psychologia oprogramowania: potrzeba interdyscyplinarnego programu”. Postępowanie IEEE 74, nr. 8: 1092–1106.

DeMarco, Tom i Timothy Lister. 1985. „Wydajność programisty i efekty miejsca pracy”. Materiały z 8. Międzynarodowej Konferencji Inżynierii Oprogramowania. Waszyngton, DC: IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. Nowy Jork: Dorset House, 1999.

Mills, Harlan D. 1983. Produktywność oprogramowania. Boston, Mass .: Little, Brown.

Sackman, H., WJ Erikson i EE Grant. 1968. „Eksploracyjne badania eksperymentalne porównujące wydajność programowania online i offline”. Komunikacja ACM 11, nr 1 (styczeń): 3-11.

Valett, J. i FE McGarry. 1989. „Podsumowanie doświadczeń z pomiarami oprogramowania w laboratorium inżynierii oprogramowania”. Journal of Systems and Software 9, nr. 2 (luty): 137-48.

Weinberg, Gerald M. i Edward L. Schulman. 1974. „Cele i wydajność w programowaniu komputerowym”. Czynniki ludzkie 16, nr 1 (luty): 70–77.

Naprawdę okropny programista może mieć produktywność poniżej zera (błędy, które wprowadzają, wymagają naprawy dłużej niż wykonanie całej pracy za nich).

A naprawdę świetny programista może robić rzeczy, których biedni i przeciętni programiści nigdy nie osiągnęliby, bez względu na to, ile czasu im dałeś.

Z tych powodów trudno mówić o „10-krotności produktywności” lub „100-krotności produktywności”.

Trzeba jednak pamiętać, że większość pracodawców programistów nie ma potrzeby wykonywania trudnych zadań, z którymi przeciętni programiści nie mogliby sobie poradzić. Większość pisanych kodów to strony internetowe, aplikacje biznesowe, aplikacje intranetowe itp., Wiele z nich naprawdę nie jest tak trudnych. Wydajny programista w tym środowisku to ten, który najlepiej rozumie i realizuje potrzeby użytkowników, a nie ten, który potrafi napisać najmądrzejszy kod.

Rzeczywiście, dla większości pracodawców programistów lepiej byłoby mieć dobrego programistę niż świetnego, ponieważ ten wielki znudzi się i odejdzie. Muszę znaleźć dobre dopasowanie między programistami a zadaniami.

Fakty i wady stanów inżynierii oprogramowania (Fakt 2, dostępny w wersji zapoznawczej Amazon):

Według badań „różnic indywidualnych” najlepsi programiści są do 28 razy lepsi niż najgorsi programiści. Biorąc pod uwagę, że ich wynagrodzenie nigdy nie jest współmierne, są to największe okazje w dziedzinie oprogramowania.

(poszukaj tam listy źródeł do badań)

Oczywiście, jeśli porównasz produktywność nieprogramisty (lub bardzo złego programisty) z dobrym (pod względem doświadczenia i wiedzy), różnica może być nieskończenie duża ( n/0 == infinitydla każdego pozytywnego n), ale nie jest to ani sprawiedliwe ani rozsądne porównanie.

Twoje wynagrodzenie może zależeć od wielu czynników (w losowej kolejności):

• Zastosowane technologie
• Kraj / stan, w którym pracujesz
• Bogactwo firmy
• Rodzaj działalności firmy
• Liczba programistów w firmie
• Jak długo pracujesz w firmie?
• Polityka biurowa

wraz z osobistym ...

• wydajność
• wiedza i doświadczenie
• zaangażowanie w działalność firmy (dla startupów)
• umiejętności negocjacyjne
• atrakcyjność seksualna i umiejętności, lol (cóż, inteligencja jest seksowna)

Moja odpowiedź brzmi „tak, ale uważaj, jak używasz tych danych”.

Programista, który, powiedzmy, działa optymalnie, to ten, który tworzy funkcjonalność i powoduje mniej błędów, które wymagają naprawy, niż jego mniej wydajni bretheren. Nie trudno byłoby mi uwierzyć, że ci ludzie są w stanie osiągnąć 10-krotnie wyższą produktywność od innych, szczególnie gdy weźmie się pod uwagę, że pojedynczy dobry lub zły wybór dokonany w ciągu godziny może z łatwością mieć 10 godzin wpływu, a programiści dokonują wielu takich wyborów większość dni.

Ale...

Bądź ostrożny, mierz to. Naprawdę nie ufam większości pomiarów wydajności, ponieważ widziałem nieskończone przypadki, w których prawie każda znana metryka nie bierze pod uwagę czegoś, co uważam za istotne dla produktywności zespołu. Dlatego generalnie nienawidzę takich twardych liczb za „produktywność”. Oto kilka przykładów:

• Linie kodu (LOC) - ogólnie znienawidzona metryka, ponieważ bezmyślny programista może generować wiele okropnych, pełnych, nieefektywnych, trudnych do debugowania linii kodu, podczas gdy dobry programista tworzy kilka, eleganckich, łatwych do naprawienia, rzadko łamanych linii kodu w dłuższym czasie, ale które są ogólnie lepszym wyborem.
• Błędy generowane i / lub czas na naprawę - każdy wygeneruje błędy, a często najdroższe błędy są generowane przez szereg złych decyzji, dla których generator problemu jest tylko ostatnim efektem domina. Ponadto, twoje świetne debuggery nie zawsze są twoimi świetnymi projektantami - potrzebujesz obu.
• Według niemal każdej metryki, są świetni programiści, którzy tak bardzo cierpią w zespole, że 1 „superproduktywny” programista odeprze 10 zasadniczo dobrych programistów i rzadko widuję kogoś, kto może zrobić wszystko dobrze, więc będziemy potrzebować więcej niż 1 osoba w projekcie.
• Nie ma łatwego sposobu na wyjaśnienie tych cudownych ludzi, którzy widzą problemy, zanim pojawią się na poważnie, i radzą sobie z nimi, szczególnie gdy problemem jest luka w procesie - wadliwe CM, nieefektywna kompilacja, luka w testowaniu, luka bezpieczeństwa - te często wyglądają jak strata czasu, dopóki nie uświadomisz sobie, że ratują cię przed katastrofą - nie ma sposobu, aby to zmierzyć.
• Są też ludzie, których uważam za koniecznych w zespole o określonej wielkości, który nazwałbym „budowniczymi spójności” - rzadko absolutnym szczytem wydajności, zwykle są nadal w górnej 20% i wykonują nieocenioną pracę, pomagając zwiększyć nowi ludzie, łącząc kropki i upewniając się, że zadawane są właściwe pytania, a właściwi ludzie pozostają w pętli, piszą (bez zadania zadania!) kluczową dokumentację, do której wszyscy się odnoszą, ponieważ jest to nie tylko właściwy dokument, ale jest ułożone we właściwy sposób. Jeśli chcesz, aby 10 osób pracowało z maksymalną wydajnością, absolutnie potrzebujesz jednego z tych ludzi i nie dostaniesz go, jeśli umieścisz 10 super programistów w pokoju.

Wiele systemów pomiarowych próbowało wziąć pod uwagę te czynniki, ale nie widziałem jeszcze jednego, który bierze pod uwagę wszystkie te kwestie, więc nigdy nie jestem pod wrażeniem takich czynników, jak: „dobry programista jest 10 razy bardziej wydajny niż przeciętny ”, ponieważ muszę się zastanawiać, czy metryka rzeczywiście odpowiada za całą pracę, która musi zostać wykorzystana do stworzenia udanego produktu na stałe lub odnoszącego sukcesy, dobrze prosperującego zespołu.

Więc moim wielkim zastrzeżeniem jest - co zamierzasz zrobić z tymi danymi? Wykorzystam coś takiego, aby mieć świadomość, że odpowiednie narzędzia i talent mogą spowodować dużą różnicę w sposobie wykonywania pracy, ale jeśli spróbujesz zoptymalizować zespół, w którym każda osoba wytwarza 10-krotność „typowego” wyniku, jesteś zobowiązany przypadek frustracji. Lepiej jest znaleźć sposób, aby twój zespół zrobił 2-3 razy więcej niż wcześniej, dzięki lepszej współpracy.

W swojej książce The Leprechauns of Software Engineering Laurent Bossavit opisuje badanie 10-krotnego wzrostu wydajności. Odkrył, że za tym nie kryją się żadne liczby dźwiękowe - twierdzenie przeszło od spekulacji do „ustalonego faktu” poprzez grę telefoniczną o kolejne, bardziej konkretne cytaty. Wpis na blogu, który zawiera rozdział o 10-krotnym roszczeniu i zawiera odpowiednie cytaty i cytaty, jest faktem i folklorem w inżynierii oprogramowania .

Znalazł coś takiego: ktoś w 1968 roku przeprowadził badanie porównujące ludzi rozwiązujących konkretny problem debugowania i stwierdził, że niektórzy z nich zrobili to 10 razy szybciej niż inni. Z tego możemy wywnioskować, że niektórzy ludzie są 10 razy lepsi w rozwiązywaniu tego problemu , lub możemy dojść do wniosku, że niektórzy mieli szczęście lub wiele różnych rzeczy. Niektóre osoby zdecydowały się zacytować to, ponieważ (wszystkie są parafrazami) „badanie (Sackman i in., 1968) wykazało, że niektórzy programiści pracują 10 razy szybciej niż inni”. Potem stało się „badania wykazały, że dobrzy programiści są 10 razy lepsi niż przeciętni”, a potem „powszechnie wiadomo, że wydajność programistów różni się 10 razy między poszczególnymi osobami”. Następnie ktoś zbiera wszystkie te cytaty, błędnie cytując jedno oryginalne źródło mówiąc „wielu badaczy uważa…”.

Oczywiście nie byłaby to gra telefoniczna, gdyby zmieniła się tylko prawdziwość tego twierdzenia: mnożnik również osiąga 11 .

„ Wydajny programista w tym środowisku to ten, który najlepiej rozumie i realizuje potrzeby użytkowników, a nie ten, który potrafi napisać najmądrzejszy kod. ” ( Odpowiedź Carson63000 )

Ten kluczowy punkt w połączeniu z bethlakshmiPunkty mają ogromne znaczenie. Świetny programista może być świetny w swojej jednej rzeczywistości, ale rozpadnie się, gdy świat się zmieni. Zdolność nadążania za potrzebami firmy jest o wiele ważniejsza niż cokolwiek innego. Ostatecznie, chyba że Twoja firma jest technologią, nie dba o technologię; potrzebują rozwiązań. Tak więc bycie świetnym w zakresie wzorców projektowych nie oznacza, że ​​użytkownicy końcowi, którzy potrzebują zrzutu danych, aby pokazać się na stronie internetowej, nie muszą robić nic prostego. Widziałem przeciętnych programistów, którzy zapewnili sobie pracę, dbając o biznes, który ich wspiera, podczas gdy wielcy programiści nudzą się i odchodzą w poszukiwaniu niekończącego się wyzwania. W zależności od organizacji i projektów możliwe jest nakarmienie tych głodnych wyzwań programistów, ale najprawdopodobniej nadejdzie moment, w którym po prostu Potrzebuję takiej mocy obliczeniowej. Ci programiści nie lubią po prostu siedzieć bezczynnie jak procesor. Wyłączą się i uruchomią ponownie w innym miejscu.

Na koniec powiem, że w porządku jest wiedzieć, kto jest waszym „kluczowym” wykonawcą, ale „zespół” ds. Rozwoju wciąż jest zespołem. Aby powtórzyć bethlakshmi, „ co zamierzasz zrobić z tą miarą?„Jeśli potrzebujesz zespołu, który zachowuje się jak zespół, nie skupiłbym się na takich danych. Zdałbym sobie sprawę, że nawet najmniejszy gracz jest nadal ważną częścią zespołu. Nawet przy 60% mniejszej wydajności twojego klucza gracz, ten jeden gracz może dawać Twojemu zespołowi coś, czego potrzebuje. Dowiedz się, co to jest i spróbuj go pomnożyć. Nie wypalaj swojego kluczowego gracza, zakładając, że powinien on kierować drużyną, znaleźć sposoby na zwielokrotnienie swojej wydajności, przez zanieczyszczenie innych graczy tą wielkością. To wymaga odrobiny kreatywności, nie tylko liczb. W końcu możesz dowiedzieć się, że to, co czyni dobrego programistę, nie jest nawet tym programistą, mogą to być jego rówieśnicy, jego możliwości w miejscu pracy a może nawet ty.