COMPUTERWORLD

19 lutego 2014 • NR 4/1019

ZARZĄDZANIE

Błąd Arystotelesa w IT

Informatyka, niby do bólu racjonalna, ulega modom, a nowe trendy szybko są przerabiane przez marketingowców na mdlącą papkę. Bzdurne mistyfikacje dotyczą także inżynierii wymagań.

Bogdan Bereza

iStock_000007597823Medium.jpg

Arystoteles twierdził, że szybkość spadania przedmiotów zależy od ich ciężaru, a więc dziesięciokilowy kamień spada dwa razy wolniej niż kamień dwudziestokilowy, a równie szybko co, ważąca także dziesięć kilo, ogromna płachta tkaniny. Dokonał w ten sposób kuszącego, pozornie logicznego uogólnienia, ale nie potrudził się o przestrzeganie przy tym zasad naukowych. Ładne słowa i proste niby-prawdy pocieszają skutecznie, a jeśli je dodatkowo skutecznie rozpowszechniamy, bliźni patrzą na nas z podziwem i płacą nam dobre pieniądze za głoszenie modnych bzdur.



Błędy Arystotelesa w IT

Kiedy pierwszy raz, wiele lat temu, uczestniczyłem w poważnej międzynarodowej konferencji inżynierii oprogramowania, byłem zdziwiony, jak trudno wśród dziesiątek prezentacji było znaleźć coś naprawdę przydatnego. Większość prezentacji nie miała żadnego waloru ogólności, to były takie anegdoty czy historyjki z konkretnego projektu, z których jednak niewiele wynikało dla innych projektów, produktów, technologii. Jeszcze bardziej zdumiał mnie fakt, że takie pseudokonkrety, gotowe rozwiązania pasujące do jednej sytuacji, cieszyły się największym powodzeniem słuchaczy, podczas gdy prezentacje usiłujące wejść na wyższy poziom, sformułować jakieś uogólnienia, krytykowano, jako zbyt teoretyczne… o ile nie brzmiały dostatecznie ogólnikowo i nie obiecywały gruszek na wierzbie.

Kilka lat później pokusiłem się o tezę, którą z dumą zaprezentowałem na konferencji EuroSTAR w Monachium w 1998 r. pt. „Czy inżynieria oprogramowania jest naukowa?”. Z entuzjazmem neofity głosiłem, że znaczna część twierdzeń inżynierii oprogramowania to gołosłowne anegdotki, oparte na pojedynczych obserwacjach, podniesione do rangi ogólnych twierdzeń bez próby naukowego sprawdzenia. Czekałem na aplauz i pochwały, a otrzymałem to, na co zasługiwałem: kompletną obojętność. Nie wiedziałem wtedy, że choć miałem rację, to nie wypadało o tym mówić, bo wiele osób na głoszeniu modnych bzdur zarabia ciężkie pieniądze, zyskuje sławę, a przynajmniej możliwość zaistnienia na konferencji, opublikowania książki czy artykułu.



Skoro nie wypada, po co o tym pisać?

To, że w inżynierii oprogramowania dość bezkarnie szerzą się rozmaite modne bzdury, nie oznacza przecież, że niczego innego w niej nie ma. Przeciwnie – można w niej znaleźć mnóstwo trafnych, słusznych metod, technik, technologii, twórczych pomysłów, których przemysł IT nie wykorzystuje nawet w połowie. Jedną z przyczyn jest właśnie popularność łatwych, pozornie skutecznych, obiecujących gruszki na wierzbie modnych bzdur. Jeśli nauczymy się je wykrywać i ignorować, będziemy pracować lepiej, sprawniej, efektywniej.



Kulturalnie, strukturalnie

Jedną z przyczyn łatwości, z jaką modne bzdury się szerzą, jest powszechny brak znajomości historii. Ludzie wierzą, że nowe znaczy lepsze i że nie ma powodu zaprzątać sobie głowę tym, co było 20 czy 40 lat temu. A jednak powód jest: w ten sposób unika się kosztownego powtarzania błędów, ulegania czarowi pseudonowości, które pod ładnym opakowaniem przemycają za duże pieniądze rzeczy znane nam od lat.

13642.jpg

Jeśli chcemy być od konkurencji dużo lepsi, trzeba pamiętać o zagrożeniu błędem Arystotelesa, nie szukać tanich pocieszeń i kierować się własnym rozumem, a nie modą ani połyskliwym marketingiem idei.

