Stack technologiczny - czy warto ograniczać?
Wybór technologii w projekcie ma ogromne znaczenie, o czym raczej nikogo nie trzeba przekonywać. Zapewne nie raz zetknęliście się z sytuacją, kiedy zobaczyliście jakieś rozwiązanie/system i po chwili stwierdziliście, że użylibyście do tego zupełnie innych bibliotek, podeszlibyście do tematu od innej strony albo zrobilibyście to w innym języku programowania.
Nie jest to nic niezwykłego, a powiedziałbym wręcz, że to jeden z większych atutów naszego zawodu. Każdy problem możemy rozwiązać na wiele sposobów, przy użyciu wielu narzędzi i w większości sytuacji osiągniemy nasz cel w unikatowy sposób.
Przez 10 lat pracy w projektach zarówno nowych, jak i różnych kontynuacjach, zauważyłem, że temat doboru technologii, w jakiej realizujemy powierzone nam zadania, sprowadza się bardzo często do dwóch opcji:
- całkowita dowolność w doborze technologii leży po stronie programistów
- istnieje spore ograniczenie stacku technologicznego przez kogoś/coś
Ograniczenia i limity…
Chciałbym się dziś skupić na tych podejściach. Stosowanie ograniczonego zestawu narzędzi, wbrew pierwszemu wrażeniu, może być pożyteczne zarówno dla programistów, jak i managementu. Pierwszą rzeczą, jaka przychodzi mi do głowy, jest łatwiejsze pozyskiwanie nowych osób do zespołu. Rekrutacja zewnętrzna przy popularnych językach i frameworkach jest łatwiejsza z uwagi na sporo większą liczbę potencjalnych kandydatów. Danie programistom wolnej ręki w doborze technologii często kończy się zastosowaniem ciekawych, ale też niszowych rozwiązań. Znalezienie wykwalifikowanych i doświadczonych ludzi na rynku jest wówczas dużo bardziej problematyczne i kosztowne.
Poza rekrutacją zewnętrzną w dużych firmach bardzo często następuje migracja osób między projektami/zespołami. Dzięki ograniczonemu odgórnie stackowi wspólnemu dla wszystkich projektów, pracownicy mają możliwość wdrażania się w dowolny projekt, poznając tylko domenę danego systemu oraz specyficzne dla tej domeny narzędzia, bez konieczności uczenia się nowych języków czy też olbrzymiej ilości nowych bibliotek. Spora część narzędzi będzie się prawdopodobnie pokrywała. Pozwala to również na dynamiczne wspieranie zespołów w razie potrzeby poprzez szybką delegację osób do innych projektów na krytyczny okres.
Należy także pamiętać, że wybór architektury i technologii ma wpływ nie tylko na developerów. Bardzo istotne są zespoły wspierające i wdrażające rozwiązanie na środowiskach produkcyjnych czy testowych. Admini i DevOpsi w takiej sytuacji są w stanie lepiej wypełniać swoje obowiązki, gdyż mają mniej zmiennych w swojej pracy. Dużo prościej jest utrzymać pięć systemów np. w Javie niż po jednym w Javie, .Necie, PHP, Go i Ruscie, kiedy każdy z nich wymaga często zupełnie innych kompetencji, doświadczenia czy nawet znajomości platformy, na jakiej jest uruchamiany.
Przekłada się to na prostsze i szybsze wdrożenia, integracje i analizy incydentów. Nie można również pominąć faktu, że niszowe rozwiązania dla takich zespołów często są bardzo problematyczne. O ile czasem programiście wystarczy poznać podstawy działania danej technologii albo skorzystać z gotowego rozwiązania na StackOverflow, to zespół wsparcia musi umieć sobie z nią poradzić w warunkach bojowych. Analiza problemu w technologii, której zbyt dobrze się nie zna, jest dla nich często sporym wyzwaniem...
Sami deweloperzy również zyskają sporo benefitów przy odpowiednim ograniczeniu stacku. Dużo prostsze jest poszukiwanie wiedzy i rozwiązań problemów w popularnych technologiach niż w przestarzałych lub niszowych. I tutaj warto zwrócić uwagę na fakt, że ograniczony stack nie oznacza stagnacji na 10 lat. Języki i frameworki rozwijają się lub są zastępowane przez nowsze i sprawniejsze. Dlatego też standard w organizacji również powinien żyć swoim tempem, ale też dostosowywać się do potrzeb w danym środowisku.
Standard taki powinien spójnie opisywać reguły tworzenia, weryfikacji i wdrażania rozwiązań, a w razie czego, powinien być też otwarty na ich rozwój i modyfikacje. W innym wypadku zaprowadzi nas to na drogę ku ciemnym wiekom. Tam, gdzie po 10 latach rozwoju produktu okazuje się, że technologia, w której działamy, ma już 6 nowych wersji i jej podwaliny są już tak przestarzałe, że nikt nie chce z nią pracować.
Rozwój standardów powinien iść w parze z rozwojem kompetencji ludzi. Dużo łatwiej to osiągnąć, kiedy możemy wdrażać spójne ścieżki rozwoju, czy też warsztaty dla większej ilości osób. Pracownicy również sami mogą łatwiej wymieniać się wiedzą i wzajemnie ją weryfikować, jeśli oscylują wokół tej samej grupy tematycznej. W sytuacji, kiedy większość osób rozwija się w okolicach tej samej technologii, z czasem może to owocować zbudowaniem społeczności, która może przerodzić się w prężnie działające centrum kompetencyjne na potrzeby wewnętrzne i nie tylko.
… nie interesują mnie
Każdy kij ma dwa końce i każda decyzja, która coś narzuca, ogranicza nam pole manewru.
W branży IT bardzo często mamy do czynienia z technologiami stworzonymi w konkretnym celu, którego do jego realizacji sprawdzą się najlepiej. Mimo iż istnieją rozwiązania generyczne, to często zastosowanie konkretnego narzędzia do określonego problemu jest dużo lepszą opcją, mimo iż wdrożenie go będzie nas kosztowało czas i pieniądze.
W przeciwnym wypadku, aby osiągnąć ten sam lub zbliżony cel (o ile to możliwe), jesteśmy zmuszeni wyrzeźbić tony kodów, które znacząco mogą komplikować złożoność naszego systemu i odbić się w przyszłości w sposób, którego dziś nie jesteśmy w stanie przewidzieć.
W efekcie może się okazać, że wymyślamy koło na nowo, mimo świadomości, iż tuż obok leży fajna technologia, która rozwiązuje nasz problem z pudełka, ale wymaga np. zastosowania innego języka programowania, który nie jest akceptowalny przez nasze standardy organizacyjne.
Kolejnym istotnym efektem ograniczenia stacku, o którym powinniśmy pamiętać, jest ograniczenie rozwoju kompetencji pracowników. Zamknięcie ich na konkretne technologie w pracy znacząco ogranicza ich rozwój i świadomość rozwiązań, które mogłyby wpasowywać się w aktualne lub przyszłe projekty. Stoi to poniekąd w opozycji do mojej tezy sprzed chwili o budowaniu kompetencji wertykalnych, ale czy na pewno?
Ograniczenie stacku skutkuje również budowaniem długu technologicznego. Utrudnianie lub - co gorsza - brak możliwości wdrażania nowych rozwiązań skutkuje pozostaniem w tyle w sferze technologii. Co za tym idzie? Po kilku latach takiej stagnacji technologicznej trzeba robić duże przebudowy systemów, aby były one zgodne z aktualnymi standardami rynkowymi lub rosnącymi wymogami klienta.
A gdzie dwóch się bije…
Z powyższych rozważań można tak naprawdę wysunąć trzy sytuacje:
- Pełna dowolność rozwiązań w rękach programistów, gdzie mamy najczęściej bardzo zadowolony zespół, wiele nowoczesnych rozwiązań, olbrzymią bazę technologii w portfolio i sporo wyzwań w zarządzaniu tym wszystkim
- Sztywne reguły narzucone z góry, powodujące frustrację wśród programistów, trudności w długofalowym działaniu i opinię technologicznego mamuta
- Hybrydę bazującą np. na rekomendacjach technologicznych i odpowiedzialności za podejmowane decyzje przez zespoły, pozwalające na stosowaniu rozwiązań skrojonych na miarę problemu po uprzedniej analizie i dostosowaniu do aktualnych standardów w organizacji.
… tam trzeci korzysta
Krocząc w kierunku skrajności, jesteśmy w stanie doprowadzić do sytuacji, które prędzej czy później mogą okazać się zgubne dla naszej działalności, powodując liczne negatywne konsekwencje związane z jakością naszych systemów lub też bezpośrednio z ludźmi.
Jak wszędzie, najważniejszy jest umiar, który pozwala nam zaspokoić najważniejsze potrzeby, nie tworząc nagle wielkiego chaosu i pozwalający na panowanie nad sytuacją. Dając ludziom wybór, ale też odpowiedzialność za decyzje, pozwalamy dojrzewać im oraz produktom, które tworzą, a w efekcie naszym biznesom.