Zarabiają te 15k, w pracy się nie spocą i co oni wiedzą o życiu… Poszliby do prawdziwej roboty, wstali o czwartej rano, wymrozili łapy, to by dopiero zrozumieli. I jeszcze narzekają. Że Fifa z zeszłego roku, że owocowe czwartki w pandemii nie wjeżdżają pod drzwi home office, że rekruterka pomyliła im imię… Ech.
Ja wiem, ja wiem, że nie mamy prawa narzekać. Kto jak kto, ale nie my, programiści. Jednak narzekanie to nasz sport narodowy. Pękłbym nie narzekając od czasu do czasu. Chcecie bym pękł?
Continuous deployment
O Jezu, jak miało być pięknie! Deploye miały się robić same, zły kod nie wchodzić na produkcję, bo testy automatyczne. A w ogóle to będziemy deployować trzy razy dziennie na produkcję, bo przecież w razie czego naprawimy za 5 minut.
Srali muchy będzie wiosna, trawa po kolana rosła!
Skonfigurowanie continuous deploymentu dla projektu legacy rozwijanego od 10 lat przypomina zadanie pytania na StackOverflow. Niby można. Wydawać by się nawet mogło, że to dobry pomysł. Jednak ilość pułapek, w które możemy wpaść sprawia, że z każdą kolejną godziną wykonywania tej roboty tracimy zapał. Co chwila i coraz szybciej spadają nowe klocki w tej układance, a my nie nadążamy ich układać. Tetris. Wygrał ktoś w to kiedyś?
Testy automatyczne – wspaniałość. Mokry sen inżyniera oprogramowania. Tyle tylko, że jakoś nikomu się ich nie chce pisać, a nawet jak chce to okazuje się, że aby się wszystko trzymało kupy nie wystarczą szybkie testy jednostkowe, ale powolne integracyjne. I wtedy na zakończenie builda czekamy tyle, że i trzy stoliki do piłkarzyków oraz pięć konsol nie rozładuje kolejki.
Deploye na produkcję trzy razy dziennie – to już była obietnica taka, że trochę nie wierzyliśmy od początku. I słusznie. Albowiem jak pisał poeta – nie udało się oddzielić dokładnie kodu od bugu, i wchodził na produkcję z nutką fakapu i commitem błędu. Poza tym proponuję przekonać kogokolwiek w bankowości do wdrożeń co trzy godziny.
Chmura
Będziemy sobie konfigurować infrastrukturę! Oh yes! Po co czekać na to aż admini zrobią nam serwer. Klikniemy trzy razy i… mamy fakturę na 50 tysięcy euro!? Bo Marek zapomniał wyłączyć te instancje, a potem się zwolnił i nikt o nich nie wiedział? Przecież to więcej niż 3 jego pensje. Olaboga.
Albo na przykład chcemy mieć chmurę, ale prywatną, bo mamy wrażliwe dane. Oczywiście deweloperzy będą mogli sobie sami wnioskować o zasoby, ale żeby niektóre z nich utworzyć będzie trzeba złożyć wniosek w ServiceNow z SLA 10 dniowym. Na resztę nałożymy korpo ograniczenia, żeby przypadkiem bitcoinów nie kopali sobie na dev instancjach, więc będzie wszystko działać wolniej niż przed chmurą. Ale elastyczność będzie. Quid pro quo.
Agile
Nie możemy planować przez dwa tygodnie rocznego projektu. W tym czasie biznes może się zmienić, a my musimy stać się zwinni i adaptować. Będziemy dostarczać co dwa tygodnie nowe funkcjonalności. Będziemy codziennie mówić nad czym pracujemy. Będziemy zmotywowanym efektywnym zespołem i będziemy dostarczać wartość biznesową.
Więc mówimy co rano… robiłem to samo co wczoraj i dzisiaj będę kończył, a poza tym to byłem na spotkaniu pół dnia.
Planować przez dwa tygodnie rocznego projektu nie możemy, ale planować przez cztery godziny dwutygodniowy sprint to już jak najbardziej. Po trzech miesiącach okazuje się, że jest reorganizacja i wszystko co zrobiliśmy idzie do piachu, więc zaczynamy od nowa. Oczywiście nadal jesteśmy zmotywowanym i efektywnym zespołem. W końcu co dwa tygodnie robimy demo. Ostatnio pokazaliśmy nowy przycisk na formularzu. Biznes był pod wrażeniem.
Podsumowanie
Oczywiście nie jest tak, że agile, chmura, czy continuous deployment są same w sobie złymi pomysłami. Wręcz przeciwnie, wynikają z historycznych uwarunkowań i rozwiązują dawne problemy. Dziś natomiast, nie pamiętamy już bolączek wczorajszych, za to doskwierają nam dzisiejsze. Przyznam jednak, że martwi mnie dość mocno jak pewne wspaniałe pomysły ulegają wypaczeniu w praktyce. Rozwiązania chmurowe potrafią naprawdę usprawnić pracę programisty, ale ich natura wymaga sporego zakresu swobody, którą często korporacyjne środowisko sprowadza do minimum. Odbiera to czasami sens całej transformacji. Stają się one tylko zmianami sterowanymi modą, trendami. Wszyscy mają chmurę, mam i ja!
Podobnie z Agile. W niektórych, szczególnie mniejszych organizacjach, widywałem ducha zwinności. Myślano tam jak zrobić coś prościej, jak implementować szybko, bez zbędnej komplikacji i narzutu. Natomiast w dużych projektach i firmach było z tym o wiele, wiele gorzej. Dużo więcej za to mówiło się o samej zwinności. Praktyka jednak była od niej dużo dalej.
Continuous deployment to natomiast przesadne oczekiwanie. Sam proces automatycznych wdrożeń, w połączeniu z testami jest niezwykle korzystny, pomaga nie tylko unikać błędów, ale też chroni przed niebezpiecznymi różnicami w środowiskach poszczególnych developerów. Natomiast obiecywanie biznesowi, że będziemy wdrażać na produkcję kilka razy dziennie to już ułańska fantazja, trzeba przyznać. Przynajmniej w większości firm.