A może Microsoft aktualizuje Windows 10 zbyt często? Opinie są podzielone

Windows Insider jest pośmiewiskiem niemal od samego początku. Najpierw wydawał się być marketingową odpowiedzią na klęskę Windows 8: całkowicie otwarty model rozwoju systemu miał być dowodem na słuchanie głosu klientów, by już nigdy więcej nie doprowadzić do katastrof w stylu Ekranu Start i pełnoekranowych aplikacji. Ponadto, atmosfera antycypacji na kolejne wydania („build”) systemu miała wspomagać proces budowania społeczności wokół Windows, a więc czegoś, co nigdy nie należało do silnych stron Microsoftu. Ludzie używają systemu Windows głównie z przyzwyczajenia, bierności lub przymusu, a nie z powodu identyfikacji z marką (jak Apple) lub projektem (jak Debian). Co ciekawe, budowanie społeczności wokół Windows jednak się powiodło, a jej aktywność jest widoczna w aplikacji Feedback Hub.

Okazuje się jednak, że oprawa marketingowa, w postaci szumu wokół kolejnych wydań, rozsyłania tapet z kotami ninja oraz ewangelizatorską działalnością Dony Sarkar, została wzięta na serio również w samym Microsofcie. Projekt, zorientowany na mniej ściśle techniczne zagadnienia, niż tzw. „release management”, został uznany za całkowicie wystarczający argument za zwolnieniem większości zespołu dedykowanych testerów. Od teraz problemy mają być znajdowane przede wszystkim przez telemetrię, rozszerzony SQM (odpowiednik programu zapewniania satysfakcji klienta) oraz przede wszystkim WER, czyli Windows Error Reporting, wysyłający szczegółowe sprawozdania na temat najmniejszych nawet niepowodzeń. Taka góra danych ma być przetwarzana przez Microsoft celem lokalizowania i naprawy problemów. A Feedback Hub, służący do „ręcznego” zgłaszania błędów i sugestii, miał być źródłem dodatkowym. Być może siły sprawcze w Redmond dały się nabrać na własną historyjkę, mówiącą, że głos społeczności będzie siłą napędową rozwoju Windows i na tej podstawie zwolniły testerów, ale faktem jest, że do zgłoszeń w Feedback Hub zaglądano sporadycznie i wybiórczo: jak był czas, jak coś eksplodowało popularnością na Twitterze, jak akurat brakowało pomysłów na nowe, „fantastyczne” funkcje. Ale testy miały się robić same, za pomocą (generalizując) telemetrii.

Dowody na to, że testerów nie da się zastąpić sztuczną inteligencją chmury Azure, przyszły bardzo szybko. Trzecie wydanie Windows 10, wersja 1607, zostało opublikowane bez poprawnej obsługi kamery internetowej. Wspominał o tym, krytykując częst aktualizacje, Paul Thurrott. Owszem, urządzenia instalowały się poprawnie, warstwa abstrakcji dla urządzeń wideo działała prawidłowo, bezbłędnie również dostarczając model uniwersalnego sterownika dla klasy kamer nowej generacji. Telemetria, Windows Update oraz WER informowały zatem wedle swej najlepszej wiedzy, że wszystko jest w jak najlepszym porządku. Szkoda tylko, że użytkownicy zamiast obrazu z kamery widzieli czarny prostokąt. To doskonały przykład awarii, którą wykryliby „ludzcy” testerzy.

Istnieją jednak ludzcy testerzy – członkowie Niejawnego Programu Testów systemu Windows. Jest ich kilka milionów. Oni też wtedy nic nie zauważyli? Ależ nie, mnóstwo osób zgłaszało ten problem. I tutaj pojawia się kolejna kwestia: zbudowanie społeczności wokół użytkowników mało technicznych skutkuje fatalnej jakości raportami o błędach. W większości były one pozbawione szczegółów, napisane fatalnym językiem i źle sklasyfikowane. Ponadto, wiele osób zamiast wyszukać podobny problem, postanawiało od razu założyć nowy raport. Dzięki czemu zamiast jednego zgłoszenia o niedziałającej kamerze, oznaczonego tysiącem punktów poparcia, wysłano kilkaset zgłoszeń, z których większość była oznaczana najwyżej przez trzy albo cztery osoby.

