Bajkę o programującym durniu zacząłem od marzeń o cudownej zmianie. Dziś kilka słów o zmiany unikaniu.

Odłożona kosa

W starszej literaturze i filmie nieraz pojawiał się motyw człowieka pożartego przez postęp. Jakiś mistrz kosy, potrafiący ściąć trzy łany zboża w czasie, w którym inni przechodzą jeden, pracowity, sumienny, ćwiczący się do perfekcji, zdobywający szacunek i solidne utrzymanie. I moment, gdy we wsi pojawia się kombajn. Wspaniale sprawna szwaczka i maszyna do szycia. Wrażliwy, mądry hodowca koni i motoryzacja. Księgowy o bajecznej pamięci i komputer. Sklepikarz i supermarket.

Wątek ma spory potencjał. Napięcie między sympatycznym człowiekiem a zdehumanizowaną techniką, często też między konkretną osobą a bezwzględną korporacją. Nuta romantycznego żalu za tym co odchodzi, od rozbłysku słońca na ostrzu kosy po dom zamieszkiwany od ośmiu pokoleń. Wysiłek, dylematy, nadzieja. Tragiczna beznadziejna szarpanina albo jakiś cudownie wykreowany happy-end.

Zmiana kosy na kombajn to rzeczywistość pokolenia moich dziadków. Dziś podobny moment przeżywają lub niedługo przeżyją dziennikarze, fotografowie, tradycyjni urzędnicy biegli w obsłudze papierowych dokumentów, drobni sklepikarze i rzemieślnicy, nawet tłumacze czy maklerzy…

Zmiana w informatyce

Trudno powiedzieć, czy w ogóle mieliśmy w informatyce nadejście kombajnu. Było kilka znacznych przełomów technologicznych (masowe pecety, GUI, internet, tanie serwery, smartfony/tablety) pojawiały się bardzo ważne narzędzia (relacyjne bazy danych, kilka ważnych języków programowania, kilka podejść architektonicznych) ale ciężko byłoby wskazać moment, który całkowicie zamiótł i wyrzucił znaczną grupę ludzi lub totalnie wywrócił sposób pracy. Przeciwnie, stałą praktyką jest i było adaptowanie w nowych warunkach wiedzy, narzędzi, umiejętności z poprzedniego etapu.

Częste wydaje mi się natomiast inne zjawisko.

Rok X. Uczymy się jakiejś nowej technologii, albo może sami coś nowego i świeżego tworzymy. Trafiamy. Włożony wysiłek daje nam przewagę nad konkurencją, jesteśmy w stanie działać szybciej i skuteczniej albo wręcz robić rzeczy, których inni zrobić nie są w stanie.

Może tu chodzić o technologię sensu stricte - język programowania, bazę danych, system operacyjny, pakiet algorytmów, framework… - ale może też o proces organizacyjny - sposób zarządzania projektem, metodykę gromadzenia i testowania wymagań, formę komunikacji z klientami. Od bycia wczesnym Python-shopem w pejzażu wszechobecnego PHP po prowadzenie prawdziwych testów używalności, gdy inni nawet nie znają tego pojęcia. Od opracowania narzędzi do rozpoznawania języka naturalnego po wypracowaną umiejętność wiarygodnego szacowania kosztu projektów. Od wirtualizacji systemów po Scrum. Od Big Data po sprzedawanie subskrybcji zamiast upgrade.

Rok X+3. Pełną garścią eksploatujemy sukces. Łapiemy więcej klientów i nowe projekty. Szkolimy więcej ludzi. Czujemy zdrową dumę, czasem demonstrowaną tylko wewnętrznie a czasem też publicznie. Zarazem - przewaga już nie jest taka duża, konkurencja też coś zrobiła albo pojawił się ktoś nowy.

Rok X+6. Działamy jak działaliśmy ale nie jest to już nic niezwykłego, ot - norma. Obserwujący wyciekającą przewagę management wprowadza zasady poufności, kontrolę dostępu do wiedzy, restrykcyjne umowy anty-konkurencyjne itd itp.

