Zmieniać czy nie zmieniać? O zmianach w IT słów więcej niż kilka (opinia)

Rok temu polski internet żałował końca Chip.PL (ten, o dziwo, reaktywował się w maju 2021) i strony PcLab (autorzy serwisu mieli przejść ze swoim know-how i wysoką jakością do Komputer Świata), wcześniej zobaczyliśmy zamknięcie wielu innych stron, mających niegdyś miliony odsłon.

Niedawno przeżyliśmy też jakże burzliwą zmianę szaty pewnego znanego serwisu, będącego obecnie elementem jednej wielkiej szczęśliwej medialnej rodziny. Nie wszystko tam być może działało poprawnie (zdarzały się błędy typu HTTP 500 „Internal server error”), niemniej jednak było tak dobrze, że na stronie i forum od lat urzędowało grono wiernych entuzjastów. Migracja została dokonana w normalny dzień roboczy, a po niej okazało się, że serwis, delikatnie mówiąc, mija się z oczekiwaniami użytkowników.

Na podstawie popełnionych błędów można sformułować dziesięć żelaznych zasad:

wprowadź wygląd bardzo podobny jak na innych portalach
nie migruj użytkownikom wszystkich danych
na każdym kroku przypominaj o mowie nienawiści
wprowadź o wiele więcej reklam i równie irytującą czcionkę szeryfową, a sama treść ma zajmować jedynie niewielki wycinek ekranu
usuń większość starych funkcjonalności (niektóre z nich dodawaj tygodniami po migracji, ale tylko wtedy, gdy użytkownicy są mocno nachalni i kategorycznie się tego domagają)
zawczasu przygotuj wytłumaczenie, pełne profesjonalnie brzmiących słów, ale bez zbyt dużej ilości deklaracji i konkretów
nie informuj zbyt wiele o pracach (najlepiej, jeżeli notki są wstydliwie schowane gdzieś z boku) i rób wszystko w czasie największej aktywności czytelników
nie przeprowadzaj próbnej migracji na systemie testowym
dodaj większe uprawnienia anonimom i zabierz przywileje użytkownikom z długim stażem
wszystkie komponenty mają być autorskie, a usterkami typu literówki nie warto się w ogóle przejmować (ważne, żeby przy tym zmniejszyć ilość programistów pracujących nad projektem)

Nie zależy mi oczywiście na tym, żeby kogokolwiek lub cokolwiek napiętnować (właściciel serwisu może z nim zrobić to, co chce, i ma do tego święte prawo), nie chcę się też zastanawiać:

w którym obszarze wspomniany serwis się znajduje (rozwój, stagnacja czy upadek)
czy jego wierni czytelnicy cierpią na syndrom sztokholmski
na ile zmiany były konieczne, a na ile były czyimś widzimisię (realizacją własnych ambicji, nadzieją czy podziękowaniem za awans)

Zatrzymam się jedynie nad ostatnim punktem z listy. Nie jestem zwolennikiem stosowania zbyt dużo bibliotek (o ile to ma sens, projekty staram się zawsze pisać w „czystym” języku programowania), jednakże są sytuacje, w których zwyczajnie nie wypada wyważać otwartych drzwi. Podam tylko jeden przykład – zamiast tworzyć od zera zgodny z jakimiś certyfikatami edytor, wystarczy pobrać kontrolkę typu SunEditor, zrobić jej konfigurację i wbudować na stronę. Użytkownik przy tym podejściu dostaje pełną aplikację w stylu Worda (patrz demo), a do bazy może trafiać gotowy sformatowany HTML. Tego typu rozwiązanie wydaje się być o wiele lepsze niż pisanie uszczuplonymi siłami wszystkiego od nowa.

Podam też przykład z drugiego bieguna. Jest taki inny znany polski serwis, który ciągle działa na PHP z 2014. Jeśli pominiemy prędkość (PHP 4 jest znacznie wolniejsze od 7 czy 8), błędy czy braki w funkcjonalności (wszyscy narzekają, ale nikt tam nie rusza nawet przysłowiowego przecinka), to czy taka nonszalancja nie jest otwartym pokazywaniem braku szacunku dla użytkowników, że o niebezpieczeństwie związanym z włamaniem i możliwością użycia tego serwera w botnecie nie wspomnę? W tym wypadku próby zmiany tej sytuacji jak dotąd skończyły się klęską… i wszystkim jest z tym dobrze (nie wzbudził zainteresowania nawet dosyć gotowy kod, który migrował istniejące dane i implementował całość w nodeJS, oferując przy tym chociażby dynamiczną zmianę treści).

