Projektowanie a badania

Styczeń 2003

(Ten artykuł pochodzi z wykładu inauguracyjnego na jesiennym spotkaniu NEPLS w 2002 roku.)

Odwiedzający ten kraj często dziwią się, że Amerykanie lubią zaczynać rozmowę od pytania „czym się zajmujesz?” Nigdy nie lubiłem tego pytania. Rzadko miałem na nie zgrabną odpowiedź. Ale myślę, że w końcu rozwiązałem problem. Teraz, gdy ktoś mnie pyta, czym się zajmuję, patrzę mu prosto w oczy i mówię: „Projektuję nowy dialekt Lispa.” Polecam tę odpowiedź każdemu, kto nie lubi być pytany, czym się zajmuje. Rozmowa natychmiast przejdzie na inne tematy.

Nie uważam, że zajmuję się badaniami nad językami programowania. Po prostu projektuję jeden, tak jak ktoś mógłby projektować budynek, krzesło lub nową czcionkę. Nie próbuję odkryć niczego nowego. Chcę tylko stworzyć język, w którym dobrze się programuje. Pod pewnymi względami to założenie znacznie ułatwia życie.

Różnica między projektowaniem a badaniami wydaje się być kwestią nowego kontra dobrego. Projektowanie nie musi być nowe, ale musi być dobre. Badania nie muszą być dobre, ale muszą być nowe. Myślę, że te dwie ścieżki zbiegają się na szczycie: najlepszy projekt przewyższa swoich poprzedników, wykorzystując nowe idee, a najlepsze badania rozwiązują problemy, które są nie tylko nowe, ale faktycznie warte rozwiązania. Ostatecznie dążymy do tego samego celu, tylko podchodzimy do niego z różnych kierunków.

To, o czym dziś będę mówił, to jak wygląda twój cel od tyłu. Co robisz inaczej, gdy traktujesz języki programowania jako problem projektowy, a nie temat badawczy?

Największa różnica polega na tym, że bardziej skupiasz się na użytkowniku. Projektowanie zaczyna się od pytania, dla kogo to jest i czego użytkownik potrzebuje? Dobry architekt na przykład nie zaczyna od stworzenia projektu, który następnie narzuca użytkownikom, ale od zbadania zamierzonych użytkowników i ustalenia, czego potrzebują.

Zauważ, że powiedziałem „czego potrzebują”, a nie „czego chcą”. Nie chcę sugerować, że praca jako projektant oznacza pracę jako kucharz na zamówienie, robiący cokolwiek powie klient. W sztuce różni się to w zależności od dziedziny, ale nie sądzę, aby istniała dziedzina, w której najlepsza praca jest wykonywana przez ludzi, którzy po prostu robią dokładnie to, co mówią im klienci.

Klient zawsze ma rację w tym sensie, że miarą dobrego projektu jest to, jak dobrze działa dla użytkownika. Jeśli napiszesz powieść, która nudzi wszystkich, lub krzesło, na którym siedzi się okropnie niewygodnie, to po prostu wykonałeś złą robotę. Nie ma obrony w mówieniu, że powieść lub krzesło zostały zaprojektowane zgodnie z najbardziej zaawansowanymi zasadami teoretycznymi.

A jednak, robienie tego, co działa dla użytkownika, nie oznacza po prostu robienia tego, co użytkownik mówi. Użytkownicy nie wiedzą, jakie są wszystkie opcje i często mylą się co do tego, czego naprawdę chcą.

Odpowiedzią na paradoks, jak sądzę, jest to, że musisz projektować dla użytkownika, ale musisz projektować to, czego użytkownik potrzebuje, a nie tylko to, co mówi, że chce. To trochę jak bycie lekarzem. Nie możesz po prostu leczyć objawów pacjenta. Kiedy pacjent mówi ci o swoich objawach, musisz dowiedzieć się, co mu faktycznie dolega i to leczyć.

To skupienie na użytkowniku jest rodzajem aksjomatu, z którego można wyprowadzić większość praktyki dobrego projektowania i wokół którego koncentruje się większość problemów projektowych.

Jeśli dobry projekt musi robić to, czego potrzebuje użytkownik, kim jest użytkownik? Kiedy mówię, że projekt musi być dla użytkowników, nie chcę sugerować, że dobry projekt celuje w jakiś najniższy wspólny mianownik. Możesz wybrać dowolną grupę użytkowników. Jeśli projektujesz narzędzie, na przykład, możesz zaprojektować je dla każdego, od początkujących po ekspertów, a to, co jest dobrym projektem dla jednej grupy, może być złe dla innej. Chodzi o to, że musisz wybrać jakąś grupę użytkowników. Nie sądzę, aby można było mówić o dobrym lub złym projekcie, chyba że w odniesieniu do jakiegoś zamierzonego użytkownika.

Najprawdopodobniej uzyskasz dobry projekt, jeśli zamierzeni użytkownicy będą obejmować samego projektanta. Kiedy projektujesz coś dla grupy, która cię nie obejmuje, zazwyczaj jest to dla ludzi, których uważasz za mniej wyrafinowanych niż ty, a nie bardziej wyrafinowanych.

To jest problem, ponieważ patrzenie z góry na użytkownika, choćby życzliwie, wydaje się nieuchronnie korumpować projektanta. Podejrzewam, że bardzo niewiele projektów mieszkaniowych w USA zostało zaprojektowanych przez architektów, którzy spodziewali się w nich mieszkać. To samo można zaobserwować w językach programowania. C, Lisp i Smalltalk zostały stworzone dla ich własnych projektantów. Cobol, Ada i Java zostały stworzone dla innych ludzi.

Jeśli myślisz, że projektujesz coś dla idiotów, to prawdopodobnie nie projektujesz czegoś dobrego, nawet dla idiotów.

Nawet jeśli projektujesz coś dla najbardziej wyrafinowanych użytkowników, nadal projektujesz dla ludzi. W badaniach jest inaczej. W matematyce nie wybierasz abstrakcji, ponieważ są łatwe do zrozumienia dla ludzi; wybierasz te, które skracają dowód. Myślę, że tak jest generalnie w naukach ścisłych. Idee naukowe nie są przeznaczone do bycia ergonomicznymi.

W sztuce sprawy mają się zupełnie inaczej. Projektowanie dotyczy ludzi. Ludzkie ciało jest dziwną rzeczą, ale kiedy projektujesz krzesło, to właśnie dla niego projektujesz, i nie ma od tego ucieczki. Wszystkie sztuki muszą schlebiać zainteresowaniom i ograniczeniom ludzi. W malarstwie na przykład, przy równych innych warunkach, obraz z ludźmi będzie ciekawszy niż obraz bez nich. To nie jest przypadek historyczny, że wielkie obrazy Renesansu są pełne ludzi. Gdyby tak nie było, malarstwo jako medium nie miałoby takiego prestiżu, jaki ma.

Czy nam się to podoba, czy nie, języki programowania są również dla ludzi, a ja podejrzewam, że ludzki mózg jest równie nieforemny i idiosynkratyczny jak ludzkie ciało. Niektóre idee są łatwe do uchwycenia przez ludzi, a niektóre nie. Na przykład, wydaje się, że mamy bardzo ograniczoną zdolność do radzenia sobie ze szczegółami. To właśnie ten fakt sprawia, że języki programowania są w ogóle dobrym pomysłem; gdybyśmy potrafili sobie poradzić ze szczegółami, moglibyśmy po prostu programować w języku maszynowym.

Pamiętaj też, że języki nie są przede wszystkim formą gotowych programów, ale czymś, w czym programy muszą być rozwijane. Każdy w sztuce mógłby powiedzieć, że możesz chcieć różnych mediów do tych dwóch sytuacji. Marmur, na przykład, jest ładnym, trwałym medium dla gotowych idei, ale beznadziejnie nieelastycznym do rozwijania nowych idei.

Program, podobnie jak dowód, jest przyciętą wersją drzewa, które w przeszłości miało fałszywe początki rozgałęziające się wszędzie. Zatem testem języka jest nie tylko to, jak czysto wygląda w nim gotowy program, ale także to, jak czysta była ścieżka do gotowego programu. Wybór projektowy, który daje eleganckie gotowe programy, może nie dawać eleganckiego procesu projektowania. Na przykład, napisałem kilka makr definiujących makra pełnych zagnieżdżonych cytatów, które teraz wyglądają jak małe klejnoty, ale ich pisanie zajęło godziny najbrzydszego prób i błędów, i szczerze mówiąc, nadal nie jestem całkowicie pewien, czy są poprawne.

Często zachowujemy się tak, jakby testem języka było to, jak dobrze wyglądają w nim gotowe programy. Wydaje się to tak przekonujące, gdy widzisz ten sam program napisany w dwóch językach, a jedna wersja jest znacznie krótsza. Kiedy podchodzisz do problemu z kierunku sztuki, mniej prawdopodobne jest, że polegasz na tego rodzaju teście. Nie chcesz skończyć z językiem programowania jak marmur.

