Świetna wydajność programisty - 10 000-krotna różnica? [Zamknięte]

Wielki operator tokarki rozkazuje kilka razy więcej niż przeciętny operator tokarki, ale wielki pisarz kodu oprogramowania jest wart 10 000 razy więcej niż przeciętny pisarz oprogramowania. - Bill Gates

Powiedzmy, że w tym samym zespole jest „świetny” inżynier oprogramowania i „przeciętny” inżynier oprogramowania. Jak możesz policzyć, że jeden inżynier jest 10 000 razy bardziej wydajny? Nie mogę tego w pełni zrozumieć, biorąc pod uwagę, że obaj biorą udział w funkcjach, błędach i badaniach i konsekwentnie dostarczają jakość. Czy mój opis prawdopodobnie uzasadniałby, że są powyżej „przeciętnej”? "świetny"?

Nie chodzi o to, że jeden z nich jest 10 tys. Razy bardziej produktywny, to taki, że jeden jest 10 tys. Razy drugi. Oprogramowanie ma wyjątkowy warunek, w którym wadliwy projekt lub implementacja może pozostawać w stanie uśpienia przez lata (źle wykonana część zwykle „po prostu„ nie działa ”i nie trafia w teren), aż do cyklu życia produktu, dopóki dzień podnosi głowę w trudnej sytuacji.

Wszyscy powinni być zaznajomieni z wykładniczym kosztem naprawy defektu w fazie projektowania, wdrożenia, testowania, produkcji i konserwacji.

Kiedy bierzesz pod uwagę możliwą odpowiedzialność, a także reputację firmy, łatwo jest stwierdzić, że programista, który wiedział wystarczająco, aby uniknąć problemu, jest wart 10 000 razy ten, który nieświadomie lub naiwnie wdrożył złe rozwiązanie.

Edycja (wiosna 2014): „Heartbleed”

Przeciętny pływak olimpijski może pływać z odległości około 2,5 mil na godzinę.

Przeciętny człowiek (który umie pływać) może pływać około 1,5 mili na godzinę na odległość.

Oznacza to, że przeciętny pływak olimpijski może przepłynąć Kanał La Manche w około 8 godzin.

Byłoby zatem uzasadnione, że pływaczka olymiczna jest o 60% szybsza niż średnia i że przeciętny pływak ukończy wyścig około 13 godzin ...

Tyle że jeśli ja, przeciętny pływak, próbuję przepłynąć Kanał La Manche, jedynym sposobem, przez który przejdę, jest mycie na brzegu tydzień później.

Wiele aspektów programowania przypomina pływanie po kanale La Manche. To jest zlew lub pływanie. Nie wiem nawet, czy 10.000X lepiej jest naprawdę dokładnym sposobem na opisanie różnicy między ukończonym oprogramowaniem, które działa, a niekompletnym oprogramowaniem, które nie działa.

Powiedzmy, że w tym samym zespole jest „świetny” inżynier oprogramowania i „przeciętny” inżynier oprogramowania. Jak możesz policzyć, że jeden inżynier jest 10 000 razy bardziej wydajny? Nie mogę tego w pełni zrozumieć, biorąc pod uwagę, że obaj biorą udział w funkcjach, błędach i badaniach i konsekwentnie dostarczają jakość. Czy mój opis prawdopodobnie uzasadniałby, że są powyżej „przeciętnej”? "świetny"?

To wiele „zalet” dla „przeciętnego” inżyniera oprogramowania. W rzeczywistości wielki inżynier oprogramowania rozwiązuje problemy w ciągu kilku godzin, których przeciętny inżynier nigdy nie rozwiąże poprawnie. Świetny inżynier oprogramowania rozwiązuje zwykłe problemy w jednej trzeciej czasu przy jednej piątej tyle kodu i jednej dziesiątej tyle błędów. Kod wielkiego inżyniera oprogramowania działa w O (n), podczas gdy kod przeciętnego inżyniera oprogramowania działa w czasie O (n ^ 3). Wielki inżynier oprogramowania może dostosować swoje rozwiązanie, gdy czekasz, podczas gdy przeciętny inżynier oprogramowania narzeka na późne zmiany specyfikacji i mówi, że spełnienie nowych wymagań zajmie tygodnie. To są wszystkie prawdziwe różnice, które widziałem, kiedy wielki inżynier przerabia pracę przeciętnego inżyniera.

