Iteracja – według Słownika Języka Polskiego PWN to „metoda w analizie matematycznej i programowaniu polegająca na wielokrotnym stosowaniu tego samego przekształcenia lub procedury”. Posiłkując się jeszcze dodatkowo Wikipedią, można przyjąć, że iteracja to zapętlenie np. procedury; zresztą łacińskie iteratio znaczy powtarzanie. Takie rozumowanie może, oczywiście, przeprowadzić humanista, który z tym pojęciem niekoniecznie zetknął się wcześniej, w każdym razie nie na gruncie nauk ścisłych (bo w sztukach pięknych iteracje się spotyka, o czym przypomina zamieszczona grafika M.C. Eschera i, niekiedy, muzyka A. Vivaldiego).

„Wcześniej” – zanim humanista zaczął pracować np. w korpo IT, wybrał się na modny kurs programowania dla kobiet czy podyplomowe studia z zarządzania projektami informatycznymi lub jeszcze zanim okazało się, że większość znajomych pracuje w IT.

Obok iteracji znajdziemy inne słowa: na przykład debugowanie, apdejtowanie, inputowanie (nie mylić z imputowaniem!), bekap, implementacja (ale nie implantacja!) i tak dalej. Iteracja jednak jest jednym z najtrudniejszych pośród nich. Pozostałe wymienione zupełnie randomowo są proste. Wystarczy je przetłumaczyć na polski i wiadomo w czym rzecz. Z iteracją nie jest tak łatwo.

W tym pojęciu mieści się wszystko to, co obce klasycznie pracującemu humaniście, takiemu, dajmy na to Kantowi (który pisał ponoć krótko, ale myślenie zabierało mu bardzo dużo czasu). Prototyp, który w informatyce, bywa efektem pierwszej iteracji, czyli w pewnym sensie pierwszej wersji programu, w niektórych, choć nie częstych przypadkach, może być wersją udostępnianą użytkownikom. Ilu humanistów zdecyduje się udostępnić swoje teksty w wersji wstępnej, nawet jeśli nazwiemy je szkicową formą? Przypomnijmy sobie etapy powstawania pracy humanistycznej: formułowanie tematu, rozeznanie w literaturze przedmiotu, wybór i wstępna analiza źródeł, stworzenie kwestionariusza badawczego (zestaw pytań, na które zamierza się odpowiedzieć w pracy), weryfikacja tematu, stworzenie wstępnego konspektu, pierwsze przymiarki do pisania – i tak dalej. Tak zwykle wygląda praca nad humanistycznym dziełem, które pokazuje się w pierwszych fragmentach na (pro)seminariach, a wreszcie w wersji gotowej, broni w czasie egzaminu magisterskiego czy doktorskiego. Broni się dosłownie: przyjętych metod naukowych, postawionych tez, wywodu…

Tymczasem w zwinnych projektach informatycznych szybko tworzy się prototyp, który spełnia założone podstawowe funkcjonalności, a następnie powstają kolejne wersje w procesie iteracji. Tak jakby napisać prototyp doktoratu od razu po zestawieniu kwestionariusza badawczego – czyli, faktycznie, zestawieniu funkcjonalności, które praca naukowa ma spełniać. Czy badacz przy zdrowych zmysłach pokaże światu to, co stworzył od razu, najlepiej jak na hackathonie w ciągu doby? Naukathon. Armageddon. Zostawmy tę piękną katastrofę. Popatrzmy na to inaczej: iteracja, choć jest przydatną metodą pracy, może prowadzić do lekkiego traktowania odbiorcy. Iteracja rozumiana tu ostatecznie jako przepisywanie, dodawanie, uzupełnianie, poprawianie i jeszcze wiele innych -aniów. Iteracja rozumiana jako pokazywanie światu nieskończonego (a czasem ledwo zaczętego) produktu, po to, by dzięki pomocy „świata” móc go naprawiać. Iteracja wyzwala w zespole tworzącym oprogramowanie akceptację sytuacji, w której ktoś zwraca nam uwagę na błąd, a my lekko mówimy: wiemy o tym, to będzie poprawione w następnej wersji.

Wyobraźmy sobie takie sytuacje:

– na koncert wychodzi orkiestra i po występie, pełnym kiksów, niedociągnięć, z symfonii w ogóle wypadła III część (nie została zaliczona do MVP) dyrygent oświadcza, że uwagi na temat występu można zgłaszać w sekretariacie, bo dzisiejszy koncert to była podstawowa wersja, a naprawdę nawet prototyp. Releasu wersji 1.0 można się spodziewać za miesiąc lub dwa – zależy od tego, ile czasu muzycy będą mogli poświęcić na taki side-project;

– chirurg po nieudanej operacji zastrzega, że nie powiodło się, bo ciągle nie wyszedł z fazy testów, ale jest już dostępny w wersji beta. W kolejnym cięciu byłby bezbłędny, niestety, pacjent nie wymaga kolejnego cięcia;

– pisarz wydaje książkę, w której białe niedrukowane strony są opatrzone tekstem „pojawi się w wersji 2.0”.

