Programowanie narażone jest na nieustanną pokusę bylejakości i pośpiechu, których skutkiem jest często albo fatalna jakość aplikacji, albo lekceważenie użytkownika i jego potrzeb.

Zrobić cokolwiek szybko? Znowu ten pośpiech. Znane jest przecież porzekadło "co nagle, to po diable" i niezliczone przykłady sytuacji, kiedy zabrakło czasu i środków, aby coś wykonać dobrze, ale znalazło się potem i jedno, i drugie, aby to coś wielokrotnie poprawiać. Informatyka to branża cierpiąca od swego powstania na syndrom czarodziejskiej plasteliny. Kilkadziesiąt lat temu udało się ludziom spełnić swe odwieczne marzenie i znaleźć substancję, z której daje się szybko i łatwo zbudować wiele najrozmaitszych rzeczy: a to system bazodanowy, a to telefonię komórkową, a to wbudowany układ sterujący do pralki automatycznej. Figurki lepione z naszej czarodziejskiej plasteliny - instrukcji mikroprocesora - rzeczywiście można tworzyć zadziwiająco szybko w porównaniu z przedmiotami z drewna, metalu czy betonu, a ponadto można je potem względnie łatwo poprawiać bez potrzeby burzenia całości, jeśli coś się nie całkiem uda. Ludzikowi z plasteliny można, nawet kiedy już jest gotowy, oderwać nogę i zastąpić ją inną, lepszą, ale też wygląda on potem jak... ludzik z plasteliny.

Programowanie narażone jest na nieustanną pokusę bylejakości i pośpiechu, których skutkiem jest często albo fatalna jakość aplikacji, albo lekceważenie użytkownika i jego potrzeb, przez co świat zapełniają zawodne i pokraczne, niewygodne w obsłudze twory z plasteliny. Po co zbierać i analizować wymagania, skoro można zacząć budować od razu, a potem w razie czego wszystko się przerobi? Po co starannie projektować system, skoro można od razu zacząć kodowanie, a potem jakoś się te niepasujące do siebie części poskleja w całość? Po co dbać o jakość projektu, skoro w bałaganie też daje się pracować i po co wysilać się na tworzenie produktów dobrej jakości, skoro czarodziejska plastelina pozwala na pozór bezkarnie poprawiać, sztukować, zaizolować kawałkiem dętki, przymocować drutem?

Miło jest sobie pozrzędzić, ale z drugiej strony nie można zaprzeczyć, że to dzięki systemom informatycznym dzisiejszy świat dramatycznie przewyższa ten sprzed lat trzydziestu czy czterdziestu pod względem możliwości, dobrobytu, bezpieczeństwa i organizacji, cokolwiek na ten temat sądzą rozmaici zwolennicy powrotu do jaskiń czy wręcz na drzewa.

Ponadto, szydząc sobie z typowego projektu informatycznego: drwala, który nie ma czasu porządnie naostrzyć siekiery, bo tak bardzo się śpieszy z rąbaniem drzewa, nie sposób przecież zapomnieć o zagrożeniach z przeciwnej strony: drwalach tak zajętych ostrzeniem siekiery, że nie mają czasu na ścinanie drzew. Czynniki psychologiczne powodują, że chętnie - uchylając się przed naprawdę trudnymi wyzwaniami - uciekamy w rytualizację, mnożenie zbędnej dokumentacji, manię zebrań i posiedzeń, wiarę w rzekomo uzdrowicielską moc procedur, procesów, poziomów dojrzałości i sprawności, duszących prawdziwą kreatywność i skuteczność.

Czy nie ma drogi pośredniej między jedną a drugą skrajnością? Jest, oczywiście - to pośpiech kontrolowany, gdzie umiejętność i wprawa pozwalają poruszać się szybko, lecz pewnie, a ścieżki na skróty niekoniecznie prowadzą na manowce.

Pomiary w pośpiechu

Warunkiem skutecznego pośpiechu kontrolowanego jest umiejętność nadzoru w biegu, tak żeby zakręt móc przejść na piszczących oponach, ale z niego nie wylecieć, zaś pokonując na skróty bezdroża, orientować się zręcznie za pomocą mapy, kompasu, zegarka i bystrych oczu - i nie zabłądzić.

Nie jesteśmy w stanie kontrolować tego, czego nie umiemy zmierzyć. Ale pomiar nie jest w informatyce słowem lubianym - nawet poddany mi przez redakcję tytuł tego artykułu omija je, zastępując niebudzącym lęku słowem ocena. Choć jako specjalista w branży nie raz spierałem się przy piwie, czy to testowanie, czy też utrzymanie oprogramowania jest bardziej niesłusznie lekceważone w praktyce naszego przemysłu, wydaje się, że palma pierwszeństwa należy się jednak pomiarom. Dobry kierowca rajdowy nie musi wysiadać z samochodu i mierzyć promienia skrętu taśmą tylko dzięki temu, że wprawa pozwala mu mierzyć bez przerywania jazdy. Przewodnik, na pozór bez wysiłku wyprowadzający przez gęste krzaki wprost na zamierzony punkt, nie wlecze za sobą wielokilometrowej nici Ariadny tylko dlatego, że nieustannie podczas marszu mierzy przebytą odległość, kierunek, nachylenie terenu. W przemyśle informatycznym chętnie udajemy kierowców Formuły 1 oraz dzielnych przewodników, nie mając niezbędnych po temu umiejętności mierzenia.

