DESIGN UND FORSCHUNG

Januar 2003

(Dieser Artikel stammt aus einem Hauptvortrag beim Herbsttreffen 2002 von NEPLS.)

Besucher dieses Landes sind oft überrascht, dass Amerikaner gerne ein Gespräch mit der Frage "Was machst du?" beginnen. Ich habe diese Frage nie gemocht. Ich hatte selten eine klare Antwort darauf. Aber ich denke, ich habe das Problem endlich gelöst. Jetzt, wenn mich jemand fragt, was ich mache, schaue ich ihm direkt in die Augen und sage: "Ich entwerfe einen neuen Dialekt von Lisp." Ich empfehle diese Antwort jedem, der es nicht mag, gefragt zu werden, was er macht. Das Gespräch wird sofort auf andere Themen umschwenken.

Ich betrachte mich nicht als jemanden, der Forschung über Programmiersprachen betreibt. Ich entwerfe einfach eine, so wie jemand ein Gebäude oder einen Stuhl oder eine neue Schriftart entwerfen könnte. Ich versuche nicht, etwas Neues zu entdecken. Ich möchte einfach eine Sprache schaffen, die gut zu programmieren ist. In gewisser Weise macht diese Annahme das Leben viel einfacher.

Der Unterschied zwischen Design und Forschung scheint eine Frage von neu versus gut zu sein. Design muss nicht neu sein, aber es muss gut sein. Forschung muss nicht gut sein, aber sie muss neu sein. Ich denke, diese beiden Wege treffen sich an der Spitze: Das beste Design übertrifft seine Vorgänger, indem es neue Ideen verwendet, und die beste Forschung löst Probleme, die nicht nur neu, sondern tatsächlich wert sind, gelöst zu werden. Letztendlich streben wir also nach demselben Ziel, nur aus unterschiedlichen Richtungen.

Worüber ich heute sprechen möchte, ist, wie dein Ziel von hinten aussieht. Was machst du anders, wenn du Programmiersprachen als Designproblem anstatt als Forschungsthema behandelst?

Der größte Unterschied ist, dass du dich mehr auf den Benutzer konzentrierst. Design beginnt mit der Frage, für wen ist das und was braucht er davon? Ein guter Architekt beginnt zum Beispiel nicht damit, ein Design zu erstellen, das er dann den Benutzern aufzwingt, sondern indem er die beabsichtigten Benutzer studiert und herausfindet, was sie brauchen.

Beachte, dass ich "was sie brauchen" gesagt habe, nicht "was sie wollen." Ich möchte nicht den Eindruck erwecken, dass es bedeutet, als Designer zu arbeiten, eine Art Kurzzeitkoch zu sein, der macht, was der Kunde dir sagt. Das variiert von Bereich zu Bereich in den Künsten, aber ich glaube nicht, dass es ein Feld gibt, in dem die beste Arbeit von den Menschen gemacht wird, die einfach genau das tun, was die Kunden ihnen sagen.

Der Kunde hat immer recht im Sinne davon, dass das Maß für gutes Design ist, wie gut es für den Benutzer funktioniert. Wenn du einen Roman schreibst, der alle langweilt, oder einen Stuhl, der schrecklich unbequem ist, dann hast du einen schlechten Job gemacht, Punkt. Es ist keine Verteidigung zu sagen, dass der Roman oder der Stuhl nach den fortschrittlichsten theoretischen Prinzipien entworfen wurde.

Und doch bedeutet es, was für den Benutzer funktioniert, nicht einfach das zu machen, was der Benutzer dir sagt. Benutzer wissen nicht, was alle Optionen sind, und irren sich oft darüber, was sie wirklich wollen.

Die Antwort auf das Paradoxon, denke ich, ist, dass du für den Benutzer entwerfen musst, aber du musst das entwerfen, was der Benutzer braucht, nicht einfach das, was er sagt, dass er will. Es ist viel wie bei einem Arzt. Du kannst nicht einfach die Symptome eines Patienten behandeln. Wenn ein Patient dir seine Symptome sagt, musst du herausfinden, was tatsächlich mit ihm nicht stimmt, und das behandeln.

