Gdyby obiektywnie popatrzeć na oprogramowanie, które tworzyłem - nawet te większe, latami rozwijane przez wiele osób systemy - to napisany kod, jakkolwiek by mierzyć jego rozmiar, jest jakimś nieszczęsnym ułamkiem całej infrastruktury. Malutkim zbiorem supełków powiązanych ponad masą narzędzi wykorzystywanych do stworzenia działającej aplikacji i do jej uruchomienia.

Bazy danych. Middleware. Serwery webowe, pocztowe, telekomunikacyjne. Języki programowania z całą swą otoczką. Frameworki. Duże i małe biblioteki pomocnicze. Cała warstwa systemowa i sieciowa. I wiele wiele innych... A przecież jeszcze narzędzia developerskie, od IDE i kompilatorów po programy graficzne i wspierające pracę w grupie.

Od dwóch miesięcy próbuję się wdrażać do GTD. Używam Nozbe do ewidencjonowania rozmaitych hobbistycznych i prywatnych zadań (od przedsięwzięć domowych po tego bloga), próbuję też korzystać z samodzielnie hostowanych Tracks do rozpisania zadań zawodowych.

Czas na wstępny bilans.

Dlaczego XML odniósł sukces?

Sporo uczonych słów na ten temat napisano, najczęściej próbując dorobić różne złożone ideologie. A tymczasem, kluczem do sukcesu XML były te same dwa czynniki, które stały za sukcesem sieci WWW:

• prostota,
• łatwa amortyzacja zmian.

A przynajmniej, to o nie chodziło w zastosowaniach, którym chcę poświęcić ten artykuł: budowaniu API komunikacyjnych, procesach wymiany danych, integracji systemów.

Projekty czysto internetowe są najczęściej planowane i budowane od góry do dołu, w spójny i jednolity sposób. Informatyka biznesowa wygląda inaczej - obrazek składany jest z kilku, kilkunastu, a bywa że i kilkudziesięciu systemów, aplikacji, modułów. Interfejs webowy (albo i parę), kilka aplikacji back-office dla różnych grup pracowników, system(y) ewidencji zgłoszeń, pakiet IVR i/lub call-centre, kanał mobilny, moduł autoryzacyjny, główna baza klientów czy towarów, komponenty wymiany danych z firmami zewnętrznymi, procedury raportujące, pakiety analityczne, podsystem windykacyjny, obsługa masowych wydruków i wysyłek, system finansowo-księgowy, oprogramowanie specjalizowanych urządzeń (od robotyki przemysłowej po bankomaty), ... Wszystko to kupowane i budowane przez lata, od wielu dostawców, a potem spinane na różne sposoby.

O specyfice tego spinania może w przyszłości troszkę popiszę, ale dziś proste wspomnienie techniczne - jak sobie dwa systemy rozmawiały. Parę lat temu to było.

Gdy jakaś duża firma lub agencja rządowa ładuje się dla rozwiązania stosunkowo skromnej potrzeby w bizantyjski, potwornie drogi projekt, kupuje najdroższe z dostępnych narzędzi (powiedzmy, największe na rynku macierze dyskowe plus klastrowe licencje AquaLogica i Oracle, by postawić stronę o firmie z rejestracją na newsletter – przejaskrawiam, ale wcale nie tak bardzo), czy nawet wywala dobry i działający system, by wdrożyć znacznie droższy i mniej przydatny – komentarzem jest zwykle charakterystyczny ruch palcami. Pewnie wzięli. Albo uzgodnili w ramach jakiejś gry wpływów i nacisków.

Zdarzają się zupełnie inne przyczyny.

Pamiętacie jeszcze aferę po pierwszej turze wyborów samorządowych w 2002 roku (to te, po których Lech Kaczyński został prezydentem Warszawy)? Wprowadzono wtedy pilotowy system informatyczny do liczenia i zbierania głosów – zapowiadany przed wyborami z charakterystyczną dla tamtych lat przesadą (tegoroczne wybory samorządowe ze względu na nowatorstwo wykorzystanych rozwiązań, są przedsięwzięciem unikatowym w skali światowej…). A system z hukiem się wywrócił, nie będąc w stanie przyjąć i przetworzyć danych.

Rzecz nie była tak naprawdę ważna, kilkudniowe opóźnienie wyników mało kogo szczególnie obeszło, prawdziwy problem mieli jedynie ludzie z komisji wyborczych – zamiast w parę godzin policzyć głosy, wysłać je i po północy iść do domu, musieli sztafetowo dyżurować przy wynikach (rekordziści bodajże do środy). Ale było tam parę ciekawych elementów.

Grywam trochę w szachy korespondencyjne (żaden tam poważny poziom, zwykła zabawa – całkiem ciekawa zresztą). Przy tej okazji, wypracowałem sobie pewną – bardzo prostą – technikę, która przydaje się i przy programowaniu.

Nazywam ją prześpij to.

Dzisiaj w kościele czytania o napominaniu. Główna interpretacja dotyczy oczywiście kwestii religijnych i etycznych ale problem dotyka całkiem mocno i mojego zawodu.

Jak powiedzieć programiście, że wybrał złe rozwiązanie, zajmuje się nie tym co trzeba, nie przestrzega zasad obowiązujących w projekcie, zapóźnia się z elementem na który wiele osób czeka, pisze niezrozumiałe dokumenty, oddaje nieprzetestowany kod, albo odwala jakąś inną kichę? Upominanie nigdy nie jest łatwe, a w tym zawodzie - gdzie wielu ludzi niepokornych, o silnym ego i dużej ambicji - tym trudniejsze.

Bjaerne Stroustrup napisał kiedyś: projektowanie i programowanie to czynności wykonywane przez ludzi, jeśli o tym zapomnisz – wszystko stracone. A dla ludzi mają znaczenie drobiazgi, nawet te obiektywnie nieistotne.

Na przykład taki prosty obrazek:

Upadła ostatnio, z niejakim hukiem, koncepcja budowy drugiej linii metra w Warszawie. Wszystkie oferty okazały się zdecydowanie za drogie. Prasa trochę popisała o drożyźnie, trochę o zmowach cenowych, ciszej o wycinaniu części oferentów z sztucznych powodów (ot, brak potwierdzonego tłumaczenia na polski dyplomu któregoś z chińskich inżynierów). Między tym wszystkim dopatrzyłem się także kwestii bardzo dobrze mi znanej z projektów informatycznych. 

Miasto zażyczyło sobie bardzo wysokich kar umownych za przekroczenie terminu zakończenia budowy. Euro 2012! A firmy oceniły ryzyko i dodały sobie te kary do ceny.