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, młody i ambitny, 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.

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.