Jak menedżerowie wybierają języki programowania

Dla nikogo nie jest tajemnicą, że menedżerowie mogą i często narzucą język programowania, który będzie używany w projekcie.

Jako programista nigdy nie byłem w stanie tego zrozumieć.

Ale teraz myślę, że tak: właśnie miałem objawienie, gdy Joel Spolsky powiedział w podcastie, że powinni używać QuickBooks, ponieważ „każdy księgowy na świecie to wie”. Uznałem to za bardzo podobne do „wybrałem Javę, ponieważ każdy programista na świecie o tym wie”.

Teraz, gdy widziałem ten sam problem z innej perspektywy, nie znam się na rachunkowości, ale wiem coś o programowaniu, zastanawiam się, w jaki sposób programista może pomóc upewnić się, że dla projektu wybrano odpowiedni język programowania ?

Błąd, jaki popełniają wielu programistów, polega na tym, że będą argumentować (lub po prostu się z tym zgadzać lub nie zgadzać) na podstawie wyłącznie zalet technicznych. Kierownictwo - i cała firma - muszą argumentować uzasadnienie biznesowe i zalety pierwszej firmy, a technicznej drugiej.

Wykracza to poza wybór języka programowania i przenika praktycznie każdą decyzję techniczną.

Dam ci przykład: komputery osobiste. Joel twierdzi (słusznie), że programiści powinni mieć najlepsze maszyny, ponieważ czas deweloperów jest drogi. Ma w tym całkowitą rację. Ale jak to argumentujesz? Prosty:

Przykład: robię kompilację kodu mniej więcej 20 razy dziennie. Za każdym razem zajmuje to 3 minuty. Gdybym miał szybki komputer, mógłbym go zbudować w 1,5 minuty. Tak więc za dodatkowy 1000 USD co dwa lata mogę dostać dodatkową pół godziny dziennie, co dla programisty zarabiającego 100 000 USD (przy kosztach co najmniej 50% co najmniej), co odpowiada około 10 000 USD rocznie.

Ale z drugiej strony argumentuje, że HR decyduje o tym, że jeden rozmiar pasuje do wszystkich, jeśli chodzi o polisy i komputery osobiste, więc pracownik call center zarabiający 25 000 $ i programista zarabiający cztery razy, który z jakiegoś powodu powinien mieć ten sam komputer.

Platforma technologiczna i języki będą miały wiele czynników wpływających na wybór decyzji:

• Relacje strategiczne z poszczególnymi dostawcami. Jeśli Twoja firma jest Złotym Partnerem Microsoft (lub jakkolwiek się teraz nazywa), powodzenia we wdrażaniu Java lub Pythona;
• Dział IT argumentuje za konkretną konfiguracją, ponieważ pieniądze na komputery PC pochodzą z ich budżetu;
• Informatycy decydują, że każdy powinien uruchomić system Windows 2000, ponieważ nie ma ludzi z Linuksem;
• Jakie inne systemy ma już firma (np. Jeśli używają Javy do wszystkiego innego, sensowne jest użycie jej do tego, nawet jeśli sama może nie być najlepszym wyborem);
• Niechęć do ryzyka dla różnych platform lub języków wynika z braku doświadczenia;
• Bardziej zainteresowany argumentowaniem ryzyka wyższemu kierownictwu niż sprawianiem radości programistom;
• Niektórzy menedżerowie podejmują decyzje po prostu dlatego, że ich ręce są związane;
• Przyczyny budżetowe, chociaż może to również działać na twoją korzyść, ponieważ utrzymuje kosztowne bibuły poza twoim domem, takie jak PVCS, wszystko wyprodukowane przez Rational itp .;
• Niechęć działu prawnego do licencji typu open source;
• Nie angażowanie personelu technicznego w planowanie i szacowanie projektu;
• Znajomość menedżera z konkretną platformą (winni są też ludzie techniczni, ale w obu przypadkach niekoniecznie jest to zła rzecz - z wieloma narzędziami, które mogą lepiej wykonywać pracę diabła, którego znasz).
• Doświadczenie personelu technicznego. Jeśli wszystkie pochodzą z języka C #, dlaczego mieliby używać Java, Python lub Ruby?
• Wiele innych powodów

Niezależnie od przypadku musisz zrozumieć przyczynę (i gwarantuję, że będzie kilka powodów) i pod tym względem uzasadniać zasadność. Niektórzy programiści są dość naiwni w tym dziale i wydają się sądzić, że takie decyzje są podejmowane z ignorancji, a nawet z mściwości, kiedy prawie zawsze bierze się pod uwagę wiele czynników.

