Przyszłość IT tworzą geniusze

Pomysły Adama nigdy nie szły za aktualną, hałaśliwą modą w IT. Wręcz przeciwnie - nie zawsze są dziś doceniane, bowiem dotyczą kształtu tego, co modą będzie dopiero za... 10-15 lat.

Dawno, dawno temu, kiedy nie było jeszcze inżynierii oprogramowania ani IT, ani nie znano nawet - o zgrozo! - PRINCE 2 ani ITIL, oprogramowanie tworzyli nobliści albo tacy, co w tym kierunku dążyli. Minęły dziesięciolecia, lampy elektronowe zostały zastąpione przez tranzystory, a te z kolei przez układy scalone i dzisiaj przeciętny telefon komórkowy, a nawet pralka automatyczna z górnej półki ma większą moc obliczeniową niż wypełniający wielkie pomieszczenia elektryczny potwór "Eniac" w 1946 r. Zmieniały się też sposoby produkcji programów: od pisania wprost kodu maszyny (lata 40.), przez asembler (50.), FORTRAN (1955), Algol (1959), C (wczesne lata 70.), C++ (1980), Javę (1995), po Visual Basic i .NET (2001).

Specjaliści od telekomunikacji, od architektury mikroprocesorów, od systemów operacyjnych opisaliby jeszcze inne takie ewolucje i towarzyszące im minirewolucje (czasem pozorne), ale przemiana podstawowa, najważniejsza i mająca największe znaczenie, to fakt, że informatyka zmieniła się z dyscypliny akademickiej oraz rozrywki nielicznych geniuszy matematycznych w powszechny przemysł informatyczny, którego wielusetmilionowa armia pracowników tworzy i współtworzy produkty wykorzystywane przez wielomiliardową rzeszę mieszkańców Ziemi.

Tylu geniuszy nie ma na świecie, więc programy muszą pisać, konfigurować, utrzymywać i budować na nowo zwykli śmiertelnicy. Muszą, co jeszcze trudniejsze, robić to i szybko, i skutecznie, i niezawodnie. Nawet geniusze współczesnego IT nie są już geniuszami informatyki ani matematyki, lecz wzornictwa (np. Steve Jobs), świetnego marketingu niezbyt oryginalnych pomysłów (np. Zuckerberg) albo projektowania pod kątem potrzeb klienta (twórcy Google).

Okopy opuszczane przez geniuszy szybko zajęli biurokraci. Skoro projekty informatyczne są zawiłe i czasem - często! - kończą się niepowodzeniem, to trzeba temu zapobiegać przy pomocy biurokratycznych narzędzi: procedur, dokumentacji, administrowania, pieczątek, podpisów i zebrań. Od dnia, kiedy po raz pierwszy użyto oficjalnie określenia "inżynieria oprogramowania" (Konferencja inżynierii oprogramowania NATO, 1968), nastąpił wysyp biurokratycznej kreatywności: ISO 9000-ISO 9001, Six Sigma, CMMI, COBIT, ITIL, TickIT, ISO/IEC 12207, Bootstrap, SPICE, ISO/IEC 15504, TMM, MMAST, TAP, TCMM, TIM, TOM, TSM, TPI, ISO 29119, PRINCE2...

Kiedy góra dokumentów rośnie, a tworzenie oprogramowania coraz mniej przypomina dawniejszą, radosną twórczość, zamieniając się w nudne administrowanie, pojawiają się też ruchy rewolucyjne, ludowe, dzieci-kwiaty IT: ekstremalne, TDD, metodyki agile, testowanie eksploracyjne...

Nie ujmując merytorycznych wartości ani podejściu biurokratycznemu, ani jego przeciwieństwu - agile’owemu powrotowi do korzeni - trudno nie ulec wrażeniu, że sprawa, o której powinny rozstrzygać przede wszystkim argumenty merytoryczne, inżynierskie, stała się polem walki stylistyki hipisowskiej ze stylistyką hierarchiczno-garniturową...