Trudno wyobrazi/c sobie in/zyniera, kt/ory najpierw buduje most, a dopiero potem sporz/adza projekt i to niechlujny. W in/zynierii oprogramowania takie podej/scie jest nagminne. Nie chodzi mi o informatyk/e teoretycznie stosowan/a, ale o t/e, z kt/or/a przychodzi mi si/e boryka/c od lat bez ma/la trzydziestu. Teoretycy informatyki bowiem zawsze nalegali na kolejno/s/c: wpierw specyfikacja, potem realizacja. Praktycy nie tylko zmienili kolejno/s/c, ale wr/ecz uznali pierwszy etap za zb/edny -- po co komu specyfikacja, i dokumentacja? Program ma dzia/la/c i ju/z.
Jest to bardzo wygodny dla tw/orcy spos/ob specyfikowania, gdy/z dzi/eki temu programy z definicji pozbawione s/a b/l/ed/ow. Program nie dzia/la /xle, ale co najwy/zej ,,zaskakuj/aco'' lub ,,nieintuicyjnie''.
Znam jeden jedyny przypadek sensownego zastosowania takiego podej/scia. Prof. Donald E. Knuth z Uniwersytetu Stanforda zdecydowa/l (http://www-cs-faculty.Stanford.Edu/~knuth/abcde.html), /ze stworzone przeze/n programy do sk/ladu tekstu i tworzenia font/ow, TeX i Metafont, maj/a by/c po jego /smierci uznane za bezb/l/edne i pozostawione bez zmian. Oby /zy/l jak najd/lu/zej, zw/laszcza /ze p/oki /zyje, zobowi/aza/l si/e do usuwania b/l/ed/ow, rozumianych jako odst/epstwa od niezwykle starannej specyfikacji. Ma/lo tego, mimo i/z oba programy s/a dost/epne bezp/latnie, ka/zdy kto wska/ze b/l/ad, ma obiecany u prof. Knutha czek. Prof. Knuth z obietnicy si/e wywi/azuje -- wiem to, bo sam jestem szcz/e/sliwym posiadaczem paru czek/ow.
Z/lo/sliwie mo/zna by zastosowa/c retorsio argumenti i stwierdzi/c, /ze istnienie b/l/ed/ow w TeX-u czy Metafoncie /swiadczy o tym, /ze specyfikacja niewiele pomog/la. Ka/zdemu bym /zyczy/l pracy z systemami tak gruntownie odpluskwionymi jak TeX i Metafont -- ,,przetrzepa/lo'' je tysi/ace ludzi na ca/lym /swiecie i szansa na to, by zarobi/c kolejny czek u prof. Knutha jest obecnie znikoma.
Idealnie bezb/l/ednych system/ow po prostu nie ma. Ale zbyt du/za liczba b/l/ed/ow powoduje, /ze systemy staj/a si/e irytuj/aco niewygodne w obs/ludze. W wi/ekszo/sci przypadk/ow wida/c jak na d/loni, /ze /xr/od/lem zapluskwienia jest tworzenie oprogramowania na o/slep, bez uprzedniego projektu. Nie dam sobie wm/owi/c, /ze na przyk/lad zamykanie systemu poprzez wej/scie do menu start mog/lo powsta/c jako efekt starannych przemy/sle/n.
Potrzeba specyfikacji dotyczy nie tylko program/ow, ale tak/ze danych, z kt/orych programy korzystaj/a. Wi/ekszo/s/c firm utajnia format danych, aczkolwiek s/a wyj/atki, np. ciesz/acy si/e coraz wi/eksz/a popularno/sci/a format prezentacji graficznych SWF. Mo/zna dyskutowa/c, czy utajnianie ma sens, ale nie mo/zna tego prywatnym firmom zabroni/c.
Uwa/zam natomiast za niedopuszczalne, by jawnej specyfikacji pozbawione by/ly publiczne dokumenty elektroniczne, a tak jest w przypadku nies/lawnych formularzy ZUS-owskich. Niestety, przyzwyczajenie i urz/ednik/ow, i -- co gorsza -- informatyk/ow do braku specyfikacji prowadzi do tego, /ze usprawnianie /zycia za pomoc/a komputeryzacji staje si/e fikcj/a. Specyfikcj/a.