Dług technologiczny–zmiana wersji

W poprzednim artykule jako jeden z pierwszych składników długu technologicznego podałem wersję narzędzi. Dzisiaj będzie trochę szerzej o tym.

Używanie starych narzędzi ma kilka dosyć poważnch skutków.

Odcinanie się od lepszych narzędzi

Pierwszy to odcinanie się od nowych zabawek, które pozwoliły by tworzyć lepsze produkty. Korzystając z .net 1.1 nie było wsparcia dla typów generycznych dzięki czemu zamiast stworzyć typ generyczny trzeba było czasem nawet pokopiować trochę kodu. Zamiast skorzystać z typów nullable trzeba było je samemu robić, a pisanie delegatów w 1.1 to był lekki koszmar. .net 3.0 przyniósł między innymi WCF który dosyć mocno ułatwił pisanie usług – wcześniej mieliśmy remoting marsharbyref i inne super szybkie wynalazki. Póżniej doszły lambdy i linq i znowu zamiast zgrabnie obsłużyć kolekcję za pomocą 1 czy 2 lambd w starych wersach trzeba było robić to na piechotę za pomocą pętli. Wystarczy sprawdzić ile zajmuje czasu wymyślenie i napisanie takiego samego kodu z i bez lambd. W skali projektu, takie drobne oszczędności potrafią zsumować się do całkiem sporych wartości.

Ślepa uliczka

To jest bardzo poważna sprawa, wyobraź sobie sytuację, że np. .net 1.1 nie działa na Windows 8, albo kontrolki, których używasz a których nie aktualizujesz od 5 lat nie działają z nowym Windowsem. Wyobraź sobie, że nie działają w aplikacji 64bitowej a następna wersja Windows będzie tylko 64 bitowa (nie wiem czy będzie, ale kiedyś nastąpi taki czas, że Microsoft zrezygnuje z wersji 32, z wersji 16bitowych już dawno zrezygnowali). Jeżeli zmieniamy wersje na bieżąco, taka sytuacja nie powinna się zdarzyć, jeśli ociągamy się z aktualizacjami, wówczas prędzej czy później możemy obudzić się z ręką w nocniku. Najgorsze w tej sytuacji jest fakt, że czasem zmiana wersji kontrolek, jakiejś biblioteki czy frameworka nie jest trywialna. I co w takiej sytuacji? Kiedy znajdziemy więcej pomocy na temat migracji .net 1.1 do 2.0 (i aktualizacji sln) wtedy kiedy większość przechodzi i ma te problemy na świeżo czy 10 lat później? To jest tak jak z psującym się zębem. Na początku wystarczy krótka wizyta u dentysty ale nie leczony spowoduje, że skończymy na ciągnącym się leczeniu kanałowym. Zwlekanie tutaj może mieć ogromnie bolesne konsekwencje.

Odpływ ludzi

Jak w każdym zawodzie tak i w programowaniu są dwie grupy ludzi, pasjonaci i hobbyści, ludzie, którzy chcą coś więcej z życia i dają coś w  zamian oraz ludzie wyrobnicy – przyszedłem do roboty, odsiedzę/odstoję/odbębnię swoje i do domu, zero własnego zaangażowania, zero czegokolwiek od siebie. Typ dojnych, krów – jak nie pociągniesz to mleka nie będzie. Jeżeli nasz projekt będzie babrał się w starych technologiach to jest duże ryzyko, że odpłyną ludzie – ci pierwsi. Oni zazwyczaj chcą robić w najnowszych najlepszych najfajniejszych rzeczach. Jeśli projekt nie jest kul to jest ryzyko, że pójdą szukać swojego Mojo w innym miejscu. Projekt zaś? no cóż, projekt zostanie z samymi wyrobnikami – powodzenia PM-ie

Kiedy zmieniać wersję?

Nie wiem. Ja lubię zmienić możliwie szybko, nawet jeśli będzie to beta. Jednak wydaje mi się, że normalne osoby powinny zmieniać gdzieś w połowie okresu wydawniczego. To powinno pozwolić internetom na skumulowanie odpowiedniej ilości wiedzy na temat możliwych problemów. Zapewni nam w miarę nowoczesne narzędzia a jednocześnie nie będziemy spędzać nad tym zbyt wiele czasu (który bety lubią pochłonąć)

Chyba tyle w kwestii używania starych narzędzi, następnym razem na warsztat weźmiemy drogi na skróty w programowaniu.