Z tego, co wydaje mi się w mojej firmie: kiedy menedżerowie wybierają język programowania, robią to zwykle bardzo konserwatywnie - biorąc pod uwagę, jakie umiejętności programistyczne są obecnie dostępne w zespole (i czy łatwo byłoby zatrudnić dodatkowe ), czy jest to dobrze ugruntowany język, próbujący wybrać coś, co będzie pasować do obecnej infrastruktury i nie będzie wymagało dużych wysiłków, aby dopasować ją do tego, co już istnieje. Kiedy programiści wybierają język programowania, rzeczy często wyglądają nieco inaczej - często lubią stawiać czoła nowym wyzwaniom.

Idealnie wszystko sprowadza się do omówienia zalet i wad menedżera i zespołu programistów oraz znalezienia rozwiązania, które najlepiej pasuje do problemu. Zazwyczaj wymaga to dużo mówienia i przekonywania :-)

Późna odpowiedź, ale ponieważ nie ma jeszcze akceptowanej odpowiedzi, spróbuję. Przyjmuję to jako dwa pytania i spróbuję na nie odpowiedzieć osobno:

Jak menedżerowie wybierają języki programowania?

W dużej mierze zależy od wielkości organizacji i doświadczenia menedżera, ale generalnie będzie polegać na ocenie obecnej sytuacji oraz przyszłych scenariuszy i wymagań. Zwykle odbywa się to za pomocą PESTLE lub podobnej analizy i tylko po to, aby podać kilka próbek w każdej kategorii:

• Polityczny
  • „Nikt nie został zwolniony za zakup IBM” - bezpieczny wybór.
  • Prezes usłyszał, że Java jest fajna - szum.
  • Główny architekt uwielbia .NET - projekt dla zwierząt.
  • Językiem kontroluje wrogi konkurent - dlaczego Google nie polega na C #.
• Ekonomiczny
  • Koszty licencjonowania.
  • Koszt szkolenia programisty.
  • Koszty migracji bazy kodu.
• Społeczny
  • Wpisowe od zespołu.
  • Dostępność umiejętności w domu (potrzeby szkoleniowe, ciągłość).
  • Dostępność umiejętności na rynku.
  • Zagrożenie dla istniejącego status quo w zespole deweloperów.
  • Dostępność wystarczająco dużej społeczności praktyk.
• Techniczny
  • Poprawa wydajności.
  • Polepszanie jakości.
  • Możliwość współpracy z istniejącą bazą kodu.
  • Przestrzeganie standardów.
  • Dojrzałość.
• Prawny
  • Warunki licencyjne.
  • Kontrola technologii (Kto jest właścicielem technologii i kontroluje ją? Jaka może być strategia licencjonowania w przyszłości?)
  • Zgodność z prawem i przepisami.
• Środowiskowy
  • Istniejąca infrastruktura w firmie.
  • Istniejące umiejętności w firmie.
  • Integracja z partnerami zewnętrznymi.
  • Poziom wsparcia technologicznego przez szersze środowisko.

Następnie kilka języków spełniających kryteria może być dalej oceniane za pomocą SWOT , analizy kosztów i korzyści lub podobnych.

Cały proces może być dość złożony, ale w ostatecznym rozrachunku większość firm lub zespołów projektowych wybierze najbezpieczniejszą opcję, biorąc pod uwagę ich obecną sytuację, która wciąż może zapewnić potrzebne im możliwości. Dość często może to oznaczać dłuższe trzymanie się obecnej platformy.

W jaki sposób programista może pomóc upewnić się, że dla projektu wybrano odpowiedni język programowania

Jak się okazało, mam nadzieję, że wykazano, że typowy programista zwykle miałby tylko 1/6 całkowitego wkładu w proces decyzyjny. I z reguły ona lub on byliby zainteresowani wyłącznie umiejętnościami językowymi!

Cóż, najlepszym sposobem na wpływ na decyzję wydaje się mieć szerszy obraz procesu selekcji, zawieranie sojuszników w zespole i poza nim, tworzenie dobrego opisu strony technologicznej i staranie się nie koncentrować wyłącznie na umiejętnościach językowych.

I oczywiście trzeba zająć pozycję, gdy kierownik projektu lub rozwoju (lub ktokolwiek inny odpowiedzialny) dostrzeże korzyści płynące z całego procesu oceny i jest przygotowany do rozważenia ryzyka i niepewności związanych z przejściem na inną język w pierwszej kolejności. Aby tak się stało, należy wykazać, że:

