Jeszcze niedawno określenie "programista" było na tyle pojemne, że mogło obejmować znaczną część kadry przedsiębiorstw informatycznych. Każdy, kto zajmował się tworzeniem programów komputerowych, mógł określić siebie w ten sposób. W miarę dojrzewania inżynierii programowania Świat ten dzieli się na wyraźne grupy. Spróbujmy je zidentyfikować, nazwać i scharakteryzować, aby wiedzieć co tak naprawdę słowo "programista" będzie znaczyło jutro.

Świat inżynierii oprogramowania na początku lat dziewięćdziesiątych wstrząsany był wieloma fundamentalnymi dyskusjami. W najlepsze trwała rewolucja mikrokomputerowa, Internet dopiero powstawał, a przedsiębiorstwa stawały w obliczu konieczności budowy coraz bardziej skomplikowanych systemów.

Narzędzia, wcześniej używane do budowy systemów o znacznie mniejszej złożoności, nie przystawały do wyzwań "czasu burzy i naporu". Szerokie rzesze informatyków zdały sobie sprawę, że proces tworzenia systemu informatycznego powinien zawierać gruntowną analizę wymagań, projekt struktury i warstwy komunikacyjnej systemu, a dopiero efektem tych faz powinno być implementowanie programu. Pojawiły się metodyki analizy i projektowania. W pewnym momencie, około roku 1993 było ich ponad trzydzieści. Zwolennicy każdej metodyki toczyli z sobą zażarte spory niczym członkowie odłamów religijnych. Analogia ta wydaje się o tyle adekwatna, że każda ze zwalczających się grup miała swoją "świętą księgę" (zawierającą notację, opis metody i jej zastosowania), swojego guru, swoje czasopisma i konferencje.

Przełom nastąpił, gdy trzech przywódców trzech takich "sekt" - Grady Booch, Ivar Jacobson i James Rumbaugh - połączyło siły w firmie Rational, a efektem ich wspólnych działań była notacja Unified Modelling Language (UML) i metodyka Unified Modelling Process. I choć krytycy wytykają im słabą spójność i niedostateczne umocowanie formalne, to UML stał się standardem de facto i zakończył erę wojen religijnych w inżynierii oprogramowania.

Srebrna kula na kryzys

Tymczasem narastał kryzys inżynierii oprogramowania (software crisis). Ogromna większość projektów informatycznych kończyła się - i nadal się kończy - porażką definiowaną jako przekroczenie czasu albo budżetu, a najczęściej jednego i drugiego. Najlepszym przykładem z rodzimego podwórka są wielkie projekty informatyczne zlecane przez instytucje publiczne, które powstają z opóźnieniem i działają źle albo wcale - i częściowo tylko jest to zawinione brakiem kompetencji i nieuczciwością decydentów, a częściowo właśnie kryzysem inżynierii oprogramowania.

Wysiłki informatyków do niedawna skupiały się na znalezieniu "srebrnej kuli". Zgodnie ze starą legendą, wilkołaka można pokonać jedynie strzelając do niego kulą wykonaną ze srebra. Wilkołaka symbolizującego kryzys inżynierii oprogramowania pokonać miała taka informatyczna "srebrna kula" - nowe narzędzie, technologia, język programowania, metodyka albo praktyka organizacyjna. Miała pokonać ten kryzys raz na zawsze, zapewniając, że programy będzie się konstruować tak jak drogi i mosty - zgodnie ze standardami, w przewidywalnym czasie i z gwarantowaną jakością. Wystarczy ją odkryć, a świat stanie się prosty i piękny: obiecywali prorocy "srebrnej kuli".

Praktyka dowiodła, że tak rozumiana "srebrna kula" nie istnieje. Można natomiast przezwyciężyć kryzys "pracą organiczną". Uwaga poświęcana projektowi systemu, staranna implementa- cja, gruntowne testowanie i racjonalne zarządzanie procesem informatycznym przez doświadczonych praktyków okazały się najlepszym lekarstwem na chaos. W drugiej połowie lat dziewięćdziesiątych pojawiły się publikacje na ten temat, a - co najważniejsze - również wykształcone kadry, umiejące zarządzać procesem inżynierii oprogramowania w sposób skuteczny i nowoczesny. I choć trudno jeszcze mówić o przezwyciężeniu kryzysu, to ostatnie dane (opublikowane przez Dataquest i Gartner Group) dowodzą, że coraz lepiej radzimy sobie z tworzeniem oprogramowania i spontaniczny chaos ustępuje miejsca precyzji i racjonalności.