Spójrzmy też na projekty, gdzie rewolucja odbyła się dawno temu.

Bardzo dużo osób przez lata ciepło wspominało system operacyjny Windows XP. Był stosunkowo mały i szybki, z czasem jednak zaczął mieć różne widoczne ograniczenia. Pamiętam, jak po przesiadce na siódemkę bardzo narzekałem, że podstawowe operacje wymagają w niej o wiele czasu (o Viście litościwie nie wspomnę, a przecież z nią miałem od początku do czynienia, i nie używałem wtedy bynajmniej 512MB RAM). Windows 7 z czasem zmienił się w Windows 10. Pojawiły się w nim różne mechanizmy zabezpieczeń, wsparcie dla nowych technologii, itp., i choć niespecjalnie lubię szatę graficzną tego „potworka”, i jego wydajność pozostawia bardzo wiele do życzenia, to nie zmienia to faktu, że bez zmiany struktury wewnętrznej niemożliwe byłoby wprowadzenie nowości.

Wszystkie opisane przypadki dotyczą oczywiście faktów dokonanych – właściciel zdecydował o pewnej ścieżce, i użytkownicy muszą się z nim zgodzić, albo poszukać alternatyw.

W przypadku Windows wszystko się udało, i system w dalszym używany jest przez miliony na całym świecie. Ponieważ historię piszą zwycięzcy, to o poważnych usterkach starszych wersji mówi się coraz mniej, ewentualnie przedstawia się je jako kreatywne poszukiwanie najlepszej możliwej opcji.

Zdarzają się też oczywiście sytuacje, w których dodanie nowych funkcjonalności chyba całkowicie zniszczyło markę. Moim sztandarowym przykładem jest Nero Burning ROM, który z małej szybkiej aplikacji do nagrywania płyt stał się tak wielkim kombajnem, że znacznie wygodniejsze okazało się korzystanie chociażby z CDBurnerXP.

Produkty komercyjne nie są idealne, i może nigdy nie będą. Problemem jest model, w którym powstają:

zakładamy w nim, że coś musi być dostarczone (z naciskiem na słowo musi). To dobra zasada, ale jeśli ją połączymy z nierealistycznym, czyli zbyt krótkim lub zbyt odległym terminem, to katastrofa gotowa. Przykładem niech będą regularne poprawki Windows albo projekt Longhborn.
decyzje najczęściej podejmowane są z pozycji silniejszego. Przypadek okienek jasno pokazuje, że to co właściwe w ocenie pracowników wyższego szczebla, niekoniecznie takim jest (proszę spojrzeć na Windows 8 czy 8.1, i katastrofę w obszarze ergonomii).
po przekroczeniu pewnego punktu krytycznego otoczka związana z zarządzaniem czy marketingiem zaczyna przeważać nad częścią techniczną, a ludzie zaczynają robić wszystko, co tylko możliwe, żeby zachować status quo i nie dopuszczać do przeróżnych zmian.

Szczególnie ostatni punkt jest interesujący. Najczęściej nie chodzi o to, żeby zrobić wszystko raz, a dobrze, ale żeby ciągle „gonić króliczka”. System Windows obecnie to nie tylko kod, nie tylko ekosystem, ale przede wszystkim miejsca pracy. Przy tak wielkich przedsięwzięciach wprawienie w ruch całej programistyczno-testersko-menadżersko-partnersko-marketingowej machiny trwa wieki, podobnie długo trwa zmiana jej kierunku albo zatrzymanie. Załóżmy, że nagle Microsoft przygotuje odseparowanie aplikacji jak w iOS czy Androidzie, a sterowniki nie będą mogły destabilizować całości. Ile ludzi należałoby wtedy przenieść do innych projektów albo zwolnić?

IT w wielu wypadkach zamiast do poprawiania jakości życia służy głównie do zarabiania, i to się już nie zmieni (z naszego podwórka - Poczta Polska od 1 lipca 2021 za dostarczenie „potwierdzonego” maila pobierze jedyne 3,75 PLN + VAT).

Pewnym rozwiązaniem jest budowanie projektów w oparciu o model bazaru. Przy tym podejściu nie ma formalizmu związanego z tworzeniem wymagań, ich omawianiem, akceptacją, itp. W takim modelu użytkownicy sami z siebie próbują różnych opcji i proponują albo wybierają to, co im najbardziej odpowiada. Nie jest to rozwiązanie idealne, gdyż wszyscy często muszą mieć duże umiejętności techniczne, a ostateczne decyzje i tak podejmują osoby z wyższymi uprawnieniami (sporo może zależeć od ich charakteru albo przekonań).

Całą koncepcję (porównanie budowania oprogramowania w oparciu o sformalizowany model, przypominający tworzenie przez setki lat wielkich katedr, z modelem, w którym nowe elementy rodzą się każdego dnia na pełnym przekupek bazarze) przedstawiono już w 1997. O tym, jak duży jest potencjał obu wersji, przekonał się chociażby Google, który stosuje ich połączenie (budowanie wielu projektów w modelu bazaru i przenoszenie tylko niektórych, najlepiej rokujących albo najważniejszych, do katedry).

Dużo ludzi w tym momencie powie, że przecież Open Source to margines rynku. To nie do końca prawda. Może rzeczywiście na pulpitach w domach króluje Windows, za to „otwarte” komponenty znajdują się chociażby w Microsoft Edge, a Microsoft coraz bardziej wchodzi we wspomnianą tematykę (WSL, Windows Terminal, WinGet, etc.). Jakby tego mało, to podobno 90% korporacyjnych programistów uważa, że w Open Source tkwi przyszłość biznesu.

Ważne, żeby sobie w tym momencie jasno powiedzieć, że w obu światach („otwartym” i „komercyjnym”) zdarzają się bardzo zgniłe jabłka. Różne metodyki inżynierii oprogramowania przez lata wytworzyły błędne założenie, że wszystko można zrobić łatwo, prosto i przyjemnie (a dziesięciu tanich programistów, żeby nie powiedzieć studentów, może zastąpić jednego dobrego człowieka z wiedzą i doświadczeniem). Do tego doszło nakręcanie rynku przez firmy sprzedające kolejne kursy programistyczne, ewentualnie różnego rodzaju couchów, którym udawało i udaje się przekonywać naiwnych, że każdy ma talent do wszystkiego.

Nadprodukcja lepszych i gorszych klepaczy kodu, jak również spora konkurencja ze strony krajów typu Indie, spowodowała, że obecnie właściwie cały czas należałoby łapać się za głowę.

Przede wszystkim na porządku dziennym jest brak dbałości o komfort użytkownika – zdarzają się „przycięcia” interfejsu (jego obsługa jest często uruchamiana wraz z czasochłonnymi operacjami, zamiast obok nich), źle skalujące się kontrolki, zaprzeczenie podstawowym zasadom ergonomii, itp. Problemy pojawiają się głównie w aplikacjach mobilnych… coraz częściej desktopowych i grach (pisałem już o CyberPunku).

Kwiatki można też znaleźć znacznie głębiej. Wiele lat temu w pewnej aplikacji zauważyłem funkcję, po włączeniu której obciążenie procesora wzrastało na stałe do kilkunastu procent. Bliższa analiza wykazała, że w nieskończonej pętli odpytywano jedno z urządzeń o stan (jeśli dobrze pamiętam, 10000 razy na sekundę). Rozwiązanie, które jest niezbędne jedynie w bardzo specyficznych sytuacjach, w tym wypadku należało zastąpić jedną jedyną instrukcją „poinformuj mnie, gdy stan urządzenia się zmieni”. Próba wyjaśnienia zakończyła się tym, że osoby władne stwierdziły, że zmiana wymagałaby szkolenia i przepisania całości, a to oznacza wydanie grubych pieniędzy. Funkcja pozostała, procesory się grzały, prąd się marnował, problem dalej przeszkadzał (nie chodzi tu nawet o kilka groszy, ale o moc obliczeniową, której zaczynało brakować po uruchomieniu tej funkcji wraz z innymi).

Ile jest takich aplikacji na rynku? Ile jest marnotrawienia zasobów, bo komuś nie chciało się użyć rzeczy znanych od dekad?

Częściowo winne są języki programowania, ale byłoby ogromną uproszczeniem stwierdzenie, że trzeba je zmienić i wtedy będzie lepiej (użycie modnych zabawek w stylu Rusta nie spowoduje, że magicznie dostaniemy same super aplikacje, i project Servo, chociaż oznaczony jako eksperymentalny, jest chyba najlepszym tego przykładem). To ludzie wyrzucają do kosza wypracowane przez lata praktyki i zasady, i notorycznie zapominają o takich „drobiazgach” jak zwalnianie czy oszczędzanie zasobów (również z takich powodów mamy języki typu Java, w których samo środowisko dba, albo przynajmniej powinno dbać o tego typu rzeczy, a do tego swoje zużywa).