1. Obecna platforma nie jest już wystarczająca.
2. Nowa platforma obiecuje korzyści, które zdecydowanie przewyższają problemy.

Jednak gdybyś zapytał „Jaki jest najlepszy sposób, aby móc używać w pracy języka, który lubię”, odpowiedzią byłaby prawdopodobnie „dołącz do firmy, która już używa tego języka lub załóż własny”.

Menedżer A jedzie na letnie rekolekcje, gdzie spotyka menedżera B.

Odp .: Więc jakiego języka używasz w swojej firmie? B: Och, używamy CA Visual Objects, dzięki czemu drony są o wiele bardziej produktywne niż COBOL.

I tak podjęto decyzję. Koniec prawdziwej historii.

Każda platforma ma dobre i złe strony. .NET jest fajny i wydajny, ale utknąłeś z serwerami Windows. Ruby jest fajna, ale powolna. Trudno byłoby znaleźć programistów dla Haskell.

Chodzi o to, że język nie wpływa na to, jak szybki będzie projekt i na jaki piękny będzie kod, ale także na tych, na których zależy menedżerom. Więc jeśli chcesz na nich wpłynąć, powinieneś teraz wybrać ich preferencje i znaleźć jak najwięcej dobrych stron w ich perspektywie, jak to możliwe.

Oddzielając obawy. Biznes powinien odpowiadać za decyzje biznesowe, a technologia za decyzje techniczne. Podoba mi się termin „Zaakceptowana odpowiedzialność”. Jeśli mam przyjąć odpowiedzialność, wymagam również dokonania wyborów, które dotyczą mojej dziedziny problemu. Biznes daje mi i moim współpracownikom technicznym wymagania biznesowe, a my odpowiadamy jedną lub dwiema alternatywami, w jaki sposób możemy przyjąć odpowiedzialność za dostarczanie. Nigdy nie powinno być tak: „zrobimy to w Pythonie lub C #”. Raczej;

„Możemy tutaj przyjąć dwie różne obowiązki: jeśli pójdziemy tą drogą, możemy dostarczyć to szybko i naprawdę dobrze sprostać tym wymaganiom biznesowym, a są one nieco trudniejsze. Moglibyśmy to zrobić w ten sposób, a to daje przewagę tym wymaganiom biznesowym Alternatywa A wymaga tych zasobów, a alternatywa B oznacza, że ​​musimy to zrobić i to ... ”

Następnie biznes wybiera, ale pamiętaj, że biznes wybiera na podstawie wpływu na sprawy biznesowe, a nie techniczne. I nie mogą wybierać między alternatywami, w których technologia nie jest gotowa zaakceptować odpowiedzialności części technologicznej.

Zostań menadżerem. (szeroki uśmiech)

Poważnie, wystarczy przedyskutować sprawę z danym decydentem i przedstawić swoje argumenty. Jeśli zdecydują się trzymać z naprawdę niewłaściwą decyzją, wówczas ich ogólne kompetencje prawdopodobnie nie są tak gorące i warto poszukać czegoś innego.

Myślę, że różnica między tym, o czym mówisz, a tym, o czym mówił Joel, polega na tym, że programowanie jest podstawową kompetencją, podczas gdy księgowość nie. Chodzi przy użyciu QuickBooks jest przypuszczalnie dlatego, że jesteś nie księgowy i księgowych może pomóc z tym. Jeśli jednak programowanie jest twoją podstawową kompetencją i przypuszczalnie tak jest, jeśli jesteś programistą, zasady gry są nieco inne.

To bardzo zależy od osobowości kierownika:

Są takie, które używają modnych słów. Dowiedz się, które modne słowa lubią, i używaj go, rozmawiając z nim w języku, którego chcesz używać.

Inni ufają tylko tym, co sami znają (na przykład VB 6.0). Spraw, aby Twój wybrany język był dla nich łatwy do zrozumienia („wiesz, to tak jak w starym dobrym VB” - nawet jeśli mówisz o Haskell ...)

Ale w rzeczywistości większość menedżerów nie jest tak głupia, jak my, maniacy, lubimy myśleć i można to uzasadnić. Ważne jest, abyś zrozumiał ich punkt widzenia: zazwyczaj nie dbają o konkretne szczegóły techniczne, dbają o wyniki. Więc nie mów im, że .net, Java, Delphi lub cokolwiek ma tę niesamowitą funkcję megacool. Powiedz im, że (wpisz swój język tutaj) jest dobrym wyborem, ponieważ funkcja A skraca czas programowania w takim projekcie lub ta funkcja B powoduje mniej błędów, a zatem skraca czas potrzebny na testowanie. Tylko upewnij się, że twój argument jest rozsądny, nie okłamuj go.