Spróbuję rozwiązać ten problem pod względem różnic:

Świetny inżynier wykona następujące czynności lepiej niż przeciętny:

• Projekt - twórz projekty, które będą wymagały mniej modyfikacji i będą bardziej elastyczne. Przekłada się to na oszczędności w całym okresie użytkowania oprogramowania.
• Funkcje - będą wdrażane na bieżąco i będą czystszymi implementacjami.
• Błędy - zostaną znalezione szybciej, zostaną dobrze naprawione i nie wprowadzą mniej przyszłych błędów.
• Dochodzenia - zostaną zakończone szybciej dzięki lepszym rozwiązaniom i wynikom.

Reasumując, pozwoliłyby one zaoszczędzić firmie dużo pieniędzy w czasie programowania i sprawić, że firma dużo pieniędzy w dodatkowe możliwości.

Świetny programista często nie tylko „bierze udział w funkcjach, błędach i badaniach”, aby zarobić pensję. Czasami odchodzą i zakładają własną firmę, dołączają do startupu lub rozpoczynają nowy projekt skunkworks, a może w dawnych czasach dołączyli do znanego na całym świecie niebieskiego nieba laboratorium badawczo-rozwojowego i wprowadzają innowacje do produktu, którego nikt nie uważa za potrzebny lub można było pomyśleć o oprogramowaniu, zanim wiedza, umiejętności i pot tego wielkiego programisty były możliwe.

Wiele z tych „wartości” tego programisty dotyczy proporcjonalnej nagrody za ryzyko. Programista mógł nawet zostać zwolniony za myślenie o tak zwariowanych produktach programowych, zamiast zarabiania 2X lub więcej.

Co dzieje się z okazjonalnym uruchomieniem oprogramowania: upublicznienie za milion / miliardy lub zdobycie przez Google lub Facebook, i in. w podobnych ilościach rzadko zdarza się operatorom tokarek (chociaż przynajmniej jeden założyciel firmy technologicznej z Doliny Krzemowej miał tokarkę w swoim warsztacie).

Istnieją rozwiązania, które będą w stanie rozwiązać tylko najlepsi programiści. Rzucanie tysięcy miernych nie zadziała. Jest to także trudniejsze do koordynacji wysiłków, nawet gdyby mogli wspólnie połączyć kawałki ich wiedzy.

Odpowiedzi na pytania dotyczące SO nie są inne. Istnieje wiele problemów, gdzie z grupy przeciętnych programistów, jedna jest w stanie wymyślić odpowiedzi. Strony te prawdopodobnie zrobić o wiele lepiej koordynowania wysiłków niż większości zespołów programistycznych, który jest smutny.

Myślę, że istnieją pewne dowody empiryczne, które obsługuje cytat Gatesa. Pamiętam czytanie (choć nie pamiętam źródła), że w basenach wpisując różnica w wydajności (łatwo mierzalnych dla puli typowania) między tymi w 5. percentyla i te w 95% percentyla było coś jak 3 do 1. Ale po oprogramowanie do przetwarzania słowo stało się dostępne, wskaźnik wzrósł do czegoś jak 10 lub 20 do 1, ponieważ ci, którzy mogliby korzystać z zaawansowanych funkcji oprogramowania zyskał jeszcze bardziej względną przewagę.

Przypuszczalnie w przypadku tworzenia oprogramowania współczynnik byłby jeszcze wyższy, ponieważ istnieje jeszcze większa swoboda w korzystaniu z wszelkiego rodzaju narzędzi, technik itp. Trudniej jest zmierzyć różnice, ale większość prób wychodzi z co najmniej 10 do 1, i że to prawdopodobnie nie doceniając znaczenia, ponieważ jest pomiar tylko to, co jest łatwe do zmierzenia.

Przy pisaniu na maszynie lub obsługiwaniu tokarki osoby w górnym 1% są prawdopodobnie bliskie osiągnięcia fizjologicznych granic tego, co jest możliwe. W przypadku programowania wyraźnie nie są (stosunek jak długo to trwa do zapisu kodu versus jak długo to trwa, aby wpisać się kod jest ogromny), więc nie powinno być miejsca dla większego zróżnicowania więcej.