Załóżmy, że nie używamy takich „staroci” jak C, tylko mamy np. „nowoczesny” Java Script. Wspomniana konstrukcja „wykonaj coś, gdy wystąpiło jakieś zdarzenie” jest oczywiście bardzo wygodna. Wyobraźmy sobie, że mamy takich zdarzeń zaledwie sto. Ich permutacji bez powtórzeń jest dokładnie 100!, czyli 1*2*3*...*100. To ogromna liczba, i jeżeli programista nie ma żadnego pojęcia o współbieżności, to jego kod tak naprawdę może działać losowo.

Czy można zapobiec popełnianiu takich błędów?

Najbardziej oczywista rada mówi, żeby zatrudniać ludzi, którzy wiedzą, co robią.

Narzędzia muszą być precyzyjnie dobrane do zadań (mój ulubiony przykład: rozpakowywanie dużych plików w Midnight Commanderze może trwać wiele minut, tymczasem użycie zwykłego unzip pozwala to samo zrobić w kilka sekund, a to dlatego, gdyż działa on na zupełnie innej zasadzie).

Ważne jest sprawdzanie, sprawdzanie i jeszcze raz sprawdzanie tego, co zostało zrobione. Częściowo można opierać się na audytach, jednakże te mogą kosztować, albo wymagać udostępnienia na zewnątrz strategicznych informacji (swoją drogą, otwartość kodu wykazuje tutaj swoją słabość i wyższość równocześnie). Oprócz tego koniecznością jest pozostawienie w projektach doświadczonej i wszechstronnej kadry testerskiej. Nacisk musi być położony na oba słowa - obecny trend polegający na robieniu wszystkiego wyłącznie automatami (które zwyczajnie nie są w stanie sprawdzić wszystkich kombinacji), ewentualnie wykonywaniu tylko podstawowych testów, i puszczaniu wszystkiego „na żywioł”, jest naganny. Dobry zespół powinien nie tylko zapewniać różnorodność, ale przede wszystkim mieć ważny głos w podejmowaniu decyzji, czy projekt jest gotowy, czy nie (wspominałem o tym przy wyliczaniu najczęściej popełnianych błędów w tekście „Testowanie to nieco zapomniana już sztuka ?”).

Skoro już wiemy, że tak naprawdę wszędzie możemy spotkać się z problemami, to wrócę do pierwotnego pytania – to zmieniać coś czy nie zmieniać?

Niektórzy mówią, żeby nie ruszać czegoś, co działa. To czasem się sprawdza, ale tylko do pewnego poziomu. Powiedziałbym, że wszystko można podzielić na systemy, czy też elementy krytyczne i niekrytyczne.

W krytycznych trzeba polegać na dobrze sprawdzonych wersjach (np. o długim czasie wsparcia), które muszą być wprowadzane z całą otoczką (odczekanie pewnego czasu od premiery, testowanie na środowisku zapasowym, itd.). Mają one służyć ludziom w sposób nieuciążliwy, mieć jak najmniej znanych błędów, coraz więcej funkcjonalności, a ich zmiany nie mogą być celem samym w sobie. „Wpadki” przy modyfikacji należy napiętnować i dokładnie analizować, żeby uniknąć ich powtórzenia. Mówię tu chociażby o problemach w urzędach z CEPIK, testowaniu powiadomień na produkcji w Mbank, firmware do topowych dysków Samsung 960 PRO (dramatycznie obniżał wydajność albo powodował niestabilność) czy kasowaniu danych w Windows 10 18H2 (zawinił m.in. katastrofalny stan programu Windows Insider i najprawdopodobniej sposób jego prowadzenia przez panią Sarkar).

Przy systemach niekrytycznych jest odwrotnie. Eksperymentowanie z kolejnymi wersjami jest wskazane, gdyż przez zmiany zdobywamy cenne doświadczenie. Należy przy tym pamiętać, że opcje migracji w różnych aplikacjach najczęściej / najbardziej testowane są w scenariuszu „migracja z ostatniej wersji”, i możemy oszczędzić sobie masę problemów, jeśli będziemy się go trzymać.

