Z zainteresowaniem przeczytałem niedawny artykuł o programowaniu intencjonalnym (Jakub Chabik Przewężenie cyfrowego rogu obfitości - CW nr 22/2004), żałując, że metody te nie zostały przeobrażone w praktyczne możliwości. Automatyzacja przechodzenia z poziomu konceptualnego do fizycznej realizacji bez konieczności żmudnego kodowania jest czymś, co jakże usprawniłoby proces wytwórczy.

Na razie obraz informatyki psuje właśnie etap pośredni, czyli czasochłonne przekuwanie myśli na algorytmy. Jeszcze bardziej jednak dobre imię informatyki szkalują niektórzy odbiorcy rozwiązań, którzy nadal nie potrafią określić czego właściwie oczekują.

Kodowanie jest niezbędnym obecnie etapem wytwarzania oprogramowania i, co nie chce pomieścić się w głowach niektórych menedżerów, także kosztownym. Dlaczego tak jest, doskonale o tym wiemy, z wyjątkiem tych, którzy nie wiedzą. Jak brzemienne w skutki (czasowe i finansowe) są zmiany w projekcie w późniejszych fazach jego realizacji, miał okazję przekonać się niejeden z uczestników tego spektaklu, by czasami nie powiedzieć, cyrku.

Ostatnio miałem sposobność obserwować taką oto zawieruchę. Zamówiono wykonanie oprogramowania, które w zamyśle władz firmy miało się integrować z istniejącymi już modułami. A miało to polegać na tym, że użytkownik klika "magiczny przycisk" i dane są przelewane z jednej bazy do drugiej. Tak błaho wyglądało to z menedżerskiego punktu widzenia. Z poziomu wykonawczego z kolei sprawa nie była aż tak trywialna - jak zwykle zresztą (ale niespodzianka, nieprawdaż?). W założeniach, nakreślonych przez decydentów przy zupełnym pominięciu w tej fazie eksperckiej roli informatyków, pomylono interfejsy i dane były w efekcie przekazywane do innego podsystemu. Po oddaniu produktu do użytku darmo oczekiwano, aż dane pojawią się tam, gdzie myślano, że się pojawią. Może by się i pojawiły, gdyby autorzy rozwiązania zostali o tym uprzednio poinformowani. Nieprawdą jednak jest, że pomylono się aż tak bardzo i głupio. Pomylono się jeszcze bardziej i jeszcze głupiej. Menedżerowie przekonani o prostocie sprawy i swojej nieomylności, zachłysnąwszy się swą mocą decyzyjną, zlekceważyli zupełnie konieczność współuczestnictwa informatyków zakładowych w opracowywaniu wytycznych do projektu.

Magiczne zaklęcia w stylu "niech się stanie" nie na wiele były przydatne. Nieodzownie trzeba było odwołać się do wiedzy i kompetencji informatyków zakładowych, którzy bądź co bądź wiedzą co w trawie piszczy i jakie procesy zachodzą w firmowym systemie informatycznym. Ku ogromnemu rozczarowaniu decydentów okazało się, że sama graficzna implementacja przycisku wyzwalającego transport danych nie wystarczy, bowiem trzeba opracować wspólny format wymiany informacji. No i tu zaczęło się piekło, gdyż nowy produkt operował na zupełnie innych strukturach aniżeli docelowa baza danych.

Założenia dla spójnego systemu zawsze będą niewłaściwe, jeżeli określają je osoby stawiające znak równości pomiędzy strukturą danych a ich ilością, kolorytem plansz na ekranie a ich przeznaczeniem, wiedzą fachową a dyletanctwem. Pieniądze i władza nie czynią z nikogo ani mędrca, ani fachowca.

Widzę w takich okolicznościach ogromne możliwości dla programowania intencjonalnego, pod warunkiem jednak, że odbiorcy będą w stanie swoje intencje w jakiś sposób przedłożyć. A najlepiej, gdyby powstała jeszcze warstwa pośrednia tłumacząca niezrozumiałe intencje pomysłodawców na intencje właściwe, ale tu już zahaczamy o parapsychologię.