W dniu piątek, 1 lutego 2013 22:59:00 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Ja z kolei nie bardzo widzę ww praktyce sytuację, kiedy oragnizacja, w
> której pisze się w np. C++ i w której wszyscy znają C++

Ja też nie bardzo widzę, bo nigdy nie widziałem takiego zespołu ani takiej
organizacji (pomijam firmy typu "Java Systems Sp. z o.o."). Zwykle jest w zespole
kilka równoległych kierunków tematycznych, może też kilka równoczesnych projektów w
różnych fazach. Zwykle też ludzie dzielą się na tych z wiekszym stażem (często jest
to staż z zewnątrz, bo w naszej branży jest spora rotacja) i na tych z mniejszym (oni
*i tak* wymagają szkolenia), co też wprowadza różne możliwości rozwoju takich
zespołów.
W firmie, w której teraz pracuję, letko naliczyłem właśnie na palcach 10
*równocześnie* używanych języków programowania. A naciągając fakty będzie 12.
W takim zespole można już porozmawiać o porównaniach, refleksji nt. walorów różnych
rozwiązań, optymalizacji dalszego kierunku, itd. Nie widzę problemu.

> nagle po
> wielokryteriowej analizie dochodzi do wniosku, że następny system klassy
> safety-critical będzie tworzony w, powiedzmy, Adzie.

Jeżeli była jakaś analiza i to jeszcze wielokryteriowa, to na pewno nie "nagle".
Obstawiam raczej długotrwały proces refleksji i poszukiwania właściwych torów.

To jest coś jak z wprowadzaniem nowej metodologii prowadzenia projektu. Cała nasza
dotychczasowa dyskusja jest w mocy po zamianie słowa "język" na "metoda prowadzenia
projektu". 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, chociaż
wcześniej nikt tego nie znał. A jednak robią to, z zapałem przewalając całą firmę do
góry nogami (czasem dosłownie). I uwaga, bywa nawet, że robią w ten sposób postęp.
Dlaczego taki zespół nie miałby zdecydować się na sięgnięcie po inny język? Nie widzę
żadnego powodu.

> To, że nie będą kończyć ci sami ma mniejszą wagę, niż sądzisz. Przecież
> nigdy nie będzie takiej sytuacji, że wymienią na raz cały zespół, a
> tymczasem jeśli zaczniesz od tego, że robisz w technologii X, to
> będziesz dokooptowywać głównie ludzi, którzy znają technologię X, lub
> np. poznają ją stopniowo pracując w twojej organizacji na innych
> stanowiskach.

Tak. Ciągłość techniczna to bardzo ważny argument. Dlatego możliwość łączenia języków
jest tu istotna - np. to, że Scala potrafi wykorzystać istniejące klasy w Javie. Itp.
To pozwala robić zmiany jednocześnie zachowując ciągłość.

> Metoda "wszystko robimy w C++ więc to też zrobimy w C++" przynajmniej
> jest dużo mniej pracochłonna.

Ale jak już pisałem nie widziałem takiego zespołu.
Oczywiście nie twierdzę, że takich nie ma.

> > Zawsze myślałem, że wykształcony programista też jest zdolny do jakiejś tam
> > intelektualnej mobilności.
>
> Nie aż takiej, żeby dowolną nową umiejętność opanować w kwadrans.

Proces optymalizacji procesu technologicznego jest z założenia długotrwały. Agile też
nie da się wprowadzić w kwadrans a jednak są zespoły, które się na to decydują. I
bywa nawet, że robią w ten sposób postęp.

Nie widzę problemu.

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