Ale właśnie, książki: znamy to dobrze z książek. „Wydanie czwarte poprawione i uzupełnione” – autor zatem ulepszył treść, inaczej mówiąc: zaktualizował książkę. W czasach ebooków mamy z tym do czynienia częściej – szczególnie w przypadku podręczników w dyscyplinach, w których ustalenia zmieniają się znacznie częściej niż w historii powszechnej XVI–XVII wieku (choć i tu zdziwilibyście się…). Czasem całą książkę pisze się na nowo, czasem zmienia się mniej niż 20% – te przypadki są dobrze znane wydawnictwom, bo regulują między innymi to, czy ponownie wypuszczane na rynek dzieło jest dodrukiem (zmiany typu korektorskiego, literówki, błędy pisarskie, niewielkie poprawki stylistyczne), czy kolejnym wydaniem (w tym przypadku zmiany muszą być znaczące: np. modyfikacja struktury, poprawa błędów faktograficznych lub wnioskowania itd.). Zmiany powyżej 20% objętości książki (np. dodanie nowego rozdziału, podmiana obszernych fragmentów lub ich usunięcie) uprawniają nawet do ignorowania umowy autorskiej i umożliwiają publikację takiej książki – pod nowym tytułem – w innym wydawnictwie.

Przenieśmy te zasady na rynek wytwarzania oprogramowania, iteracyjnego. Oddajemy w ręce użytkowników aplikację w wersji beta. Uniemożliwiamy odbiorcom narzekanie, bo beta to wersja nieskończona (o czym głośno trąbimy wszem i wobec), to dajemy produkt zabugowany (czyli z błędami). Niekiedy wręcz pobieramy opłaty za taki program, mimo że to ciągle jest wersja beta, a nawet jeśli oprogramowanie jest darmowe, to twórcy czerpią z niego innego typu zyski – fejm to też zysk… (polecam tu ciekawe omówienie kwestii, dlaczego Google tak długo utrzymywało wersję beta Gmaila).

Po wypuszczeniu na rynek nowej wersji (nie beta, tylko normalnej, pełnej wersji) wiele programów czy aplikacji jest aktualizowanych (znaczy to, że zespół nadal iteruje…). Zmienia się wtedy wersję programu. W dużym uproszczeniu: małe zmiany oznaczają wszystkie liczby po kropce, duże zmiany – liczby przed kropką. To mechanizm podobny do rozróżnienia między dodrukiem a nowym wydaniem. Od pojawienia się ebooków te pojęcia – nowe wydanie lub dodruk – trochę straciły znaczenie. Przywodzi mi to na myśl „sprawę biografii Kapuścińskiego” szczegółowo opisaną przez Roberta Drózda w Świecie Czytników, a także informacje Amazonu dla autorów pragnących aktualizować swoją książkę. Czytamy tam: „wysłanie użytkownikom zaktualizowanej wersji może usunąć jakieś notatki lub podkreślenia, które wprowadzili do tekstu, zatem poprawki muszą dawać większą wartość niż te niedogodności”. Ile razy zdarzyło mi się po aktualizacji oprogramo
wania stwierdzić, że zniknęły moje prywatne notatki czy – jak w przypadku niedawnej aktualizacji Apple Music – playlisty…

Stąd zresztą inspiracja do napisania tej notki, poświęconej pozornie iteracjom. Naprawdę dotykam problemu perfekcjonizmu lub po prostu jakości w świecie wymagającym konsumpcji on demand. Kryję się w grupie humanistów, których – może niesłusznie – posądzam o dążenie do wypolerowania własnego dzieła przed jego opublikowaniem, a faktycznie po prostu tęsknię za jakością.

Wiem, co to jest quality assurance i testowanie jakości oprogramowania, wiem, co to jest continuous integration, ale – dziwne! – często nie znajduję tego w oprogramowaniu, z którego korzystam na co dzień. Zmusza mnie właśnie to do zastanowienia się nad podejściem zespołów IT do jakości, a może raczej do bylejakości i uważam, że wynika to właśnie z bardzo lekkiego stosowania formuły iteracyjnego tworzenia produktu, zwłaszcza, że znam zespoły, które sobie swobodnie iterują, nie do końca wiedząc, dokąd zmierzają – ale to naprawdę wyjątkowe i niepowtarzalne przypadki. Moje uwagi na temat iteracji nie znaczą też, że postuluję, by w IT podobnie jak w humanistyce cyzelowano dzieło, ale by traktowano odbiorców nie jako króliki doświadczalne, lecz jako właśnie odbiorców.

Humanistów zaś namawiam, przynajmniej tych, którzy tworzą dzieła idealne, nigdy nie skończone i zatem nigdy nie pokazane publicznie, by nauczyli się, że iteracja może być dobra. Dla nich samych –  naprawdę szybciej skończą, dla dzieła – dzięki poddaniu dyskusji treść czy struktura może zyskać na jakości.

Teraz czyszczę kesza i spadam iterować :)

Uprzejmie przepraszam za zamieszczenie tylu wyrażeń mogących niektórym sprawiać kłopot. Chyba wszystkie można znaleźć w Wikipedii.