Na domiar złego, Feedback Hub posiada dziwnie rozmytą i skomplikowaną metodę podziału na błąd, „uwagę” oraz sugestię nowej funkcjonalności. Formularz zgłoszeniowy jest nieco dziwaczny i zachowuje się w sposób zupełnie odmienny od rozwiązań stosowanych na przykład w środowisku BugZilla. A już zupełną bzdurą jest to, że zawartość Feedback Hub, który jest stroną internetową, jest niedostępna spoza aplikacji Windows Insider! Szereg czynników sprawia zatem, że „feedback” przesyłany w ramach inicjatywy Insider pozostawia bardzo wiele do życzenia.

Konsekwencją tych faktów jest naturalnie degradacja jakości. Objawia się albo niezdolnością wydania nowej wersji (aktualizację 1803, oznaczoną tak od marca 2018, nazwano kwietniową, a wydano w maju) albo absurdalnym pośpiechem i publikacją systemu serwerowego z uszkodzoną przeglądarką procesów, byle tylko zdążyć z terminem, zapewne celem „uniknięcia blamażu związanego z opóźnieniami”.

Temat nieakceptowalnie niskiej jakości dostarczanego produktu, instalowanego zresztą na siłę (Windows 10 aktualizuje się sam, również do nowej wersji całego systemu), stał się przedmiotem bardzo żywiołowej debaty wśród publicystów IT. Redaktor serwisu Windows Central, Zac Bowden, zwraca uwagę na to, że mimo powszechnej dezaprobaty dla częstych aktualizacji Okienek, inżynierowie Microsoftu są zdecydowanymi zwolennikami takiego modelu. Ich przychylność nie wynika z nabrania się na rzekome zalety programu Insider. Bierze się ze świadomości, jak wiele usprawnień, między innymi dla modelu programistycznego UWP, jest wprowadzanych między wersjami. Tworzenie nowoczesnych i energooszczędnych aplikacji jest niewątpliwie łatwiejsze dla wersji 1809, niż 1507. Podobnie twierdzą ludzie z działu Windows Server. Oraz inżynierowie z wyższym stażem: pamiętają oni poprzedni cykl wydawniczy, polegający na rozwijaniu kodu przez pierwszą połowę czasu, a testowanie przez drugą. Z jego powodu, jeżeli coś było gotowe później, musiało czekać trzy lata, a nie trzy miesiące.

Rafael Riviera sygnalizuje w jeszcze wyraźniejszy sposób, że problem tkwi w zarządzaniu, a nie samym pomyśle: nieoficjalne rozmowy wskazują bowiem, że krąg Release Preview, przeznaczony do testowania kandydatów na wydania finalne, jest powszechnie uznawany za krąg „dla słabeuszy” i nietraktowany ze szczególną powagą. Najwyraźniej liczy się bowiem duma z dostarczenia nowych funkcji i chęć zaprezentowania ich światu – zapewne napędzana wskutek wewnętrznych kryteriów oceny pracowniczej dla zespołów składających się na dział Windows. Każdy próbuje wyśrubować normy i dowieść istotności swojego projektu poprzez „empire-building” i forsowanie publikowania w kanale Insider Fast. To oczywiście szalenie szkodliwa (i dawno już opisana, należąc wręcz do kanonu porażek) postawa w projektach IT i proszenie się o katastrofę. Nie zanosi się jednak na zmianę. Dona Sarkar jest bowiem nadmiernie wyrazista od samego początku i prawdopodobnie świetnie się z tym bawi. A Riviera, za swój Twitt na ten temat, zebrał po łbie z wielu stron, do tego stopnia, że usunął swój wpis na ten temat.