Innymi słowy: traktuj go jak inteligentną istotę (prawdopodobnie jest).

Pomyśl o języku, którego chcesz używać bardzo, bardzo mocno. Upewnij się, że wiesz, że nie jest to dobry język dla pracy, a następnie zapytaj kierownika, czy możesz zasugerować inny, lepszy język do wykorzystania w pracy. Podaj wszelkie możliwe informacje, które dowodzą, że język nie byłby odpowiedni do pracy i zobacz, co mówi. To nie może boleć. :)

Wybór języka programowania jest często decyzją biznesową. Klienci / Użytkownicy nie dbają o to. Oto krótki cytat (z http://www.ericsink.com/bos/Geeks_Rule.html ):

Języki programowania wybierane są głównie ze względów biznesowych. Większość czasu spędzam na pracy z językami, które tak naprawdę nie lubię, ponieważ języki, z którymi chciałbym pracować, mają wady biznesowe przewyższające ich zalety techniczne. Taka jest natura gry. Mogę zaakceptować sytuację (mój wybór) lub znaleźć nowego pracodawcę. Narzekanie na temat tego, jak nie mogę korzystać z Javy, Pythona lub czegokolwiek w pracy, po prostu nie wchodzi w grę.

Przede wszystkim programowanie to kolejna forma sztuki. Bardzo logiczna forma sztuki. Jeśli menedżerowi zależy na jego niezwykłych projektach programowych, które w pewnym stopniu są dziełem arcydzieła, zapytaj go:

Ile energii i czasu kosztowałoby Rembrandta dodatkowo, aby nie malować swoim ulubionym pędzlem, ale pędzlem, który po uważnym rozważeniu kierownictwa został mu przekazany 400 lat temu i zanim jego prace stały się sławne. Czy jego obraz będzie mniej lub bardziej warty myślenia?

Podobnie, jeśli mówisz programistom, jakiego języka należy użyć, to bądź konsekwentny, a także powiedz malarzowi, jakich rozmiarów pędzla należy użyć! LUB, alternatywnie, pozostaw ten wybór ludziom, którzy muszą z nim pracować każdego dnia i (jak większość arcydzieł) nocy!

To są różne koncepcje.

Podczas księgowania udostępniasz swoje wyniki: podatki, prawo, inwestorzy itp. Potrzebują narzędzia, aby zobaczyć wyniki pracy, a to narzędzie musi być dobrze znane.

Podczas programowania korzystasz z dowolnego narzędzia - o ile wyświetla ono .exeplik, który można uruchomić w systemie Windows. W przypadku rachunkowości jest to dokładnie to samo, co dokument czytelny w Quick Books.

Tak więc, jeśli opracujesz toster, możesz zachować wewnętrzną dokumentację w języku chińskim, ale lepiej dostarcz podręcznik w języku angielskim.

Jest jeszcze jedna rzecz: jeśli reguły Twojej firmy zakładają, że wynikiem twojego kodu nie jest sam produkt, ale kod źródłowy, to na pewno mogą zdecydować, jak będzie wyglądać (wybierając odpowiedni język).

To, co wybiorą, zależy od ich celów: jeśli chcą łatwych do wymiany programistów, wybierają Javę; jeśli wyślą go do innego działu, będzie to wymaganie tego działu itp.

Z mojego doświadczenia wynika, że ​​zawsze zależy to od:

1. Czy mamy zasoby do używania języka?
2. Czy mamy środki na utrzymanie języka?
3. Jeśli nie mamy zasobów do używania i utrzymywania języka, jak trudne / kosztowne jest zdobycie tych zasobów?
4. Jaka jest „przyszłość” tego języka (czy będzie on dostępny i używany przez jakiś czas?)

O ile projekt nie potrzebuje czegoś, co zapewnia tylko określony język / platforma / technologia / framework, sprowadza się do tego, co już znamy i używamy. Zarówno zatrudnianie nowych osób, jak i szkolenie istniejących programistów jest dość kosztowne dla większości firm. Przy zatrudnianiu zawsze bierzemy pod uwagę język i upewniamy się, że kandydaci wiedzą, jakiego języka będą prawdopodobnie używać.

Mamy nadzieję, że masz programistę, który jest także menedżerem i może reprezentować programistów w tego rodzaju decyzjach. Jeśli nie, jest to niebezpieczna sytuacja i powinieneś porozmawiać ze swoim przełożonym, jeśli wiesz, że taka decyzja jest podejmowana.