Słowem, bez przepisania nieomal w całości istniejącego oprogramowania, poczynając od systemów operacyjnych, poprzez środowiska aplikacyjne i bazodanowe, aż po przeglądarki internetowe (które, nawiasem mówiąc, coraz bardziej przypominają system operacyjny) nie będzie możliwy dalszy, szybki przyrost funkcjonalności aplikacji. Programowanie trafiło więc na barierę technologiczną, której przezwyciężenie potrwa na pewno lata, a być może dekady.

Rozproszenie

Podobne są konsekwencje innej fundamentalnej zmiany: Internetu. W świecie usług internetowych trwa w najlepsze "ucieranie się" standardów interoperacyjności i wymiany danych. Coraz mniej aplikacji stanowi jednolitą, autonomiczną całość, zdolną funkcjonować na "informacyjnej wyspie" komputera wyposażonego w system operacyjny, urządzenia peryferyjne i nic więcej. Korzystanie z danych, a także usług dostępnych w tzw. chmurze, to już codzienność programisty.

O ile wcześniej aplikacje cechowało duże ryzyko zmienności i niestabilności poszczególnych elementów (bibliotek), o tyle w Internecie jest ono spotęgowane wielokrotnie. "Wiszący wskaźnik" (dangling pointer), zmora programistów sprzed 20 lat, w sieci nabiera nowego znaczenia. Taki wskaźnik (w dzisiejszych realiach: URI albo URL) wskazuje zasoby, które mogą być w danej chwili niedostępne (z powodów technicznych lub bezpieczeństwa), działać wolno albo akurat zmienić interfejs.

Aplikacje internetowe mają jeszcze jeden problem związany z ich architekturą: przechowywanie stanu. W dzisiejszych realiach większość aplikacji webowych działa bezstanowo; tj. po stronie klienta musi być zachowana pełna informacja o stanie aplikacji pomiędzy poszczególnymi wywołaniami, tak jakby każde pochodziło od kogoś innego. W praktyce komercyjnych zastosowań jest to trudne lub wręcz niemożliwe, m.in. ze względów bezpieczeństwa. Bring back state to web applications - apeluje sam Martin Fowler, autor niezliczonej ilości książek o inżynierii oprogramowania.

Trzeba jednak powiedzieć, że generalnie tworzenie aplikacji webowych jest dziś prostsze niż kiedykolwiek wcześniej. Prostota narzędzi i mnogość osób dysponujących podstawowymi umiejętnościami tworzenia w środowiskach takich jak Perl, PHP, MySQL czy Ruby (często w wieku gimnazjalnym) może być źródłem dość dużego spokoju ducha dla przedsiębiorców jutra: programistów nie zabraknie. Natomiast budowa rozwiązań na tyle dojrzałych, by integrowały rozwiązania z "chmury" w aplikacje w sposób inteligentny, stabilny, skalowalny i łatwy w utrzymaniu, to cała dziedzina sztuki, która więcej ma wszakże wspólnego z zarządzaniem architekturą niż działalnością typowo programistyczną. Znajomość architektury aplikacji internetowych, wzorców (patterns) architektonicznych i projektowych oraz umiejętność ich stosowania w konkretnych sytuacjach na pewno będzie jedną z kluczowych kompetencji programistów jutra.

Środowiska i narzędzia

Wyzwania programowania AD 2010 i nadchodzących lat leżą w środowiskach i narzędziach. Chyba nikt już nie szuka tzw. srebrnej kuli, czyli języka (środowiska), które rozwiąże wszystkie problemy i w sposób magiczny pozwoli dostarczać dobre oprogramowanie, w przewidywanym czasie, z zadaną jakością i za rozsądne pieniądze. Wiarą w istnienie takiego narzędzia zdominowane były przede wszystkim lata 90., kiedy to kolejne pojawiające się języki i metodyki obiecywały przełom i przezwyciężenie kryzysu inżynierii oprogramowania. Trafnie porównywano ten czas do nieskutecznych starań średniowiecznych alchemików, by uzyskać kamień filozoficzny.

Dziś, jak mówi Anders Hejlsberg (niegdyś główny architekt firmy Borland, a później autor języka C), zasadniczym wyzwaniem programowania jest programowanie imperatywne vs deklaratywne. W programowaniu imperatywnym autor aplikacji musi maszynie powiedzieć, jak dana funkcjonalność ma być zrealizowana; w deklaratywnym - co powinno być efektem. Typowym przykładem języka deklaratywnego wczesnej generacji jest SQL, który opisuje, jakie dane, z jakich źródeł i jak pogrupowane ma dostarczyć baza. Jej motor ma sam znaleźć optymalny algorytm.