Brak umiejętności sprawnego mierzenia uniemożliwia zarządzanie ryzykiem, zastępując je unikaniem ryzyka lub bezsensowną brawurą. Unikanie ryzyka w inżynierii oprogramowania rodzi projekty sztywne, zbiurokratyzowane, nieskuteczne, omijające właściwe wyzwania. Bezsensowna brawura oznacza fanfaronadę przy wyznaczaniu celów, środków i terminów, po czym... To, co zdarza się potem, także można oczywiście zmierzyć. Odpowiednią miarą, nie do końca jeszcze uznaną przez fizyków, jest "och-nie-sekunda" (oh-no-second), stosowana do określenia czasu upływającego od chwili, gdy się zorientowaliśmy, że popełniliśmy NAPRAWD˘ DUŻY BŁŃD (np. klikając "wyślij do wszystkich").

O zarządzaniu ryzykiem i skutecznych pomiarach napiszę wkrótce, jeśli mi czas i redakcja pozwolą. Na razie pora przejść do sedna: jak szybko ocenić jakość produktu, czyli jak mierzyć w biegu?

Precz z grzybami

Wyobraźmy sobie, że pełnimy funkcję Naczelnika Jakiejś Jednostki Administracyjnej. Najnowsza polityka rządu kładzie szczególny nacisk na oczyszczanie lasów z grzybów. Dlaczego - nieważne, ale nietrudno sobie wyobrazić... Grzyby przecież bywają trujące, a ludność musi być chroniona przed zagrożeniami. Następnie, jesteśmy nowoczesnym europejskim krajem, a grzyby nie mają witamin, nie poddają się racjonalnej hodowli i wzbudzają - jako pozbawione chlorofilu - zastrzeżenia wojujących środowisk wegańskich. Poza tym grzyby to pasożyty, co kłóci się z ideami solidaryzmu społecznego (lub jest ich złośliwą karykaturą), a ich preferencje seksualne też są - zdaje się - nad wyraz nieprawomyślne. Niechęć do grzybów ma wyraźnie ponadpartyjny charakter, lasy mają więc być odgrzybione, a za dwa dni przyjedzie - o czym dał nam cynk kolega z Sąsiedniej Jednostki Administracyjnej - Nadzwyczajna Komisja, żeby sprawdzić stan odgrzybienia naszego lasu podmiejskiego. Mamy więc SZYBKO OCENIĺ JAKOŚĺ LASU!

Nie muszę dodawać, że dotąd w tej sprawie nie zrobiono nic. Gdyby las był już wcześniej systematycznie odgrzybiany, nie byłoby paniki. Oczywiście, identycznie jest z potrzebą szybkiej oceny jakości aplikacji. Gdyby projekt był od początku prowadzony porządnie, jakość aplikacji byłaby po prostu znana - realizowana i mierzona cały czas. Cóż, świat jest jednak niedoskonały, więc idziemy mierzyć w pośpiechu.

Grzybobranie

Zasada podstawowa - nie da się trafnie ocenić stanu zagrzybienia lasu, nie wysyłając tam ludzi odpowiednio zmotywowanych, umiejących szukać grzybów! Można, rzecz prosta, wysłać do lasu krótkowidza, który na grzybach się nie zna, dla całkowitej pewności mówiąc mu złowieszczym głosem "Mam nadzieję, że przyniesie mi pan DOBRE wiadomości!". Wtedy ocena jakości lasu będzie wprawdzie odpowiednio szybka, ale dramatycznie nietrafna, a nie o to chyba nam chodzi. Śmiejąc się z takiej metody, nie zapominajmy, że dokładnie tak odbywa się często próba szybkiej oceny jakości aplikacji: jeśli nie wykonują jej fachowi testerzy, odpowiednio nagradzani za przynoszenie wieści o błędach, wynik pomiaru jest bezwartościowy.

Dobry grzybiarz szuka grzybów tam, gdzie spodziewa się je znaleźć. Wykorzystując sobie tylko znane intuicje, wie gdzie zwykle rosną koźlaki, gdzie rydze, a gdzie opieńki, dzięki czemu przynosi ich pełne kosze. Tak samo doświadczony tester wykorzystuje swe wcześniejsze doświadczenia, aby szukać błędów ocenianej aplikacji tam, gdzie spodziewa się je znaleźć. Jak rydze lubią rosnąć pod świerkami, tak błędy lubią się np. gromadzić w pobliżu wartości krańcowych, na granicach przedziałów i dobry tester tam właśnie będzie ich szukać. Dalej, błędy chętnie dojrzewają w miejscach odludnych, których nikt od dawna nie testował, bo kod jest tak zawiły, że lepiej go nie ruszać. Wiemy też, że obecność kilku błędów zwykle oznacza, że jest ich tam o wiele więcej - wynikają bowiem z tych samych błędów projektowania. Kolejną regułę streszcza powiedzenie "gdzie kucharek sześć...": jeśli kod był wielokrotnie zmieniany, jeśli modyfikowało go wielu programistów - tam warto poszukać błędów. Zasad jest wiele, a profesjonalni testerzy powinni je znać.