Na przykład, ogromnym plusem w rozwoju oprogramowania jest posiadanie interaktywnego toplevelu, co w Lispie nazywa się pętlą read-eval-print. A kiedy ją masz, ma to rzeczywisty wpływ na projekt języka. Na przykład, nie działałaby dobrze dla języka, w którym musisz deklarować zmienne przed ich użyciem. Kiedy po prostu wpisujesz wyrażenia do toplevelu, chcesz móc przypisać x jakąś wartość, a następnie zacząć robić rzeczy z x. Nie chcesz najpierw deklarować typu x. Możesz spierać się o którąkolwiek z przesłanek, ale jeśli język ma mieć toplevel, aby był wygodny, a obowiązkowe deklaracje typów są niekompatybilne z toplevel, to żaden język, który czyni deklaracje typów obowiązkowymi, nie będzie wygodny w programowaniu.

W praktyce, aby uzyskać dobry projekt, musisz zbliżyć się, i pozostać blisko, swoich użytkowników. Musisz stale kalibrować swoje pomysły na rzeczywistych użytkownikach, zwłaszcza na początku. Jednym z powodów, dla których powieści Jane Austen są tak dobre, jest to, że czytała je na głos swojej rodzinie. Dlatego nigdy nie popada w samolubne opisy krajobrazów ani pretensjonalne filozofowanie. (Filozofia tam jest, ale jest wpleciona w historię, zamiast być przyklejoną jak etykieta.) Jeśli otworzysz przeciętną powieść „literacką” i wyobrazisz sobie, że czytasz ją na głos swoim przyjaciołom jako coś, co napisałeś, poczujesz aż za dobrze, jak bardzo takie rzeczy narzucają się czytelnikowi.

W świecie oprogramowania ta idea jest znana jako „Worse is Better”. W rzeczywistości kilka idei jest zmieszanych w koncepcji „Worse is Better”, dlatego ludzie nadal spierają się, czy gorsze jest faktycznie lepsze, czy nie. Ale jedną z głównych idei w tej mieszance jest to, że jeśli budujesz coś nowego, powinieneś jak najszybciej udostępnić prototyp użytkownikom.

Alternatywne podejście można nazwać strategią „Hail Mary”. Zamiast szybko wypuszczać prototyp i stopniowo go udoskonalać, próbujesz stworzyć kompletny, gotowy produkt w jednym długim podaniu. O ile mi wiadomo, jest to przepis na katastrofę. Niezliczone startupy zniszczyły się w ten sposób podczas bańki internetowej. Nigdy nie słyszałem o przypadku, żeby to zadziałało.

To, czego ludzie spoza świata oprogramowania mogą nie zdawać sobie sprawy, to fakt, że „Worse is Better” jest obecne w całej sztuce. Na przykład w rysunku ta idea została odkryta podczas Renesansu. Teraz prawie każdy nauczyciel rysunku powie ci, że właściwym sposobem na uzyskanie dokładnego rysunku nie jest powolne poruszanie się po konturze obiektu, ponieważ błędy się skumulują i na końcu okaże się, że linie się nie stykają. Zamiast tego powinieneś narysować kilka szybkich linii w przybliżeniu we właściwym miejscu, a następnie stopniowo udoskonalać ten początkowy szkic.

W większości dziedzin prototypy tradycyjnie wykonywano z różnych materiałów. Czcionki do wycinania w metalu były początkowo projektowane pędzlem na papierze. Posągi do odlewania w brązie modelowano w wosku. Wzory do haftowania na gobelinach rysowano na papierze tuszem. Budynki do konstrukcji z kamienia testowano w mniejszej skali w drewnie.

To, co sprawiło, że farby olejne były tak ekscytujące, gdy po raz pierwszy zyskały popularność w XV wieku, było to, że można było faktycznie stworzyć gotowe dzieło z prototypu. Można było zrobić wstępny szkic, jeśli się chciało, ale nie było się do niego przywiązanym; można było dopracować wszystkie szczegóły, a nawet dokonać znaczących zmian podczas kończenia obrazu.

W oprogramowaniu też można to zrobić. Prototyp nie musi być tylko modelem; można go udoskonalić do gotowego produktu. Myślę, że zawsze powinieneś to robić, kiedy tylko możesz. Pozwala to wykorzystać nowe spostrzeżenia, które pojawiają się po drodze. Ale być może nawet ważniejsze, jest to dobre dla morale.

Morale jest kluczowe w projektowaniu. Zaskakuje mnie, że ludzie o tym nie mówią więcej. Jeden z moich pierwszych nauczycieli rysunku powiedział mi: jeśli się nudzisz podczas rysowania czegoś, rysunek będzie wyglądał nudno. Na przykład, załóżmy, że musisz narysować budynek i postanawiasz narysować każdą cegłę indywidualnie. Możesz to zrobić, jeśli chcesz, ale jeśli znudzisz się w połowie i zaczniesz robić cegły mechanicznie zamiast obserwować każdą z nich, rysunek będzie wyglądał gorzej niż gdybyś tylko sugerował cegły.

Budowanie czegoś poprzez stopniowe udoskonalanie prototypu jest dobre dla morale, ponieważ utrzymuje zaangażowanie. W oprogramowaniu moja zasada brzmi: zawsze miej działający kod. Jeśli piszesz coś, co będziesz mógł przetestować za godzinę, masz perspektywę natychmiastowej nagrody, która cię zmotywuje. To samo dotyczy sztuki, a zwłaszcza malarstwa olejnego. Większość malarzy zaczyna od rozmazanego szkicu i stopniowo go udoskonala. Jeśli pracujesz w ten sposób, to w zasadzie nigdy nie musisz kończyć dnia czymś, co faktycznie wygląda na niedokończone. Istnieje nawet powiedzenie wśród malarzy: „Obraz nigdy nie jest skończony, po prostu przestajesz nad nim pracować”. Ta idea będzie znajoma każdemu, kto pracował nad oprogramowaniem.

Morale to kolejny powód, dla którego trudno jest zaprojektować coś dla niewyrafinowanego użytkownika. Trudno pozostać zainteresowanym czymś, czego samemu się nie lubi. Aby zrobić coś dobrego, musisz myśleć: „wow, to jest naprawdę świetne”, a nie: „co za gówno; ci idioci to pokochają”.

Projektowanie oznacza tworzenie rzeczy dla ludzi. Ale ludzki jest nie tylko użytkownik. Ludzki jest również projektant.

Zauważ, że przez cały ten czas mówiłem o „projektancie”. Projekt zazwyczaj musi być pod kontrolą jednej osoby, aby był dobry. A jednak wydaje się możliwe, aby kilku ludzi współpracowało przy projekcie badawczym. To wydaje mi się jedną z najciekawszych różnic między badaniami a projektowaniem.

Istniały słynne przykłady współpracy w sztuce, ale większość z nich wydaje się być przypadkami wiązania molekularnego, a nie fuzji jądrowej. W operze często zdarza się, że jedna osoba pisze libretto, a druga muzykę. A podczas Renesansu, czeladnicy z Europy Północnej byli często zatrudniani do wykonywania krajobrazów w tle włoskich obrazów. Ale to nie są prawdziwe współprace. To bardziej przykłady powiedzenia Roberta Frosta „dobre ogrodzenia tworzą dobrych sąsiadów”. Możesz połączyć dobre projekty, ale w ramach każdego indywidualnego projektu jedna osoba musi mieć kontrolę.

Nie mówię, że dobry projekt wymaga, aby jedna osoba wszystko przemyślała. Nie ma nic cenniejszego niż rada kogoś, komu ufasz. Ale po zakończeniu rozmowy decyzja o tym, co zrobić, musi spocząć na jednej osobie.

Dlaczego badania mogą być prowadzone przez współpracowników, a projekt nie? To ciekawe pytanie. Nie znam odpowiedzi. Być może, jeśli projekt i badania się zbiegają, najlepsze badania są również dobrym projektem, a faktycznie nie mogą być prowadzone przez współpracowników. Wielu najsłynniejszych naukowców wydaje się pracować samotnie. Ale nie wiem wystarczająco dużo, aby stwierdzić, czy istnieje taki wzorzec. Może to po prostu fakt, że wielu słynnych naukowców pracowało w czasach, gdy współpraca była mniej powszechna.

Jaka by nie była historia w naukach ścisłych, prawdziwa współpraca wydaje się być niezwykle rzadka w sztuce. Projektowanie przez komitet jest synonimem złego projektu. Dlaczego tak jest? Czy jest jakiś sposób, aby pokonać to ograniczenie?

Skłaniam się ku myśleniu, że nie – że dobry projekt wymaga dyktatora. Jednym z powodów jest to, że dobry projekt musi być jednością. Projekt jest nie tylko dla ludzi, ale dla indywidualnych ludzi. Jeśli projekt reprezentuje ideę, która mieści się w głowie jednej osoby, to idea ta zmieści się również w głowie użytkownika.

Powiązane: