W dniu niedziela, 3 lutego 2013 17:07:12 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Pewne uproszczenie oczywiście. Dla mnie normą też jest to, że jest kilka
> innych języków, ale każdy z nich ma swoją niszę. Jeśli jest to powiedzmy
> C++/Python, to np. nie pojawi się temat "czy zamiast Pythona nie lepiej
> byłoby używać Ruby".

Tak. To pozwala ograniczyć ilość języków wartych uwagi do takiego zbioru, który
faktycznie można realnie ogarnąć.

> Ale widzisz, ja uważam, że rozmawianie, refleksja, to sensowne metody.
> Liczenie chekboxów jest bezsensowne.

Ale te rzeczy się nie wykluczają. Zbiór checkboksów (czyli wymagania na nowe
narzędzie) powstaje na skutek refleksji nad stanem obecnym. Samo liczenie checkboksów
to pikuś, ale jakoś trzeba tą listę stworzyć - to jest ta trudniejsza część i na
pewno zajmie najwięcej czasu.

> > I tak np. wyobraź
> > sobie, że są zespoły, które po jakiejś analizie i refleksji decydują
> > się na wprowadzenia agile, scrum, czy co tam jeszcze,
[...]

> Ta analogia jest moim zdaniem nietrafna, ale nawet pomimo tego można
> zauważyć, że właśnie często jest tak, że próby wprowadzenia Agile nie
> dochodzą do skutku lub kończą się źle na wskutek złego zrozumienia na
> czym to polega lub też konfliktu z mentalnością zespołu czy kulturą firmy.\

I dokładnie z takiego samego powodu może się nie udać wprowadzenie nowego języka.

> > Dlaczego taki zespół nie
> > miałby zdecydować się na sięgnięcie po inny język? Nie widzę żadnego
> > powodu.
>
> Ja nie widzę żadnego powodu, dla którego miałby w tym celu liczyć checkboxy.

Checkboksy stanowią odpowiedź na pytanie dlaczego X a nie Y.

> More to the point, raczej nie będzie tak, że w zespole piszącym w Javie
> a nie w Scali ogół programistów wypisze checkboxy tak, żeby Scala
> wygrała.

Zgadza się. I na pewno programista Javy, który patrzy się wyłącznie w swój monitor,
tego problemu konstruktywnie nie rozwiąże. Co więcej, nie zrobi tego też "otwarty"
programista Javy, który jeździ wyłącznie na konferencje Javy, czyta wyłącznie
książki/blogi o Javie, itd. Dlatego w zespole potrzebni są też ludzie, którzy sięgną
dalej. Jeżeli takich ludzi nie ma, to zespół nie ma najmniejszych szans na postęp i w
ogóle cała ta dyskusja takich zespołów nie dotyczy.

> A jeśli nawet programiści znają te rzeczy i rozumieją ich wartość, to
> zazwyczaj będą mieli też zdanie, czy przeważają one zalety Javy czy nie.
> Wychodząc więc z tego, że znają zalety Javy i zalety Scali i mając
> opinię co jest lepsze, mogą sobie bez problemu wybrać checkboxy do
> wpisania tak, żeby wyszło to, co uważają, że powinno wyjść.

Zgadza się. Na pewno ich własne oczekiwania będą jakoś wpływać na ten proces.

> No i jest jeszcze jeden, mniej przyjemny aspekt tej sprawy - dotyczy też
> bardziej ogólnie, nie tylko metody liczenia checkboxów, ale w ogóle
> dania programistom wolnej ręki w wyborze języka programowania. Jest nim
> pewien konflikt interesów między programistą a właścicielem projektu
> (właścicielem firmy, prezesem, szefem działu itd.).

Konflikt wygląda tak:

"Panowie, no weźcie zróbcie coś, żeby tych bugów tyle nie było."

> Pomińmy nawet chęć
> zastosowania nowego języka z niskich pobudek jak wpisanie sobie modnej
> technologii do CV,

Ciekawe, że ta motywacja nie jest sprzeczna z oczekiwaniami właściciela projektu, bo
użycie modnej technologii wpływa pozytywnie na rekrutację.

> czy nieodpowiedzialną chęć pobawienia się nowymi
> gadźetami, w obu przypadkach potencjalnie kosztem projektu.

"Oferujemy możliwość pracy z najnowszymi technologiami."

> Dla właściciela projektu liczy się
> przede wszystkim co innego - rentowność projektu.

Tak. Dobry wybór technologii nie stoi w sprzeczności z tym celem.

> I teraz rozpatrz w świetle tego decyzję o adopcji Scali w projekcie
> javowym. Załóżmy, że zalety języka spowodują, że program będzie miał
> mniej błędów, że nowe ficzery będą szybciej implementowane, że dzięki
> temu klienci będą bardziej zadowoleni i program zarobi więcej. Ale dla
> właściciela projektu efekt adopcji Scali będzie też taki, że nie tylko
> będzie trudniej (i drożej) zatrudnić programistów znających już Scalę,

To ciekawy zbieg okoliczności, ale akurat biorę udział w rekrutacji do takiego
projektu.

"Jeżeli chciałby Pan rozwijać się zawodowo i np. nauczyć się czegoś poza głównym
nurtem, który podkreślił Pan w swoim CV, to również tego typu możliwości można w
naszej firmie znaleźć. Np. mamy miejsce na projekty tworzone przy użyciu Scali."

To był mniej lub bardziej dosłowny cytat. Musiałbyś widzieć, jak się wtedy kandydatom
oczy świecą z radości. A przynajmniej jeszcze nie widziałem, żeby ktoś wtedy wyszedł.

Tak więc nie przyjmuję argumentu, że jest to wbrew oczekiwaniom pracodawcy. Wydaje
się, że przy odpowiedniej organizacji można stworzyć układ, w którym wszystkim będzie
po drodze.

> Dlatego też nie jest w ogóle oczywiste, czy dla właściciela
> w ogóle dobrym posunięciem jest pozostawienie tej decyzji wyłącznie w
> gestii programistów.

"No chyba powinniście wiedzieć, co zrobić, żeby było dobrze."

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com