Skoro zatem model półrocznych aktualizacji nie działa poprawnie, a program Insider cierpi na poważne bolączki, może naprawdę warto przełączyć się na roczne dostarczanie i spokojniejszy model rozwoju? Niekoniecznie. Usiłuje to wykazać Peter Bright, posługując się logicznym i słusznym argumentem: jeżeli półroczne wydania sprawiają problemy, to przechodząc na wydania roczne bez żadnych innych zmian, odroczymy jedynie problem w czasie. Za przykład podaje usługę Office 365: subskrypcyjny pakiet biurowy aktualizuje się w tle co miesiąc (w trybie Insider nawet co tydzień!), co jest zupełnie niezauważalne. Nigdy nie następuje „downtime” – pakiet jest zawsze gotowy do pracy, aktualizacje zachodzą pod spodem i bardzo rzadko wymagają chwilowego wyłączenia programu, a nigdy – restartu komputera. Tymczasem od wydania wersji MSO 16, czyli obecnej postaci „rolling release” pakietu Office 2016 wydawanego w ramach subskrypcji, ani razu nie było afery z wadliwie działającym Wordem, źle liczącym Excelem, czy PowerPointem gubiącym slajdy. Problem tkwi zatem w procesie, a nie w samym pomyśle na półroczne aktualizacje.

To przecież oczywiste. Ale dopiero, gdy powie się to na głos. Wiele osób w branży IT twierdzi, że należy zmniejszyć prędkość aktualizowania Windows 10. Ale to pogląd płynący z błędnego i niesprawiedliwego przekonania, że firma z Redmond potrzebuje „taryfy ulgowej” i najwyraźniej zasługuje, by ją dostać. Może poprawne testowanie produktu jest za trudne dla Microsoftu? Dajmy im więcej czasu. A może programiści są zbyt przemęczeni i nie mają siły zagwarantować wystarczająco wysokiej jakości? Pozwólmy im trochę wolniej popracować. Nie potrzebujemy przecież nowych funkcji ani nowych API. Co prawda system jest płatny, ale jakimś cudem trzeba wybierać między jakością, a nowinkami. Bądźmy wyrozumiali, weźmy tę rzadszą wersję, która za to nie kasuje plików, a strudzonym pracownikom Microsoftu dajmy trochę odetchnąć.

Więc owszem, obecny model półroczny nie działa. Ale rzeczą, której użytkownicy Windows 10 jako klienci powinni oczekiwać, nie jest zmniejszenie prędkości aktualizacji, a poprawa procesu. Wymuszenie lepszych praktyk dla Feedback Hub. Mniejsza bezczelność w podejściu do testów i trochę mniej nieprofesjonalny język Dony. A może zatrudnienie testerów…? Niewątpliwie pomogłaby rezygnacja z rozwoju i dodawania bzdur, jak Portal Rozszerzonej Rzeczywistości, Paint 3D i inne zabawki, których na pewno nikt nie używa. W końcu less is more. To akurat podobno już się zmieniło.

Nowe funkcje i (przede wszystkim!) nowe API środowiska programowania, szczególnie UWP, powinny w systemie lądować natychmiast. Tak, jak ma to miejsce w przypadku pakietu Office. Aktualizacja powinna po prostu być przezroczysta, odbywać się w tle. A więc nie wymagać pół godziny downtime’u i trzech restartów. W przeciwnym wypadku mierzymy się z monolitycznym modelem znanym z Androida, gdzie nowe API, zabezpieczenia i funkcje nie trafiają do tańszych telefonów, bo trzebaby było przebudować sterownik do diody powiadomień, czy inne cuda. Dopiero wtedy można mówić o realizacji modelu Software-as-a-Service i dostarczania systemu Windows 10 jako usługę.

Obecny stan procesu aktualizowania Windows 10, opisywany często słowem „trainwreck” wymaga przede wszystkim zmian psychologicznych. Być może jest to niemożliwe bez dalszych zmian personalnych (tak podejrzewam), ale to bez znaczenia. Windows Insider powtarza błędy znane i opisane już lata temu, a są to błędy związane z procesem produkcyjnym, zatem z czynnikiem ludzkim. Dopiero na końcu jest to wina rozwiązań technicznych. Zdaję sobie sprawę z ograniczeń modelu aktualizowania obrazów Windows, stosu serwisowego i ultraskomplikowanego, pozornie genialnego narzędzia DISM. Ale należy zacząć od rozwiązywania problemów z ludźmi, a nie z kodem.