Rok X+8. Nasze podejście trąci myszką, raczej o nim nie mówimy, da się wyczuć pewne zażenowanie. Management coraz bardziej narzeka na wydajność, jakość i koszty. Kiepsko wychodzi przyciąganie nowych ludzi, wartościowi wolą robić co innego, zresztą - jesteśmy na tyle sztywni i/lub zamknięci, ze ktokolwiek się pojawi, nie ma możliwości ruchu.

Rok X+10. Niegdysiejsza nowość jest teraz kulą u nogi, spowalnia nas, wstydzimy się jej, nie chcemy. Indywidualne osoby szukają okazji do ucieczki z projektów, nowi bronią się rękami i nogami. Management ciągle ma poczucie, że posiada jakąś wielką wartość ale sytuacja nabrzmiewa do ostatecznego rozwiązania.

Ten cykl oczywiście nie musi być dziesięcioletni. Może być drastycznie krótszy (javascriptowy framework potrafi go zawinąć w rok), może być dłuższy (baza danych Oracle w 20 lat jeszcze go nie zamknęła).

Co ważne: najczęściej nie ma tu żadnych wyraźnych punktów przełomowych. Jest powolny, niedostrzegalny z bliska, proces.

Spalić i zaorać

W dyskusjach o tym zjawisku łatwo można napotkać dwie skrajne postawy.

Jedną jest próba zaprzeczania mu lub ignorowania go, w podtekście mająca obawę przed zmianą. Prowadzi wprost do przejścia całego cyklu do samego końca … i trochę dalej.

Drugą jest żądanie gwałtownych i natychmiastowych działań. Skasować, usunąć, wyłączyć i natychmiast ale to natychmiast zacząć robić wszystko zupełnie inaczej, biorąc byle co, byle było nowe.

Trochę mi to przypomina prowadzone co dwa-cztery lata dyskusje o reformie polskiego futbolu, w myśl których należałoby zlikwidować PZPN, rozwiązać wszystkie kluby, zaorać boiska, zakazać pracy wszelkim trenerom i sędziom a potem … no, potem na pewno jakoś tam będzie.

To że wartość sprzed lat podlega znacznej inflacji nie oznacza jeszcze, że każda nowość jest więcej warta.

W indywidualnym wymiarze

Rok X. Jasiek odsuwa krzesełko, siada przy biurku i implementuje niebanalny raport używając świeżo wdrożonej bazy danych. Robi przy tym parę błędów, ma sporo problemów i wątpliwości ale ogólnie praca ma ekscytujący posmak.

Rok X+10. Jasiek ciężko opada na krzesełko i kleci swój 1847-y raport podobnego typu. Sprawnie i bez błędów, powtarzalność daje perfekcję, jest też z czego kopiować. Jest jednak na tyle znużony, że ciężko mu się zabrać do pracy i odchodzi od niej pod byle pretekstem, więc jego ogólna wydajność jest zbliżona do tej z roku X. A konkurencja dawno już nie robi żadnych raportów, dostarcza możliwość żywej, interaktywnej analizy danych.

Ten obrazek jest dla całkiem wielu osób ... kuszący. Dla kierujących pracą - ze względu na doskonałą przewidywalność, stabilność a też możliwość perfekcyjnego wyszkolenia Jaśka nawet jeśli jest on tytułowym programującym durniem. Dla Jaśków - bo pozwala być leniwym, ujmuje stresu, nie dostarcza problemów, nie boli.

Ból przyjdzie później. Dla firmy - gdy odkryje, że nie jest konkurencyjna. Dla Jaśka - gdy okaże się niepotrzebny.

