Jak korporacje dobierają narzędzia

Ten post jest próbą wyrzucenia z siebie drzemiącej głęboko frustracji dotyczącej fatalnego podejścia do doboru narzędzi, w korporacjach, z którymi się zetknąłem.

Trawestując znanego survival-owca oraz Naczelnika Skautów Wielkiej Brytanii "Narzędzia są po to aby wykonywały pracę za Ciebie - nie na odwrót.". Choć zdanie to dotyczyło konserwacji i ostrzenia piły, noża czy siekierki, to pasuje również do naszej, jakże przepełnionej narzędziami, informatycznej rzeczywistości.

Rozpoczynając pracę musisz wybrać narzędzia. Jednak samo ich posiadanie nie rozwiązuje problemu - musi nastąpić etap selekcji. Selekcji, która w dużych firmach podejmowana jest raz i nieodwołalnie, często kilka, anawet kilkanaście lat przed rozpoczęciem projektu, któremu przyjdzie z nich korzystać.

Innymi słowy, narzędzia wybierane są globalnie w skali całej firmy i w tej samej firmie ich używanie jest egzekwowane bez względu na charakter i rodzaj przedsięwzięcia. Zdarza się iż używany jest system kontroli wersji, którego początki pamiętają roku 1992, którego założenia koncepcyjne są na tle nowoczesnych systemów kontroli wersji z gruntu złe. Ogromna ilość pieniędzy, stworzona infrastruktura, ilość znanych rozwiązań problemów oraz doświadczenie tworzą pozorną wartość przekładającą się na równie pozorną łatwość w użyciu tak dobrze "sprawdzonego" i "sprawdzającego się" narzędzia w kolejnym projekcie.

Jednak wszystko to jest iluzoryczne. Przyzwyczajenia ludzi nie świadczą o jakości narzędzia, ani o sprawności jego używania gdyż nawet większa nieudolność, w wykorzystywaniu nowego oprogramowania na początku, może być błyskawicznie zniwelowana sumą zwiększonej prędkości jego działania oraz dobrze przygotowanym programem szkoleń dla osób początkujących, posuniętego nawet do algorytmów postępowania.

Równie fałszywe jest wrażenie "problemów, z którymi przyjdzie nam się zmierzyć". Często zakładamy, że skoro oprogramowanie zaproponowane przez firmę sprawiło nam wiele kłopotów, to wraz z wprowadzeniem nowego narzędzia pojawią się nowe. Nikt jednak, bardzo często, nie zauważa, że znaczna część tych problemów wynika z wieku narzędzia i architektury oraz koncepcji, które bardzo często nie przystawały do współczesnych realiów. Realiów, w których zostało stworzone nowe narzędzie, dzięki któremu będziemy mogli zminimalizować portfolio "dobrze znanych rozwiązań, dobrze znanych problemów" nawet o 90%.

W epoce kamienia łupanego ludzie do krojenia używali ostrych kamieni. Używali ich ponieważ sprawdzały się, a w pobliżu nie było nic bardziej dostosowanego do krojenia. Dzisiaj jednak używamy noży, toporów, siekier, pił i scyzoryków. Używamy ich na drodze prostej ewolucji, w której narzędzia mniej przydatne przestawały być używane, odchodziły w niepamięć, a zastępowały je lepsze, bardziej użyteczne odpowiedniki. O tym czy narzędzie i jego wykorzystywanie przetrwało do naszych czasów czy nie decydowała jego efektywność.

Kiedy się temu przyjrzymy, wydaje się to rzeczą naturalną. Można wręcz powiedzieć iż stwierdzenie przybliżone w poprzednim akapicie trąci truizmem. Truizm ten nie jest niestety oczywisty w korporacjach, w których w kółko i na okrągło wykorzystuje się stare, zakupione dekadę, albo dwie temu programy. Pomimo dziesiątek problemów i dawno stwierdzonych wad są używane w kolejnych projektach.

Jednak nie tylko wykorzystywanie archaicznych rozwiązań, na dużą skalę, może być błędem. Git to niewątpliwie fantastyczny system kontroli wersji. Pomyli się jednak ten, kto użyje go do projektu Visual Studio 2010, w środowisku opartym o kontroler domeny Windows. Wystarczy bowiem przyjrzeć się Mercurialowi aby dostrzec zalety w formie: natywnego wsparcia dla okienek, świetnej integracji z Visual Studio 2010 dzięki wtyczce VisualHG (znacznie lepszej niż jakakolwiek integracja Gita z Visualem), czy wsparcia dla Single Sign On w postaci HGKerberos, która działa z SPNEGO.

Na tym przykładzie widać, że narzędzia można dobrać lepiej lub gorzej, albo po prostu źle. Moim zdaniem idealnym rozwiązaniem jest tworzenie architektury "per-projekt", w których używane narzędzia będą symbolem "epoki", w której projekt startował. Doskonale rozumiałbym używanie tak archaicznego systemu kontroli wersji jak CVS w projekcie z lat 90siątych, tak jak używanie Subversion w narzędziu, którego początki są datowane na 2000 rok. Konsekwentnie, dobierając nowoczesne rozwiązania do projektów, które powstały na przestrzeni kilku ostatnich lat.