Niektórzy z Czytelników wiedzą, a może nawet pamiętają, że w językach programowania w latach 50. i 60. dominowały straszne konstrukcje z użyciem instrukcji GOTO, a ich efektem był tzw. „kod spaghetti”: trudny albo i niemożliwy do zrozumienia, do przetestowania, do modyfikowania.

Słynny holenderski informatyk Edsger Dijkstra wynalazł o wiele lepszy sposób: języki programowania pozbawione GOTO, a dysponujące instrukcjami, takimi jak: IF, CASE, WHILE, FOR. Dzięki temu wynalazkowi nastąpił prawdziwie kwantowy skok wydajności pracy programistów: zamiast tracić czas i energię na walkę z potworem GOTO, mogli skoncentrować się na sprawnej implementacji algorytmów. Testowanie kodu stało się możliwe.

Nowe języki Dijkstra nazwał „strukturalnymi”. W latach 70. zaczęła się wielka kariera tego słowa, masowo nadużywanego, sprowadzonego przez złodziei idei do nic nieznaczącego, ogólnikowego przymiotnika zastępującego słowo „dobry”. Tej modzie na słówko „strukturalny” ulegali zarówno cwaniacy, szmuglujący za jego pomocą modne bzdury, jak i rzetelni fachowcy, zmuszeni z powodów marketingowych popularyzować swoje dobre pomysły przy użyciu słowa-klucza „strukturalny”. Znani do dziś twórcy systematycznych zasad analizy i dekompozycji wymagań DeMarco, Yourdon i Constantine nazwali swoje podejście analizą strukturalną. Strukturalne programowanie i strukturalna analiza nie mają za sobą nic wspólnego, oprócz tego modnego słówka, pewnie wtedy koniecznego, aby zostać w ogóle zauważonym.



Kolejna wpadka IT: obiektowość

Języki programowania przechowują niektóre dane na tzw. stosie (ang. stack). Z punktu widzenia programisty oznacza to, że dane i funkcje, zadeklarowane wewnątrz jednej funkcji, przestają istnieć, gdy się tę funkcję opuści.

Trudno to zrozumieć? To znakomicie, ponieważ to właśnie chcę pokazać, że słynne w latach 80. i 90. podejście obiektowe tak naprawdę powstało jako technologia o wiele wcześniej i jako najzupełniej hackerskie rozwiązanie: pewien typ danych (obiekty) kompilator języka umieszczał na stercie (ang. heap) zamiast na stosie, dzięki czemu stały się możliwe pewne ciekawe i praktyczne rozwiązania: klasy, dziedziczenie. Takie podejście jego twórcy (Nygaard, Dahl) nazwali obiektowym.

Rozwiązanie było dobre, ale przecież totalnie niezrozumiałe dla biznesu, i nastąpiło kolejne szaleństwo: słowo „obiektowe” zaczęło znaczyć „dobre i nowoczesne”, tworzono absurdalne i fantastyczne teorie o rzekomej zgodności obiektowego modelowania świata z poznawczymi mechanizmami psychiki człowieka. Pojawiła się plejada „obiektowych” metod: analizy i projektowania, dobrych lub złych, ale niemających nic wspólnego z przenoszeniem danych ze stosu na stertę ani z mechanizmem dziedziczenia w obiektowych językach programowania.

Dzisiaj ta histeria minęła i pozostało po niej wiele dobrego: obiektowe języki programowania, diagramy przypadków użycia w UML, ale rzekome cudowne rozwiązania wszystkiego przez obiektowość okazało się marketingową fikcją, kolejnym błędem Arystotelesa.



Moda na agile

Zmądrzeliśmy? Ani trochę. W 1999 r. pojawił się nowatorski, kontrowersyjny pomysł, nazwany przez autorów (Beck, Cunningham) programowaniem ekstremalnym. Ten paradygmat sprawdzał się znakomicie w projektach, w których nie dało się precyzyjnych wymagań sformułować zawczasu, pod warunkiem że realizowali je programiści wysokiej klasy.

Już dwa lata później, w roku 2001, ten dobry pomysł podzielił losy swoich wcześniejszych pobratymców i poszybował w górę, w stratosferę. „Manifest agile”, zawierający skądinąd wiele mądrych pomysłów, jednocześnie pełen jest gołosłownych ogólników głoszących, że podejście zwinne jest totalnie nowym, wszechstronnie lepszym sposobem tworzenia systemów IT, nową, humanitarną filozofią informatyki. I tak jest do dzisiaj.

