On 04/02/2013 09:40, Maciej Sobczak wrote:
> 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ąć.

Pytanie nie jaki zbiór można ogarnąć, tylko jakim kosztem. Każdy
dodatkowy język wiąże się z dodatkowymi kosztami.

>> 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.

Co jednak, jeśli z refleksji wychodzi co innego niż z liczenia
checkboksów? Bo widzisz, w praktyce zawsze tworzący listę będzie też
uważał, że niektóre checkboksy są ważniejsze od innych. Można oczywiście
bawić się w jakieś przypisanie wag, ale biorąc pod uwagę, że konkretne
liczby zawsze będą arbitalne, to nie lepiej jednak po prostu stwierdzić,
czy się uważa, czy zalety po prawej stornie tableki przeważają nad
wadami po lewej stronie tabelki?

>> 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.

I dokładnie to jest to, czego liczenie checkboksów ci nie powie.

>> 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.

W praktyce w skali zespołu zawsze będziesz miał ograniczenie polegające
na tym, że rekrutowani byli ludzie z określonymi umiejętnościami. Nie ma
co liczyć na to, żeby w zespole posługującym się Javą wszyscy czy
większość rozumiała jak te rzeczy, które są w Scali praktycznie wpłyną
na pisanie programów. No chyba że rekrutujesz ich specjalnie pod tym
kątem, ale wtedy ktoś kiedyś musiał zadecydować, że takie a nie inne
umiejętności będą wymagane.

[...]
>> 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.

Na tyle, że cała metoda jest bezsensowna.

>> 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."

U was w firmie programiści chcą, żeby bugi były?

>> 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ę.
[...]
> "Oferujemy możliwość pracy z najnowszymi technologiami."

Być może, ale to przecież nie znaczy, że każdy dobór najnowszej czy
dobrej technologii ma sens w każdym projekcie. Tak więc teoretycznie
może zaistnieć sytuacja, kiedy programista, któremu pozostawiono w tej
kwestii wolną rękę, dobiera niewłaściwą technologię nie dlatego, że
wydaje mu się naprawdę lepsza do danego projektu, tylko dlatego, że
wydaje mu się osobiście ciekawsza. Na przykład wybiera bazę danych NoSQL
tam, gdzie SQL byłaby lepsza, bo NoSQL jest sexy i na topie.

Ale, jak mówiłem, mój argument nawet nie dotyczy takiej sytuacji.

>> 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.

Zależy jak rozumie się "dobry". Jeśli taki, który zwiększy produktywność
i niezawodność, to może jednak tak być: jeśli wykorzystanie danej
technologii spowoduje, że miesięczne przychody z programu zwiększą się o
X, a koszty produkcji zwiększą się o Y, to opłacalność tego zależy od
tego, czy X jest większe od Y (upraszczając, ale mniejsza o to). Nie
jest oczywiste, że X będzie zawsze większe od Y, a w dodatku problem
jest długofalowy - początkowo bilans może być dodatni, bo programiści
nie dostaną podwyżek i premii natychmiast po wprowadzeniu Scali, ale w
perspektywie iluś lat trzeba im dać wyższe podwyżki i zapłacić wyższe
koszta rotacji.

Żeby nie było - ja też uważam, że zwykle czy nawet prawie zawsze
bardziej opłaca się zatrudnić dobrych programistów i płacić im
odpowiednią kupę szmalcu, ale też nie mam żadnych rzeczowych dowodów na
to, że X będzie większe od Y, tylko swoją intuicję, a sam przecież nie
jestem bezstronny.

> "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ł.

Oj, nie twierdzę przecież, że problem (metaforycznej) Scali jest taki,
że kandydaci nie będą chętni. Problem jest taki, że:
* Kandydaci owszem, chętnie się nauczą Scali, ale póki co jej nie
znają. Zanim się zapoznają minie ileś tam czasu, w którym to czasie będą
mniej produktywni.
* Jeśli chcesz zatrudnić kandydatów już znających Scalę, to możesz
długo szukać. Jeśli nie chcesz długoo szukać, to musisz wystawić bardzo
atrakcyjną ofertę.
* Jeśli dajmy na to nie wymagasz znajomości Scali, ale w celu
skrócenia czasu nauki i zapewnienia dobrego wykorzystania zalet języka
szukasz ludzi, którzy wiedzą coś np. o programowaniu funkcyjnym. To też
utrudnia ci znalezienie kandydata i powoduje konieczność wystawienia
lepszej oferty (niż gdybyś tego nie wymagał) w celu pryciągnięcia
odpowiednich ludzi.
* Jeśli zdecydujesz się zatrudnić ludzi, którzy nie znają ani Scali,
ani odpowiednich technik, to ryzykujesz, że się ich nie będą w stanie
nauczyć. Dasz im, powiedzmy, pół roku okresu próbnego, to musisz się
liczyć, że po pół roku jakiś tam procent nie będzie rokował nadziei i
trzeba będzie szukać kolejnych - koszty. Zaostrzając kryteria
rekrutacji, nawet nie konkretnie w tę stronę, ale nawet w celu
zatrudnienia po prostu najbardziej kumatych, obniżysz ten procent, ale
podwyższysz koszty wyjściowe - będziesz musiał dłużej szukać albo
zaoferować lepsze wynagrodzenie.

Możesz powiedzieć, że tak czy inaczej starasz się zatrudnić tych
kumatych, ale wszystko jest kwestią skali (no pun intended). Zawsze
możesz starać się zatrudnić jeszcze bardziej kumatych, a jeśli ogłosisz,
że płacisz 30 tysięcy na rękę, to na pewno wielu kumatych przyjdzie do
ciebie na rozmowę. Ale to nie znaczy, że twój szef się zgodzi, że warto
zapłacić te 30 tysięcy, i nie znaczy, że nie będzie miał w tym racji.

> 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.

Nie wszystko, co można jest dobre dla "bottom line".

>> 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."

Niekiedy jest tak, że między programistą a pointy haired bossem niekiedy
jest jeden lub więcej szczebli menedżerów technicznych, którzy mają na
tyle pojęcia o technologii, żeby móc podejmować takie decyzje, ale
którzy z drugiej strony nie mają motywacji, że dzięki użyciu Scali będą
mieli większe podwyżki i mniejszą szansę na zwolnienie. Wręcz przeciwnie
- im większe firma będzie musiała dawać podwyżki ich podwładnym, i im
trudniej będzie im zastąpić, tym mniejsze (ceteris paribus) będą ich
własne podwyżki i premie i tym większa szansa na, jeśli nie utratę
pracy, to przynajmniej utratę stanowiska kierowniczego.