Dieser Fokus auf den Benutzer ist eine Art Axiom, aus dem die meisten Praktiken guten Designs abgeleitet werden können und um das sich die meisten Designfragen drehen.

Wenn gutes Design das tun muss, was der Benutzer braucht, wer ist der Benutzer? Wenn ich sage, dass Design für Benutzer sein muss, möchte ich nicht implizieren, dass gutes Design auf eine Art von niedrigstem gemeinsamen Nenner abzielt. Du kannst jede Benutzergruppe wählen, die du möchtest. Wenn du zum Beispiel ein Werkzeug entwirfst, kannst du es für jeden von Anfängern bis zu Experten entwerfen, und was für eine Gruppe gutes Design ist, könnte für eine andere schlecht sein. Der Punkt ist, du musst eine Benutzergruppe auswählen. Ich glaube nicht, dass du überhaupt von gutem oder schlechtem Design sprechen kannst, außer im Hinblick auf einen beabsichtigten Benutzer.

Du wirst am ehesten gutes Design erhalten, wenn die beabsichtigten Benutzer den Designer selbst einschließen. Wenn du etwas für eine Gruppe entwirfst, die dich nicht einschließt, neigt es dazu, für Menschen zu sein, die du als weniger anspruchsvoll betrachtest als dich, nicht anspruchsvoller.

Das ist ein Problem, denn auf den Benutzer herabzusehen, so wohlwollend es auch sein mag, scheint den Designer unvermeidlich zu verderben. Ich vermute, dass sehr wenige Wohnprojekte in den USA von Architekten entworfen wurden, die erwarteten, darin zu leben. Du kannst dasselbe in Programmiersprachen sehen. C, Lisp und Smalltalk wurden für ihre eigenen Designer geschaffen. Cobol, Ada und Java wurden für andere Menschen geschaffen.

Wenn du denkst, dass du etwas für Idioten entwirfst, stehen die Chancen gut, dass du nichts Gutes entwirfst, selbst für Idioten.

Selbst wenn du etwas für die anspruchsvollsten Benutzer entwirfst, entwirfst du immer noch für Menschen. Es ist anders in der Forschung. In der Mathematik wählst du Abstraktionen nicht, weil sie für Menschen leicht zu verstehen sind; du wählst die, die den Beweis kürzer machen. Ich denke, das gilt allgemein für die Wissenschaften. Wissenschaftliche Ideen sind nicht dazu gedacht, ergonomisch zu sein.

In den Künsten ist es ganz anders. Design dreht sich alles um Menschen. Der menschliche Körper ist eine seltsame Sache, aber wenn du einen Stuhl entwirfst, ist das, wofür du entwirfst, und es gibt keinen Weg daran vorbei. Alle Künste müssen den Interessen und Einschränkungen der Menschen Rechnung tragen. In der Malerei zum Beispiel wird ein Gemälde mit Menschen darin, alles andere gleich, interessanter sein als eines ohne. Es ist kein bloßer Zufall der Geschichte, dass die großen Gemälde der Renaissance alle voller Menschen sind. Wenn sie es nicht gewesen wären, hätte die Malerei als Medium nicht den Prestige, den sie hat.

Ob es dir gefällt oder nicht, Programmiersprachen sind auch für Menschen, und ich vermute, dass das menschliche Gehirn genauso klumpig und eigensinnig ist wie der menschliche Körper. Einige Ideen sind für Menschen leicht zu erfassen und andere nicht. Zum Beispiel scheinen wir eine sehr begrenzte Fähigkeit zu haben, mit Details umzugehen. Diese Tatsache macht Programmiersprachen überhaupt erst zu einer guten Idee; wenn wir mit den Details umgehen könnten, könnten wir einfach in Maschinensprache programmieren.