Słowo „zwinny” samo w sobie brzmi obiecująco, więc z łatwością zostało porwane przez marketing do roli usłużnego słowa oznaczającego coś dobrego. Nadużywane jest do granic wytrzymałości, przylepiane do czegokolwiek, co chce się promować. Sam tego doświadczyłem niedawno, kiedy prowadzony przez siebie warsztat nazwałem nie warsztatem o testowaniu, tylko o testowaniu agile. Sprzedawał się znakomicie, a ja mam zupełnie czyste sumienie, bo uczestników ani trochę nie interesowała specyfika testowania w projektach agile Scrum, lecz ogólne tematy testowania, niezmienne od 50 lat. Ale przyznawali, że szkolenie zainteresowało ich ze względu na atrakcyjną nazwę.

13614.jpg

Ludzie wierzą, że nowe znaczy lepsze i że nie ma powodu zaprzątać sobie głowę tym, co było 20 czy 40 lat temu. A jednak powód jest: w ten sposób unika się kosztownego powtarzania błędów, ulegania czarowi pseudonowości, które pod ładnym opakowaniem przemycają za duże pieniądze rzeczy znane nam od lat.

Żeby było jasne – jestem gorącym zwolennikiem paradygmatu (zrębu – ang. framework) agile, zwłaszcza agile Scrum. Ten sposób realizowania projektów jako pierwszy i jedyny dotąd na świecie zdołał – przynajmniej częściowo – zlikwidować szereg chronicznych od lat słabości projektów IT, takich jak: projektowanie testów w ostatniej chwili, lekceważenie wymagań, brane z sufitu szacunki pracochłonności, chaos niekontrolowanych zmian, zwanych czule „wrzutkami”. Przez dziesiątki lat zmianom opierali się skutecznie tak programiści, dający sobie chętnie przywilej na pełną dowolność działań, jak i biznes uważający, że mętne i nieprecyzyjne wizje biznesowe powinny się w cudowny sposób szybko zamieniać w działające oprogramowanie. Agile udało się w jakiś sposób ukrócić te praktyki, narzucić mądrą dyscyplinę tam, gdzie wcześniej – pod płaszczykiem rzekomo zdyscyplinowanych projektów tradycyjnych, sekwencyjnych, planowanych z góry – tę dyscyplinę tylko symulowano i łamano na wszelkie sposoby.

To, czym agile mnie razi, co krytykuję, to udawanie, że jest czymś więcej niż znakomitym sposobem realizacji projektów IT, że jest jakąś nową, lepszą filozofią, która na głowie rzekomo stawia to wszystko, co inżynieria oprogramowania dotąd stworzyła. Szczególnie jaskrawym wyrazem tego szaleństwa jest zupełnie niepotrzebna własna terminologia, dziwaczne nazewnictwo, utrudniające porozumienie i tworzące fałszywe wrażenie istotnej odmienności. Ten stan rzeczy ma dwie wady i jedną zasadniczą zaletę. Wady to, po pierwsze, utrudnienie korzystania przez agile z dorobku inżynierii oprogramowania oraz, po drugie, utrudnienie dostrzeżenia przez klasyczną inżynierię oprogramowania znakomitych zalet agile. Zaleta to możliwość stworzenia i sprzedaży tych samych książek, tych samych szkoleń, tych samych metod po raz drugi, z dodatkiem magicznego słowa „agile”. Testowanie agile to w 85% testowanie takie samo jak każde inne, plus 15% specyfiki procesów agile, ale książka pod tym tytułem liczy sobie nie 50, a 350 stron i omawia wszystkie zagadnienia od początku, udając, że opisuje coś zupełniej nowego. Niezły biznes…



Kult eksploracji

Podobnie rzecz ma się z testowaniem eksploracyjnym. Dobry pomysł, dobra metoda, którą niektórzy zwolennicy przerobili na niemal religię, mimochodem – chcę wierzyć, że nieświadomie – stwarzając zapotrzebowanie na swoje niezbyt tanie usługi doradcze i szkoleniowe, rzekomo o niebo lepsze od innych, „tradycyjnych”.

Wprawdzie opisane przeze mnie zjawiska podważają inżyniersko-informatyczny racjonalizm, ale jeśli ulegniemy jakiejś chwilowej fascynacji modnymi bzdurami, pocieszmy się: konkurencja popełni identyczne błędy.

Natomiast jeśli chcemy być od konkurencji dużo lepsi, trzeba pamiętać o zagrożeniu błędem Arystotelesa, nie szukać tanich pocieszeń i kierować się własnym rozumem, a nie modą ani połyskliwym marketingiem idei.

comments powered by Disqus