By postawić to w dobrej perspektywie: nasz Jasiek nie musi być durniem a jego zadanie prostą głupotą. Może faktycznie pisze te raporty ... i umie wycisnąć absolutnie ostatnie poty z perfekcyjnie znanej bazy danych (tylko niestety zamknął się na wiedzę, że inne narzędzia potrafiłyby zaprezentować te same dane znacznie ciekawiej). Może jest biegłym i skutecznym administratorem potrafiącym skonfigurować maszynę od zera w parę godzin bez jakichkolwiek pomyłek czy przeoczeń (ale ignorującym cały świat automatycznych deploymentów). Może bardzo biegle programuje w C (ale nie wie, że zamiast programować przez miesiąc, mógłby bieżący problem rozwiązać w dwa dni składając webappkę z gotowych komponentów jakiegoś Django i paru usług sieciowych). Może umie napisać wydajny parser nietrywialnego języka (i ignoruje istnienie wielu gotowych języków skryptowych, które mógłby wykorzystać, zamiast tworzyć własny).

Problemem nie jest też, że Jasiek korzysta z umiejętności sprzed lat. Jeśli dla danego zadania jest ona odpowiednia - czemu nie? Bagnistą łąkę pod lasem ciągle najlepiej jest kosić kosą.

Źle jest, gdy Jaśkowi nie rośnie arsenał środków. A zwłaszcza, gdy nie rośnie on firmie.

Przykładem z parserem lekko piję do pewnej autentycznej sytuacji.

Nigdy nie nauczyłem się porządnie robienia Bisonowych parserów (czy ogólnie, parserów opartych o gramatyki), nie miałem okazji. Dlatego dla ludzi potrafiących je sprawnie konstruować miałem zawsze sporo szacunku. Jednak ... nie w sytuacji, gdy partner próbował rozpisać w taką gramatykę XML-owy komunikat, włącznie z permutowanymi produkcjami amortyzującymi różne porządki tagów. A ja dysponowałem przyjemnym API z reprezentacją XML-u jako drzewa, pierwociną przyszłych element-tree różnej maści.

Aha: dziś, po latach, to API jest w fazie „kuli u nogi”...

Konkluzja

… jest banalnie prosta. Stałą powolną stratę wartości trzeba równoważyć stałym, spokojnym rozwojem. Testować i wybierać wartościowe nowe narzędzia, regularnie korygować procesy, dbać by używany kod był żywy, zmieniany i ulepszany.

A przede wszystkim, z niczego nie robić świętej krowy. Coś, co się sprawdziło i dużo dało, tym bardziej wymaga aktywnej pielęgnacji - bo ma większy wkład w wartość firmy i wpływ na projekty. Argument było dobre więc nie ruszajmy jest w dłuższej perspektywie samobójczy. Jeśli stale unikamy drobnych remontów, w końcu przyjdzie nam zburzyć i odbudowywać cały dom.

Zmiany nie muszą być szokowe, lepiej gdy następują płynnie i spokojnie, nawet po cichu. Liczy się efekt końcowy: firma działa trochę inaczej niż działała 5 lat temu, ma poszerzone portfolio technologii i skorygowane procesy; pojedynczy człowiek umie parę rzeczy których nie umiał 5 lat temu, nawet jeśli pracuje w podobnym kontekście, jest w stanie działać trochę inaczej.

Zamknę cytatem, który zanotowałem w roku 2000, i który do dzisiaj bardzo lubię (Michael Reed):

One of our consultants had a seven pound dog that started every night at the foot of the bed. Through the night this dog, by touching here, nudging there, and by always applying just a little bit of pressure, ended up every morning sleeping exactly between him and his wife.

That is the way to change the organization.

W wolnym tłumaczeniu:

Jeden z naszych konsultantów miał siedmiofuntowego psa, który każdą noc zaczynał leżąc w nogach łóżka. W ciągu nocy, pchając tu, pociągając tam, i zawsze stosując tylko odrobinę nacisku, kończył rano śpiąc dokładnie między właścicielem a jego żoną.

Tak należy zmieniać organizacje.

Przypominam to sobie często, gdy dążę do jakiejś zmiany i irytuję jej powolnością. Małe, drobne ruchy potrafią w sumie dać bardzo dużo.

Po prostu muszą następować regularnie.