Denke auch daran, dass Sprachen nicht primär eine Form für fertige Programme sind, sondern etwas, in dem Programme entwickelt werden müssen. Jeder in den Künsten könnte dir sagen, dass du für die beiden Situationen möglicherweise unterschiedliche Medien wählen möchtest. Marmor zum Beispiel ist ein schönes, langlebiges Medium für fertige Ideen, aber ein hoffnungslos unflexibles für die Entwicklung neuer Ideen.

Ein Programm, wie ein Beweis, ist eine beschnittene Version eines Baumes, der in der Vergangenheit falsche Starts hatte, die überall davon abzweigten. Daher ist der Test einer Sprache nicht einfach, wie sauber das fertige Programm darin aussieht, sondern wie sauber der Weg zum fertigen Programm war. Eine Designentscheidung, die dir elegante fertige Programme gibt, gibt dir möglicherweise keinen eleganten Designprozess. Zum Beispiel habe ich ein paar Makro-definierende Makros mit verschachtelten Backquotes geschrieben, die jetzt wie kleine Juwelen aussehen, aber das Schreiben hat Stunden des hässlichsten Ausprobierens gekostet, und ehrlich gesagt bin ich mir immer noch nicht ganz sicher, ob sie korrekt sind.

Wir handeln oft so, als wäre der Test einer Sprache, wie gut fertige Programme darin aussehen. Es scheint so überzeugend, wenn du dasselbe Programm in zwei Sprachen siehst und eine Version viel kürzer ist. Wenn du das Problem aus der Richtung der Künste angehst, bist du weniger geneigt, von dieser Art von Test abhängig zu sein. Du willst nicht mit einer Programmiersprache enden, die wie Marmor ist.

Zum Beispiel ist es ein großer Vorteil bei der Softwareentwicklung, ein interaktives Top-Level zu haben, was in Lisp als read-eval-print loop bezeichnet wird. Und wenn du eines hast, hat das echte Auswirkungen auf das Design der Sprache. Es würde nicht gut für eine Sprache funktionieren, in der du Variablen deklarieren musst, bevor du sie verwendest. Wenn du einfach Ausdrücke in das Top-Level eingibst, möchtest du in der Lage sein, x auf einen bestimmten Wert zu setzen und dann anfangen, Dinge mit x zu tun. Du möchtest nicht zuerst den Typ von x deklarieren müssen. Du kannst entweder eine der Prämissen bestreiten, aber wenn eine Sprache ein Top-Level haben muss, um bequem zu sein, und obligatorische Typdeklarationen mit einem Top-Level unvereinbar sind, dann könnte keine Sprache, die Typdeklarationen obligatorisch macht, bequem zu programmieren sein.

In der Praxis musst du, um gutes Design zu erhalten, nah an deinen Benutzern bleiben und nah bleiben. Du musst deine Ideen ständig an tatsächlichen Benutzern kalibrieren, besonders am Anfang. Einer der Gründe, warum Jane Austens Romane so gut sind, ist, dass sie sie laut ihrer Familie vorgelesen hat. Das ist der Grund, warum sie nie in selbstgefällige, künstlerische Beschreibungen von Landschaften oder prätentiöses Philosophieren abgleitet. (Die Philosophie ist da, aber sie ist in die Geschichte eingewebt, anstatt wie ein Etikett daraufgeklebt zu werden.) Wenn du einen durchschnittlichen "literarischen" Roman öffnest und dir vorstellst, ihn laut deinen Freunden vorzulesen, als hättest du ihn geschrieben, wirst du allzu schmerzlich spüren, was für eine Zumutung so etwas für den Leser ist.

In der Softwarewelt ist diese Idee als "Worse is Better" bekannt. Tatsächlich sind mehrere Ideen im Konzept von "Worse is Better" vermischt, weshalb die Leute immer noch darüber streiten, ob schlechter tatsächlich besser ist oder nicht. Aber eine der Hauptideen in diesem Mix ist, dass, wenn du etwas Neues baust, du so schnell wie möglich einen Prototypen vor den Benutzern haben solltest.

Der alternative Ansatz könnte als "Hail Mary"-Strategie bezeichnet werden. Anstatt schnell einen Prototypen herauszubekommen und ihn schrittweise zu verfeinern, versuchst du, das komplette, fertige Produkt in einem langen Touchdown-Pass zu erstellen. Soweit ich weiß, ist das ein Rezept für eine Katastrophe. Unzählige Startups haben sich auf diese Weise während der Internetblase selbst zerstört. Ich habe noch nie von einem Fall gehört, in dem es funktioniert hat.

Was Menschen außerhalb der Softwarewelt möglicherweise nicht realisieren, ist, dass "Worse is Better" in den Künsten weit verbreitet ist. In der Zeichnung zum Beispiel wurde die Idee während der Renaissance entdeckt. Jetzt wird dir fast jeder Zeichenlehrer sagen, dass der richtige Weg, eine genaue Zeichnung zu erhalten, nicht darin besteht, sich langsam um die Kontur eines Objekts zu arbeiten, weil sich Fehler ansammeln und du am Ende feststellst, dass die Linien sich nicht treffen. Stattdessen solltest du ein paar schnelle Linien an ungefähr der richtigen Stelle zeichnen und dann diese erste Skizze allmählich verfeinern.

In den meisten Bereichen wurden Prototypen traditionell aus verschiedenen Materialien hergestellt. Schriftarten, die in Metall geschnitten werden sollten, wurden ursprünglich mit einem Pinsel auf Papier entworfen. Statuen, die in Bronze gegossen werden sollten, wurden in Wachs modelliert. Muster, die auf Wandteppichen gestickt werden sollten, wurden mit Tinte auf Papier gezeichnet. Gebäude, die aus Stein gebaut werden sollten, wurden im kleineren Maßstab in Holz getestet.

Was Ölfarbe so aufregend machte, als sie im fünfzehnten Jahrhundert populär wurde, war, dass du das fertige Werk aus dem Prototypen machen konntest. Du konntest eine vorläufige Zeichnung machen, wenn du wolltest, aber du warst nicht daran gebunden; du konntest alle Details ausarbeiten und sogar größere Änderungen vornehmen, während du das Gemälde fertigstelltest.

Das kannst du auch in der Software tun. Ein Prototyp muss nicht nur ein Modell sein; du kannst ihn in das fertige Produkt verfeinern. Ich denke, du solltest das immer tun, wenn du kannst. Es ermöglicht dir, neue Erkenntnisse, die du auf dem Weg hast, zu nutzen. Aber vielleicht noch wichtiger ist, dass es gut für die Moral ist.

Moral ist der Schlüssel im Design. Ich bin überrascht, dass die Leute nicht mehr darüber sprechen. Einer meiner ersten Zeichenlehrer sagte mir: Wenn du gelangweilt bist, während du etwas zeichnest, wird die Zeichnung langweilig aussehen. Zum Beispiel, nehmen wir an, du musst ein Gebäude zeichnen, und du entscheidest dich, jeden Ziegel einzeln zu zeichnen. Du kannst das tun, wenn du willst, aber wenn du in der Mitte gelangweilt bist und anfängst, die Ziegel mechanisch zu machen, anstatt jeden zu beobachten, wird die Zeichnung schlechter aussehen, als wenn du nur die Ziegel angedeutet hättest.

Etwas zu bauen, indem du schrittweise einen Prototyp verfeinerst, ist gut für die Moral, weil es dich engagiert hält. In der Software ist meine Regel: immer funktionierenden Code haben. Wenn du etwas schreibst, das du in einer Stunde testen kannst, hast du die Aussicht auf eine sofortige Belohnung, die dich motiviert. Das Gleiche gilt in den Künsten, insbesondere in der Ölmalerei. Die meisten Maler beginnen mit einer verschwommenen Skizze und verfeinern sie allmählich. Wenn du auf diese Weise arbeitest, dann musst du prinzipiell nie den Tag mit etwas beenden, das tatsächlich unvollständig aussieht. Tatsächlich gibt es sogar ein Sprichwort unter Malern: "Ein Gemälde ist nie fertig, du hörst einfach auf, daran zu arbeiten." Diese Idee wird jedem vertraut sein, der an Software gearbeitet hat.

Moral ist ein weiterer Grund, warum es schwierig ist, etwas für einen unsophistizierten Benutzer zu entwerfen. Es ist schwer, an etwas interessiert zu bleiben, das dir selbst nicht gefällt. Um etwas Gutes zu machen, musst du denken: "Wow, das ist wirklich großartig," nicht "Was für ein Stück Scheiße; diese Narren werden es lieben."

Design bedeutet, Dinge für Menschen zu machen. Aber nicht nur der Benutzer ist menschlich. Der Designer ist auch menschlich.

Beachte, dass ich die ganze Zeit von "dem Designer" gesprochen habe. Design muss normalerweise unter der Kontrolle einer einzelnen Person stehen, um gut zu sein. Und doch scheint es möglich zu sein, dass mehrere Personen an einem Forschungsprojekt zusammenarbeiten. Das scheint mir einer der interessantesten Unterschiede zwischen Forschung und Design zu sein.

Es gab berühmte Beispiele für Zusammenarbeit in den Künsten, aber die meisten scheinen Fälle von molekularer Bindung zu sein, anstatt von nuklearer Fusion. In einer Oper ist es üblich, dass eine Person das Libretto schreibt und eine andere die Musik. Und während der Renaissance wurden oft Gesellen aus Nordeuropa beschäftigt, um die Landschaften im Hintergrund italienischer Gemälde zu machen. Aber das sind keine echten Kooperationen. Sie sind eher Beispiele für Robert Frosts "gute Zäune machen gute Nachbarn." Du kannst Beispiele für gutes Design zusammenfügen, aber innerhalb jedes einzelnen Projekts muss eine Person die Kontrolle haben.

Ich sage nicht, dass gutes Design erfordert, dass eine Person an alles denkt. Es gibt nichts Wertvolleres als den Rat von jemandem, dessen Urteil du vertraust. Aber nachdem das Reden vorbei ist, muss die Entscheidung darüber, was zu tun ist, bei einer Person liegen.

Warum kann Forschung von Mitarbeitern durchgeführt werden und Design nicht? Das ist eine interessante Frage. Ich kenne die Antwort nicht. Vielleicht, wenn Design und Forschung konvergieren, ist die beste Forschung auch gutes Design und kann in der Tat nicht von Mitarbeitern durchgeführt werden. Viele der berühmtesten Wissenschaftler scheinen allein gearbeitet zu haben. Aber ich weiß nicht genug, um zu sagen, ob es hier ein Muster gibt. Es könnte einfach sein, dass viele berühmte Wissenschaftler in einer Zeit arbeiteten, in der Zusammenarbeit weniger verbreitet war.

Was auch immer die Geschichte in den Wissenschaften ist, echte Zusammenarbeit scheint in den Künsten äußerst selten zu sein. Design durch Komitee ist ein Synonym für schlechtes Design. Warum ist das so? Gibt es irgendeinen Weg, diese Einschränkung zu überwinden?

Ich neige dazu zu denken, dass es das nicht gibt – dass gutes Design einen Diktator erfordert. Ein Grund ist, dass gutes Design aus einem Guss sein muss. Design ist nicht nur für Menschen, sondern für individuelle Menschen. Wenn ein Design eine Idee darstellt, die in den Kopf einer Person passt, dann wird die Idee auch im Kopf des Benutzers passen.

Verwandt: