Ontwerp en Onderzoek

Januari 2003

(Dit artikel is afgeleid van een keynote speech op de najaarsbijeenkomst van NEPLS in 2002.)

Bezoekers van dit land zijn vaak verrast om te ontdekken dat Amerikanen een gesprek beginnen met de vraag "wat doe je?". Ik heb deze vraag nooit leuk gevonden. Ik heb er zelden een net antwoord op gehad. Maar ik denk dat ik het probleem eindelijk heb opgelost. Nu, als iemand me vraagt wat ik doe, kijk ik hem recht in de ogen en zeg: "Ik ontwerp een nieuwe dialect van Lisp." Ik raad dit antwoord aan iedereen aan die niet graag wordt gevraagd wat hij doet. Het gesprek zal onmiddellijk naar andere onderwerpen afbuigen.

Ik beschouw mezelf niet als iemand die onderzoek doet naar programmeertalen. Ik ontwerp er gewoon een, op dezelfde manier als iemand een gebouw, een stoel of een nieuw lettertype zou ontwerpen. Ik probeer niets nieuws te ontdekken. Ik wil gewoon een taal maken die goed is om in te programmeren. In sommige opzichten maakt deze aanname het leven een stuk gemakkelijker.

Het verschil tussen ontwerp en onderzoek lijkt een kwestie van nieuw versus goed. Ontwerp hoeft niet nieuw te zijn, maar het moet goed zijn. Onderzoek hoeft niet goed te zijn, maar het moet nieuw zijn. Ik denk dat deze twee paden bovenaan samenkomen: het beste ontwerp overtreft zijn voorgangers door nieuwe ideeën te gebruiken, en het beste onderzoek lost problemen op die niet alleen nieuw zijn, maar ook daadwerkelijk de moeite waard zijn om op te lossen. Uiteindelijk streven we dus naar dezelfde bestemming, alleen benaderen we deze vanuit verschillende richtingen.

Waar ik het vandaag over ga hebben, is hoe je doel er vanaf de achterkant uitziet. Wat doe je anders als je programmeertalen behandelt als een ontwerpprobleem in plaats van een onderzoeksonderwerp?

Het grootste verschil is dat je je meer richt op de gebruiker. Ontwerp begint met de vraag: voor wie is dit bedoeld en wat hebben ze eraan nodig? Een goede architect begint bijvoorbeeld niet met het creëren van een ontwerp dat hij vervolgens aan de gebruikers oplegt, maar door de beoogde gebruikers te bestuderen en uit te zoeken wat ze nodig hebben.

Let op: ik zei "wat ze nodig hebben", niet "wat ze willen". Ik wil niet de indruk wekken dat werken als ontwerper betekent werken als een soort snelle kok, die maakt wat de klant hem vertelt. Dit varieert per kunstveld, maar ik denk niet dat er een veld is waarin het beste werk wordt gedaan door mensen die gewoon precies maken wat de klanten hen vertellen.

De klant heeft altijd gelijk in de zin dat de maatstaf voor goed ontwerp is hoe goed het voor de gebruiker werkt. Als je een roman schrijft die iedereen verveelt, of een stoel waar het vreselijk ongemakkelijk op zit, dan heb je gewoon slecht werk geleverd. Het is geen verdediging om te zeggen dat de roman of de stoel is ontworpen volgens de meest geavanceerde theoretische principes.

En toch betekent het maken van wat voor de gebruiker werkt niet simpelweg maken wat de gebruiker je vertelt. Gebruikers weten niet wat alle opties zijn, en hebben het vaak mis over wat ze werkelijk willen.

Het antwoord op de paradox, denk ik, is dat je moet ontwerpen voor de gebruiker, maar je moet ontwerpen wat de gebruiker nodig heeft, niet simpelweg wat hij zegt dat hij wil. Het is een beetje als een dokter zijn. Je kunt niet alleen de symptomen van een patiënt behandelen. Wanneer een patiënt je zijn symptomen vertelt, moet je uitzoeken wat er werkelijk mis met hem is en dat behandelen.

Deze focus op de gebruiker is een soort axioma waaruit het grootste deel van de praktijk van goed ontwerp kan worden afgeleid, en waarom de meeste ontwerpkwesties draaien.

Als goed ontwerp moet doen wat de gebruiker nodig heeft, wie is dan de gebruiker? Als ik zeg dat ontwerp voor gebruikers moet zijn, bedoel ik niet te impliceren dat goed ontwerp streeft naar een soort laagste gemeenschappelijke deler. Je kunt elke groep gebruikers kiezen die je wilt. Als je bijvoorbeeld een gereedschap ontwerpt, kun je het ontwerpen voor iedereen, van beginners tot experts, en wat goed ontwerp is voor de ene groep, kan slecht zijn voor de andere. Het punt is dat je een groep gebruikers moet kiezen. Ik denk niet dat je überhaupt kunt praten over goed of slecht ontwerp, behalve met betrekking tot een beoogde gebruiker.

Je krijgt waarschijnlijk het beste ontwerp als de beoogde gebruikers de ontwerper zelf omvatten. Wanneer je iets ontwerpt voor een groep waar je zelf niet toe behoort, is het meestal voor mensen die je als minder verfijnd beschouwt, niet meer verfijnd.

Dat is een probleem, want neerkijken op de gebruiker, hoe welwillend ook, lijkt onvermijdelijk de ontwerper te corrumperen. Ik vermoed dat heel weinig woningbouwprojecten in de VS zijn ontworpen door architecten die er zelf zouden gaan wonen. Je ziet hetzelfde in programmeertalen. C, Lisp en Smalltalk zijn gemaakt voor hun eigen ontwerpers om te gebruiken. Cobol, Ada en Java zijn gemaakt om door andere mensen te worden gebruikt.

Als je denkt dat je iets ontwerpt voor idioten, is de kans groot dat je niets goeds ontwerpt, zelfs niet voor idioten.

Zelfs als je iets ontwerpt voor de meest verfijnde gebruikers, ontwerp je nog steeds voor mensen. Het is anders in onderzoek. In wiskunde kies je geen abstracties omdat ze gemakkelijk te begrijpen zijn voor mensen; je kiest welke de bewijsvoering korter maken. Ik denk dat dit over het algemeen geldt voor de wetenschappen. Wetenschappelijke ideeën zijn niet bedoeld om ergonomisch te zijn.

In de kunsten is het heel anders. Ontwerp draait helemaal om mensen. Het menselijk lichaam is een vreemd ding, maar als je een stoel ontwerpt, is dat waarvoor je ontwerpt, en daar is geen ontkomen aan. Alle kunsten moeten toegeven aan de belangen en beperkingen van mensen. In de schilderkunst bijvoorbeeld, zal een schilderij met mensen erin, bij gelijke andere omstandigheden, interessanter zijn dan een zonder. Het is niet louter een historisch toeval dat de grote schilderijen uit de Renaissance allemaal vol mensen zitten. Als dat niet het geval was geweest, zou schilderkunst als medium niet de prestige hebben die het nu heeft.

Of je het nu leuk vindt of niet, programmeertalen zijn ook voor mensen, en ik vermoed dat het menselijk brein net zo grillig en eigenzinnig is als het menselijk lichaam. Sommige ideeën zijn gemakkelijk voor mensen om te begrijpen en sommige niet. We lijken bijvoorbeeld een zeer beperkte capaciteit te hebben voor het omgaan met details. Het is dit feit dat programmeertalen in de eerste plaats een goed idee maakt; als we de details konden hanteren, konden we gewoon in machinetaal programmeren.

Vergeet ook niet dat talen niet primair een vorm zijn voor voltooide programma's, maar iets waarin programma's moeten worden ontwikkeld. Iedereen in de kunsten kan je vertellen dat je verschillende media kunt willen voor de twee situaties. Marmer, bijvoorbeeld, is een mooi, duurzaam medium voor voltooide ideeën, maar een hopeloos inflexibel medium voor het ontwikkelen van nieuwe ideeën.

Een programma, net als een bewijs, is een gesnoeide versie van een boom die in het verleden valse starts had vertakt. De test van een taal is dus niet simpelweg hoe schoon het voltooide programma erin oogt, maar hoe schoon het pad naar het voltooide programma was. Een ontwerpkeuze die je elegante voltooide programma's oplevert, levert je misschien geen elegant ontwerpproces op. Ik heb bijvoorbeeld een paar macro-definierende macro's geschreven vol met geneste backticks die er nu uitzien als kleine juweeltjes, maar het schrijven ervan kostte uren van het lelijkste vallen en opstaan, en eerlijk gezegd ben ik er nog steeds niet helemaal zeker van dat ze correct zijn.

We doen vaak alsof de test van een taal is hoe goed voltooide programma's erin uitzien. Het lijkt zo overtuigend als je hetzelfde programma in twee talen ziet geschreven, en de ene versie is veel korter. Als je het probleem vanuit de richting van de kunsten benadert, ben je minder geneigd om op dit soort tests te vertrouwen. Je wilt niet eindigen met een programmeertaal als marmer.

Het is bijvoorbeeld een enorme winst bij het ontwikkelen van software om een interactieve toplevel te hebben, wat in Lisp een read-eval-print loop wordt genoemd. En als je er een hebt, heeft dit reële gevolgen voor het ontwerp van de taal. Het zou bijvoorbeeld niet goed werken voor een taal waarin je variabelen moet declareren voordat je ze gebruikt. Als je gewoon expressies in de toplevel typt, wil je een variabele x een waarde kunnen toekennen en dan dingen met x gaan doen. Je wilt niet eerst het type van x hoeven te declareren. Je kunt het met een van beide premissen oneens zijn, maar als een taal een toplevel moet hebben om handig te zijn, en verplichte type declaraties onverenigbaar zijn met een toplevel, dan kan geen enkele taal die type declaraties verplicht stelt, handig zijn om in te programmeren.

In de praktijk moet je, om goed ontwerp te krijgen, dicht bij je gebruikers komen en dicht bij hen blijven. Je moet je ideeën voortdurend kalibreren op echte gebruikers, vooral in het begin. Een van de redenen dat de romans van Jane Austen zo goed zijn, is dat ze ze hardop voorlas aan haar familie. Daarom verzinkt ze nooit in zelfingenomen artistieke beschrijvingen van landschappen, of pretentieuze filosofie. (De filosofie is er wel, maar het is in het verhaal verweven in plaats van erop geplakt als een label.) Als je een gemiddelde "literaire" roman opent en je voorstelt dat je hem hardop voorleest aan je vrienden als iets dat je hebt geschreven, zul je maar al te goed voelen wat voor een opdringerigheid dat soort dingen voor de lezer is.

In de softwarewereld staat dit idee bekend als Worse is Better. Eigenlijk zijn er verschillende ideeën vermengd in het concept van Worse is Better, daarom discussiëren mensen nog steeds over de vraag of slechter eigenlijk beter is of niet. Maar een van de belangrijkste ideeën in die mix is dat als je iets nieuws bouwt, je zo snel mogelijk een prototype aan gebruikers moet laten zien.

De alternatieve benadering kan de Hail Mary-strategie worden genoemd. In plaats van snel een prototype uit te brengen en het geleidelijk te verfijnen, probeer je het complete, afgewerkte product in één lange touchdown pass te creëren. Voor zover ik weet, is dit een recept voor rampen. Ontelbare startups hebben zichzelf op deze manier vernietigd tijdens de internetbubbel. Ik heb nog nooit gehoord van een geval waarin het werkte.

Wat mensen buiten de softwarewereld misschien niet realiseren, is dat Worse is Better door de hele kunstwereld heen te vinden is. In tekenen bijvoorbeeld, werd het idee ontdekt tijdens de Renaissance. Nu zal bijna elke tekendocent je vertellen dat de juiste manier om een nauwkeurige tekening te maken niet is om langzaam rond de contour van een object te werken, omdat fouten zich zullen ophopen en je aan het einde zult merken dat de lijnen niet samenkomen. In plaats daarvan moet je een paar snelle lijnen op ongeveer de juiste plaats zetten en dit initiële schets geleidelijk verfijnen.

In de meeste velden werden prototypes traditioneel gemaakt van verschillende materialen. Lettertypen die in metaal zouden worden gesneden, werden aanvankelijk met een penseel op papier ontworpen. Beelden die in brons zouden worden gegoten, werden gemodelleerd in was. Patronen die op wandtapijten zouden worden geborduurd, werden op papier getekend met penseel en inkt. Gebouwen die van steen zouden worden gebouwd, werden op kleinere schaal getest in hout.

Wat olieverf zo spannend maakte, toen het in de vijftiende eeuw populair werd, was dat je het eindproduct feitelijk van het prototype kon maken. Je kon een voorlopige tekening maken als je wilde, maar je was er niet aan gebonden; je kon alle details uitwerken, en zelfs grote veranderingen aanbrengen, terwijl je het schilderij afwerkte.

Dit kun je ook in software doen. Een prototype hoeft niet alleen een model te zijn; je kunt het verfijnen tot het eindproduct. Ik denk dat je dit altijd moet doen als je kunt. Het stelt je in staat om nieuwe inzichten die je onderweg hebt, te benutten. Maar misschien nog belangrijker, het is goed voor het moreel.

Moreel is de sleutel in ontwerp. Ik ben verbaasd dat mensen er niet meer over praten. Een van mijn eerste tekendocenten zei: als je je verveelt terwijl je iets tekent, zal de tekening er saai uitzien. Stel je voor dat je een gebouw moet tekenen en je besluit elke baksteen individueel te tekenen. Dat kan als je wilt, maar als je halverwege verveeld raakt en de stenen mechanisch begint te maken in plaats van elke steen te observeren, zal de tekening er slechter uitzien dan wanneer je de stenen slechts had gesuggereerd.

Het bouwen van iets door geleidelijk een prototype te verfijnen, is goed voor het moreel omdat het je betrokken houdt. In software is mijn regel: heb altijd werkende code. Als je iets schrijft dat je over een uur kunt testen, heb je het vooruitzicht van een onmiddellijke beloning om je te motiveren. Hetzelfde geldt in de kunsten, en met name in de olieverfschilderkunst. De meeste schilders beginnen met een wazige schets en verfijnen deze geleidelijk. Als je op deze manier werkt, hoef je in principe nooit de dag af te sluiten met iets dat er feitelijk onvoltooid uitziet. Er is zelfs een gezegde onder schilders: "Een schilderij is nooit af, je stopt er gewoon mee." Dit idee zal bekend voorkomen bij iedereen die aan software heeft gewerkt.

Moreel is nog een reden waarom het moeilijk is om iets te ontwerpen voor een onverfijnde gebruiker. Het is moeilijk om geïnteresseerd te blijven in iets dat je zelf niet leuk vindt. Om iets goeds te maken, moet je denken: "wow, dit is echt geweldig", niet "wat een stuk stront; die dwazen zullen het geweldig vinden."

Ontwerp betekent dingen maken voor mensen. Maar het is niet alleen de gebruiker die menselijk is. De ontwerper is ook menselijk.

Merk op dat ik al die tijd over "de ontwerper" heb gesproken. Ontwerp moet meestal onder controle staan van één persoon om goed te zijn. En toch lijkt het mogelijk voor meerdere mensen om samen te werken aan een onderzoeksproject. Dit lijkt me een van de meest interessante verschillen tussen onderzoek en ontwerp.

Er zijn beroemde voorbeelden van samenwerking in de kunsten geweest, maar de meeste lijken gevallen van moleculaire binding te zijn geweest in plaats van kernfusie. In een opera is het gebruikelijk dat de ene persoon het libretto schrijft en de andere de muziek. En tijdens de Renaissance werden reizende ambachtslieden uit Noord-Europa vaak ingehuurd om de landschappen op de achtergronden van Italiaanse schilderijen te doen. Maar dit zijn geen echte samenwerkingen. Het zijn meer voorbeelden van Robert Frost's "goede hekken maken goede buren." Je kunt goede ontwerpinstanties aan elkaar plakken, maar binnen elk individueel project moet één persoon de controle hebben.

Ik zeg niet dat goed ontwerp vereist dat één persoon aan alles denkt. Er is niets waardevoller dan het advies van iemand wiens oordeel je vertrouwt. Maar nadat het praten is gedaan, moet de beslissing over wat te doen bij één persoon liggen.

Waarom kan onderzoek door samenwerkende partijen worden gedaan en ontwerp niet? Dit is een interessante vraag. Ik ken het antwoord niet. Misschien, als ontwerp en onderzoek samenkomen, is het beste onderzoek ook goed ontwerp, en kan het in feite niet door samenwerkende partijen worden gedaan. Veel van de beroemdste wetenschappers lijken alleen te hebben gewerkt. Maar ik weet niet genoeg om te zeggen of hier een patroon in zit. Het kan simpelweg zijn dat veel beroemde wetenschappers werkten toen samenwerking minder gebruikelijk was.

Wat het verhaal ook is in de wetenschappen, echte samenwerking lijkt in de kunsten zeldzaam te zijn. Ontwerp door een commissie is een synoniem voor slecht ontwerp. Waarom is dat zo? Is er een manier om deze beperking te overwinnen?

Ik ben geneigd te denken van niet – dat goed ontwerp een dictator vereist. Een reden is dat goed ontwerp een geheel moet zijn. Ontwerp is niet alleen voor mensen, maar voor individuele mensen. Als een ontwerp een idee vertegenwoordigt dat in het hoofd van één persoon past, dan zal het idee ook in het hoofd van de gebruiker passen.

Gerelateerd: