Specyfik(a)cja
Bogusław Jackowski

Trudno cytat wyobrazić sobie inżyniera, który najpierw buduje most, a dopiero potem sporządza projekt i to niechlujny. W inżynierii oprogramowania takie podejście jest nagminne. Nie chodzi mi o informatykę teoretycznie stosowaną, ale o tę, z którą przychodzi mi się borykać od lat bez mała trzydziestu. Teoretycy informatyki bowiem zawsze nalegali na kolejność: wpierw specyfikacja, potem realizacja. Praktycy nie tylko zmienili kolejność, ale wręcz uznali pierwszy etap za zbędny – po co komu specyfikacja, i dokumentacja? Program ma działać i już.

Jest to bardzo wygodny dla twórcy sposób specyfikowania, gdyż dzięki temu programy z definicji pozbawione są błędów. Program nie działa źle, ale co najwyżej „zaskakująco” lub „nieintuicyjnie”.

Znam jeden jedyny przypadek sensownego zastosowania takiego podejścia. Prof. Donald E. Knuth z Uniwersytetu Stanforda zdecydował (http://www-cs-faculty.Stanford.Edu/~knuth/abcde.html), że stworzone przezeń programy do składu tekstu i tworzenia fontów, TeX i Metafont, mają być po jego śmierci uznane za bezbłędne i pozostawione bez zmian. Oby żył jak najdłużej, zwłaszcza że póki żyje, zobowiązał się do usuwania błędów, rozumianych jako odstępstwa od niezwykle starannej specyfikacji. Mało tego, mimo iż oba programy są dostępne bezpłatnie, każdy kto wskaże błąd, ma obiecany u prof. Knutha czek. Prof. Knuth z obietnicy się wywiązuje – wiem to, bo sam jestem szczęśliwym posiadaczem paru czeków.

Złośliwie można by zastosować retorsio argumenti i stwierdzić, że istnienie błędów w TeX-u czy Metafoncie świadczy o tym, że specyfikacja niewiele pomogła. Każdemu bym życzył pracy z systemami tak gruntownie odpluskwionymi jak TeX i Metafont – „przetrzepało” je tysiące ludzi na całym świecie i szansa na to, by zarobić kolejny czek u prof. Knutha jest obecnie znikoma.

Idealnie bezbłędnych systemów po prostu nie ma. Ale zbyt duża liczba błędów powoduje, że systemy stają się irytująco niewygodne w obsłudze. W większości przypadków widać jak na dłoni, że źródłem zapluskwienia jest tworzenie oprogramowania na oślep, bez uprzedniego projektu. Nie dam sobie wmówić, że na przykład zamykanie systemu poprzez wejście do menu start mogło powstać jako efekt starannych przemyśleń.

Potrzeba specyfikacji dotyczy nie tylko programów, ale także danych, z których programy korzystają. Większość firm utajnia format danych, aczkolwiek są wyjątki, np. cieszący się coraz większą popularnością format prezentacji graficznych SWF. Można dyskutować, czy utajnianie ma sens, ale nie można tego prywatnym firmom zabronić.

Uważam natomiast za niedopuszczalne, by jawnej specyfikacji pozbawione były publiczne dokumenty elektroniczne, a tak jest w przypadku niesławnych formularzy ZUS-owskich. Niestety, przyzwyczajenie i urzędników, i – co gorsza – informatyków do braku specyfikacji prowadzi do tego, że usprawnianie życia za pomocą komputeryzacji staje się fikcją. Specyfikcją.