Jeśli zdarzyło ci się uczęszczać do polskiego liceum, prawdopodobnie rozpoznajesz poniższy schemat.

To rysunek znany pod nazwą “sinusoidy Krzyżanowskiego”, od nazwiska Juliana Krzyżanowskiego. Założenie sinusoidy jest takie, że pokazuje progresję epok historycznych i literackich poprzez ich podejście do szeroko rozumianego rozumu. Epoki nad linią są “jasne”, bliższe ziemi, materii, rozumowi i humanizmowi; podczas gdy epoki poniżej linii są “ciemne”, bardziej efemeryczne, powiązne z religią, emocjami i dekadencją. Sinusoida ma za zadanie pokazać jak ludzka myśl w skali cywilizacyjnej opiera się na kontraście w sztuce, literaturze i filozofii.

Niestety, o ile brzmi to bardzo jasno i uporządkowanie, sinusoida jest w dużej mierze bezsensowna, jest klasycznym przykładem dobierania faktów pod tezę.

Pomimo tego, w przeciwieństwie do wielu innych rzeczy pakowanym młodzieży do głów w szkołach, nie jest kompletnie bez sensu. Istnieje ziarno prawdy w podziale między racjonalnym a nieracjonalnym. Jednakże te terminy są niepotrzebnie tendencyjne. W społeczeńswie przesiąkniętym galopującym scjentyzmem przyszło, niestety, do cechowania irracjonalizmu negatywnie, a racjonalizmu pozytywnie. Te terminy powinny zostać zmienione.

Kupno samochodu

Potencjalne rozwiązanie tego problemu możemy znaleźc w rozdziale 6. Zen i sztuki oporządzania motocykla. Jednym z centralnych motywów filozofii Pirsiga i jednym z pierwszych które prezentuje jest kontrast między tym co nazywa “klasycznym” i “romantycznym” podejściem do rozumienia świata.

W wymiarze klasycznym świat odbierany jest przede wszystkim jako obiektywna forma sama w sobie. W wymiarze romantycznym jest on odbierany przede wszystkim jako bezpośredni fenomen.

Ta dychotomia zdaje się przecinać niemal całe ludzkie doświadczenie, ale jest najbardziej widoczna i najczęściej spotykana kiedy dochodzi do interakcji z technologią. Na co zwracasz uwagę, kiedy zastanawiasz sie jaki samochód kupić? Niektórzy mówią o niskim spalaniu, tanich częściach zamiennych, niskim przebiegu. Inni wybiorą samochód który widzieli w filmie lub grze komputerowej, kiedy zechcą kupić swoje pierwsze auto.

Ja należę do tej drugiej grupy. Pierwsze “prawdziwe” auto które miałem to Mitsubishi Eclipse, które wybrałem tylko dlatego, że wyglądało fajnie i wydawało się szybkie, pomimo tego, że wcale takie nie było. Kiedy przeszukiwałem ogłoszenia w internecie, niespecjalnie interesowały mnie szczegóły techniczne—rozglądałems ię za samochodami, które występowały w którejś z części Need for Speed w które grałem za dzieciaka.

Oh, ale jak dobrze się jeździło tym Eclipsem. Teraz, kiedy to piszę, jest już w innych rękach, a ja przesidłem się na stare Volvo—jedno z tych starych Volvo, które nigdy się nie psuje. Podoba mi się jak to Volvo działa, jest ciche i wygodne, części są tanie, diesel mało pali… Ale nie wygląda jak Eclipse, i, co ważniejsze, nie jeździ się nim jak Eclipsem. Jest… nudne.

To jest prawdziwy podział między klasycznym a romantycznym umysłem. Klasyk interesuje się tym jak coś działa, podczas gdy romantyk interesuje się tym, jak coś się odczuwa. To też prowadzi do pewnych różnic w podejściu do techniki.

Klasycznie zorientowana osoba jest technofilem. Chce zrozumieć maszynę, techniczne szczegóły jej działania, jak wszystkie części do siebie pasują i jak ją naprawić kiedy coś się zepsuje. Myśl klasyczna dała nam logikę, matematykę, racjonalizm i metodę naukową. Jest zbudowana na hierarchii faktów, które same w sobie są zbudowane na podobnej hierarchii, aż do samego dołu, do fundamentalnych aksjomatów wszechświata.

Z rugiej strony, romantycznie zorientowana osoba jest naturalnie technofobem. Jedno z praw Clarke’a mówi, że każda wystarczająco zaawansowana technologia jest nierozróżnialna od magii, a dla romantyka zrozumienie technologii jest okradaniem jej z jej magii, podkopywaniem jej piękna. Co jest uważane za zaletę przez klasyków bywa wadą dla romantyków.

Programiści-romantycy

Skoro programowanie jest nierozerwalnie zestawione z technologią, można by się spodziewać, że romantyczne nastawienie jest zupełnie niekompatybilne z tym powołaniem. Jednakże, wydaje mi się że ze wzrostem popularności wysokoopziomowych języków programowania, ich maszyn wirtualnych które działają niezależnie od sprzętu na jakim są uruchomione, a nawet bardziej w erze dużych modeli językowych używanych do pisania kodu, programowanie stało się o wiele bardziej oddzielone od technologii. Nie stało się do końca sztuką, ale rozumiane wysokopoziomowy nie jest też w zupełności naukowe. Manifest “software craftsmanship” wydaje się to tylko potwierdzać.

Niemniej, jest to trudne pole dla romantyków. Klasycznych programisitów jest tak wielu, że od romantyków oczekuje się zupełnego przyjęcia klasycznych wartości, podczas gdy nie zawsze działa to tak samo w drógą stronę. Tego się od nas oczekuje: klasyczne oprogramowanie ma być kuloodporne i działać bez problemu, bez bugów i bez zająknięć.

Ze smutkiem natomiast zauważam, że wśród moich kolegów wartość oprogramowania, które jest odczuwalnie przyjemne w użyciu oraz rozwijaniu jest często zupełnie drugorzędna. Kładziemy znacznie mniejszy nacisk na software, którego dobrze się używa.

A przecież jedno nie wyklucza drugiego. Oczywiście, mając do wyboru aplikację która działa, ale nie da się jej używać; lub aplikację której używa się dobrze ale nie działa—żaden to wybór! Obie są nic niewarte. Jednakże, mając już na tapecie aplikację która dobrze działa, ale używanie jej jest toporne, być może więcej wartości będzie miało skupienie się na doświadczeniu zamiast na działaniu. A odpowiedni balans między jednym a drugim oznacza prawdziwą jakość.

I co jest ważne, to że nie powinniśmy szukać jakości jedynie w tym, jak oprogramowanie jest używane, ale jak oprogramowanie jest rozwijane—chcemy mieć odporną, przetestowaną i modularną bazę kodu, która działa dobrze, ponieważ jest również przyjemna w rozwoju. I wydaje się, że również rozumiemy, że zbyt sztywne ograniczenia też nie są dobre—zauważamy, że jeśli zmiana jednej linii kodu produkcyjnego wymaga aktualizacji kilkunastu plików z testami, to coś poszło nie tak.

Ostatecznie jednak sądzę, że ważne jest, abyśmy mieli tę dychotomię na uwadze przy decydowaniu o składzie zespołu. Czyjaś szczególna skłonność nie powinna być wymówką do pisania złego oprogramowania, czy to byłoby oprogramowanie, które działa słabo lub jest nieprzyjemne w użyciu, ale raczej powinna być wykorzystana do udoskonalania istniejących projektów, aby doprowadzić je do najwyższych poziomów jakości.