Średniowiecze, romantyzm, czy oświecenie trwały dziesiątki czy bardziej setki lat. My żyjemy w czasach, gdy każdy przeżywa co najmniej kilka technologicznych epok. W nowoczesnym IT wymiana oprogramowania to normalność. Sam to robiłem, robię i będę robił (np. z moją stroną), i tak naprawdę trzeba narzucić sobie konieczność zmian, gdyż inaczej szybko pozostaniemy dinozaurami.

Trochę inną sprawą pozostaje sprzęt. Jego produkcja i używanie to określony koszt dla środowiska naturalnego, i należy go wybierać z głową (tak żeby starczył raczej na lata). Z tego względu nie ma co kupować laptopa, gdy potrzebujemy stacji roboczej, albo stacji roboczej, gdy chcemy raz na jakiś czas otworzyć Chrome.

Podam przykład takiego zachowania – zamiast katować w warunkach polowych starego poczciwego Precisiona, dałem szansę Medionowi Akoya E4251 (nie sprawdził się, a szczegóły przedstawiłem w recenzji w marcu), Acerowi Swift 1 (opisywałem go w maju i na nim tworzę ten tekst), rozważyłem też MacBooka Air (zrobiłem nawet jego porównanie ze Swiftem) i kilkanaście innych modeli (polecam tekst o grzałkach Intela, łapaniu tego, co jest, w gospodarce tzw. kapitalistycznej, iluzorycznie szerokiej ofercie czy upraszczaniu złączy). Nie powiem, Precision jest dobry i mocny (na biurku posłuży jeszcze długi czas), ale jego chłodzenie w warunkach polowych długo by nie wytrzymało (przy procesorze o TDP 45W kluczowe jest, żeby nie zasłaniać otworów wentylacyjnych), ciągle należałoby uważać na plastikowy spód, a do tego bateria i wyświetlacz i tak wymagałyby wymiany.

W przypadku sprzętu bardziej niż kiedykolwiek konieczna jest weryfikacja każdego elementu. Współczesne komponenty nie tylko mogą wpływać na nasze zdrowie (omawiałem to przy okazji monitorów, wspominałem też przy wpisie o iPhone12 i informacjach o nowszych Samsungach). Producenci z różnych powodów (załamanie się łańcuchów dostawców, ale równie zachłanność i chęć zysku) bardzo kreatywnie podchodzą do parametrów swoich wyrobów. Nie chcę znów dużo mówić o oszczędnościowym chłodzeniu nowego iMaca czy mieszaniu Zen 2 z Zen 3. W ostatnim tygodniu przeczytałem o pewnej "korekcie" dokonanej przez firmę PNY - dysk SSD XLR8 CS3020 bez zmiany oznaczenia otrzymał w specyfikacji TBW mniejsze nawet o 78% (w przypadku wersji 256GB i 512GB stało się ono niższe od TBW taniego modelu zamontowanego w „moim” tanim Swifcie). Takich przekrętów typu „kup panie wieżę Eiffla” jest o wiele więcej (patrz mój przegląd o tym tytule z zeszłego roku, ewentualnie tekst o Samsungu 980 PRO czy serię wpisów o laptopach)

Jeżeli chodzi o przeszłość, to w ogóle nachodzi mnie pewna refleksja. Gdy różne portale nie mają już o czym pisać, to wspomina się Steve Jobsa, czy Freddiego Merkurego. Legenda tych słów powstała m.in. dlatego, że odeszli w pewnym momencie, który był chwilą wielkiego triumfu. Ich historia jest zapewne wszystkim doskonale znana, ale często tu i tam wraca się nawet do najdrobniejszych detali ich życia.

W IT nie ma co żałować starych sław. Warto oczywiście wracać do przeszłości, ale nie można zasłaniać sobie nią całego widoku. Właśnie z tego względu nie żal mi, że ze Spiders Web zniknęły moje teksty. Kiedyś w mikroskopijnym stopniu przyczyniły się do wzrostu tego serwisu, obecnie usunięto je jako przestarzałe lub niezgodne z obecną polityką portalu. Pozostał ślad na mojej stronie i być może w Web Archive, a ja nawet jakoś specjalnie nie zapłakałem. Przez kilka lat po publikacji znacznie rozwinąłem wiedzę i umiejętności, i to, co kiedyś pisałem, dzisiaj często budzi we mnie jedynie uśmiech i politowanie (nie zmienia to faktu, że kiedyś byłem święcie przekonany o swojej racji).