DESIGN UND FORSCHUNG

January 2003

(Dieser Artikel basiert auf einem Vortrag, der auf der Herbsttagung 2002 von NEPLS gehalten wurde.)

Besucher in diesem Land sind oft überrascht, dass Amerikaner gerne ein Gespräch mit der Frage beginnen: "Was machst du?" Ich habe diese Frage nie gemocht. Ich hatte selten eine klare Antwort darauf. Aber ich glaube, ich habe das Problem endlich gelöst. Wenn mich jetzt jemand fragt, was ich tue, schaue ich ihm direkt in die Augen und sage: "Ich entwerfe eine neue Lisp-Dialekt." Ich empfehle diese Antwort jedem, der es nicht mag, gefragt zu werden, was er tut. Das Gespräch wird sofort auf andere Themen gelenkt.

Ich betrachte mich nicht als Forscher in Programmiersprachen. Ich entwerfe nur eine, so wie jemand ein Gebäude, einen Stuhl oder eine neue Schriftart entwerfen könnte. Ich versuche nicht, etwas Neues zu entdecken. Ich möchte nur eine Sprache schaffen, die gut zum Programmieren ist. In gewisser Weise macht diese Annahme das Leben viel einfacher.

Der Unterschied zwischen Design und Forschung scheint eine Frage von Neuem versus Gutem 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 konvergieren 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 sind, sondern auch tatsächlich lösenswert sind. Letztendlich zielen wir also auf dasselbe Ziel, nähern uns ihm aber aus verschiedenen Richtungen.

Worüber ich heute sprechen werde, ist, wie Ihr Ziel von hinten aussieht. Was machen Sie anders, wenn Sie Programmiersprachen als Designproblem anstatt als Forschungsthema behandeln?

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

Beachten Sie, dass ich "was sie brauchen" sagte, nicht "was sie wollen". Ich möchte nicht den Eindruck erwecken, dass die Arbeit als Designer bedeutet, als eine Art Schnellkoch zu arbeiten, der das macht, was der Kunde ihm sagt. Dies variiert von Feld zu Feld in den Künsten, aber ich glaube, es gibt kein Feld, in dem die beste Arbeit von denjenigen geleistet wird, die genau das machen, was die Kunden ihnen sagen.

Der Kunde ist immer richtig in dem Sinne, dass das Maß für gutes Design darin besteht, wie gut es funktioniert für den Benutzer. Wenn Sie einen Roman schreiben, der jeden langweilt, oder einen Stuhl der schrecklich unbequem zum Sitzen ist, dann haben Sie einen schlechten Job gemacht, Punkt. Es ist keine Verteidigung zu sagen, dass der Roman oder der Stuhl nach den fortschrittlichsten theoretischen Prinzipien entworfen ist.

Und doch bedeutet das Erstellen von etwas, das für den Benutzer funktioniert, nicht einfach das Erstellen von dem, was der Benutzer Ihnen sagt. Benutzer wissen nicht, welche Möglichkeiten es gibt und irren sich oft darüber, was sie wirklich wollen.

Die Antwort auf das Paradoxon ist meiner Meinung nach, dass man für den Benutzer entwerfen muss, aber man muss das entwerfen, was der Benutzer braucht, nicht einfach das, was er sagt, dass er will. Es ist ähnlich wie ein Arzt zu sein. Man kann nicht einfach die Symptome eines Patienten behandeln. Wenn ein Patient Ihnen seine Symptome erzählt, müssen Sie herausfinden, was tatsächlich mit ihm nicht stimmt, und das behandeln.

Dieser Fokus auf den Benutzer ist eine Art Axiom, aus dem sich die meisten Praktiken guten Designs ableiten lassen und um das sich die meisten Designprobleme 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 kleinsten gemeinsamen Nenner zielt. Sie können jede Gruppe von Benutzern auswählen, die Sie möchten. Wenn Sie beispielsweise ein Werkzeug entwerfen, können Sie es entwerfen für jeden von Anfängern bis zu Experten, und was gutes Design ist für die eine Gruppe könnte für die andere schlecht sein. Der Punkt ist, Sie müssen sich für eine Gruppe von Benutzern entscheiden. Ich glaube nicht, dass man über gutes oder schlechtes Design sprechen kann, außer mit Bezug auf einen bestimmten Benutzer.

Sie erhalten am wahrscheinlichsten gutes Design, wenn die beabsichtigten Benutzer den Designer selbst einschließen. Wenn Sie etwas entwerfen für eine Gruppe, die Sie nicht einschließt, dann ist es in der Regel für Menschen die Sie für weniger klug halten als Sie, nicht für klügere.

Das ist ein Problem, denn auf den Benutzer herabzuschauen, so wohlwollend auch immer, scheint den Designer unweigerlich zu verderben. Ich vermute, dass nur sehr wenige Wohnprojekte in den USA wurden von Architekten entworfen, die erwarteten, darin zu leben. Sie können dasselbe sehen in Programmiersprachen. C, Lisp und Smalltalk wurden für ihre eigenen Designer geschaffen. Cobol, Ada und Java wurden für andere Leute geschaffen.

Wenn Sie denken, dass Sie etwas für Idioten entwerfen, dann ist die Wahrscheinlichkeit groß, dass Sie nichts Gutes entwerfen, selbst für Idioten.

Auch wenn Sie etwas für die anspruchsvollsten Benutzer entwerfen, entwerfen Sie immer noch für Menschen. Es ist anders in der Forschung. In der Mathematik wählen Sie Abstraktionen nicht, weil sie für Menschen leicht zu verstehen sind; Sie wählen diejenigen, die die Beweise kürzer machen. Ich denke, das gilt allgemein für die Wissenschaften. Wissenschaftliche Ideen sollen nicht ergonomisch sein.

In den Künsten ist das ganz anders. Design ist alles dreht sich um Menschen. Der menschliche Körper ist ein seltsames Ding, aber wenn Sie einen Stuhl entwerfen, dann ist das, wofür Sie entwerfen, und es gibt keinen Weg daran vorbei. Alle Künste müssen sich den Interessen und Grenzen anpassen von Menschen. In der Malerei zum Beispiel, unter sonst gleichen Bedingungen, ein Gemälde mit Menschen darin wird interessanter sein als eines ohne. Es ist nicht nur ein Zufall der Geschichte, dass die großen Gemälde der Renaissance sind alle voller Menschen. Wenn sie es nicht gewesen wären, hätte die Malerei als Medium nicht das Prestige das sie hat.

Ob es uns gefällt oder nicht, Programmiersprachen sind auch für Menschen da, und ich vermute, dass das menschliche Gehirn genauso klumpig und eigenwillig ist wie der menschliche Körper. Manche Ideen sind für Menschen leicht zu verstehen und manche nicht. Zum Beispiel scheinen wir eine sehr begrenzte Fähigkeit zu haben, mit Details umzugehen. Es ist diese Tatsache, die Programmiersprachen zu einer guten Idee macht; wenn wir mit den Details umgehen könnten, könnten wir einfach in Maschinensprache programmieren.

Denken Sie auch daran, dass Sprachen nicht in erster Linie eine Form für fertige Programme sind, sondern etwas, in dem Programme entwickelt werden müssen. Jeder in den Künsten könnte Ihnen sagen, dass Sie möglicherweise verschiedene Medien für die beiden Situationen benötigen. Marmor zum Beispiel ist ein schönes, haltbares 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 verzweigt waren. Also die Prüfung von einer Sprache ist nicht einfach, wie sauber das fertige Programm aussieht in ihr, sondern wie sauber der Weg zum fertigen Programm war. Eine Designentscheidung, die Ihnen elegante fertige Programme liefert, liefert Ihnen möglicherweise keinen eleganten Designprozess. Zum Beispiel, Ich habe ein paar makrodefinierende Makros voller verschachtelter Backquotes geschrieben, die jetzt wie kleine Juwelen aussehen, aber sie zu schreiben dauerte Stunden des hässlichsten Trial-and-Error, und ehrlich gesagt, ich bin immer noch nicht ganz sicher, ob sie korrekt sind.

Wir tun oft so, als ob die Prüfung einer Sprache wäre, wie gut fertige Programme darin aussehen. Es scheint so überzeugend, wenn man dasselbe Programm sieht in zwei Sprachen geschrieben, und die eine Version ist viel kürzer. Wenn Sie das Problem aus der Richtung der Künste angehen, sind Sie weniger geneigt, sich auf diese Art von Test zu verlassen. Sie wollen nicht mit einer Programmierung enden Sprache wie Marmor.

Zum Beispiel ist es ein großer Gewinn bei der Entwicklung von Software, einen interaktiven Toplevel zu haben, was in Lisp als Read-Eval-Print-Schleife bezeichnet wird. Und wenn Sie einen haben, hat dies reale Auswirkungen auf das Design der Sprache. Es würde nicht gut funktionieren für eine Sprache, in der Sie Variablen deklarieren müssen, bevor Sie sie verwenden, zum Beispiel. Wenn Sie nur Ausdrücke in den Toplevel eintippen, möchten Sie in der Lage sein, x auf einen bestimmten Wert zu setzen und dann Dinge mit x zu tun. Sie möchten nicht den Typ von x deklarieren müssen zuerst. Sie können entweder die Prämissen bestreiten, aber wenn eine Sprache einen Toplevel haben muss, um bequem zu sein, und obligatorische Typdeklarationen sind nicht mit einem Toplevel kompatibel, dann könnte keine Sprache, die Typdeklarationen obligatorisch macht, bequem zum Programmieren sein.

In der Praxis müssen Sie, um gutes Design zu erhalten, nah dran sein und bleiben an Ihren Benutzern. Sie müssen Ihre 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 ihren Familien laut vorlas. Deshalb versinkt sie nie in selbstverliebt künstlerischen Beschreibungen von Landschaften, oder anmaßender Philosophie. (Die Philosophie ist da, aber sie ist in die Geschichte eingewebt, anstatt wie ein Etikett darauf geklebt zu werden.) Wenn Sie einen durchschnittlichen "literarischen" Roman öffnen und sich vorstellen, ihn Ihren Freunden laut vorzulesen als etwas, das Sie geschrieben haben, werden Sie nur zu deutlich spüren, was für eine Zumutung diese Art von Ding für den Leser ist.

In der Softwarewelt ist diese Idee als Worse is Better bekannt. Tatsächlich gibt es mehrere Ideen, die im Konzept von Worse is Better vermischt sind, weshalb die Leute immer noch darüber streiten, ob schlechter tatsächlich besser ist oder nicht. Aber eine der Hauptideen in dieser Mischung ist, dass Sie, wenn Sie etwas Neues bauen, ein Prototyp vor Benutzern so schnell wie möglich.

Der alternative Ansatz könnte als Hail Mary-Strategie bezeichnet werden. Anstatt schnell einen Prototypen zu erstellen und ihn schrittweise zu verfeinern, versuchen Sie, 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 selbst zerstört während der Internetblase. Ich habe noch nie von einem Fall gehört wo es funktioniert hat.

Was Menschen außerhalb der Softwarewelt vielleicht nicht wissen, ist, dass Worse is Better in allen Künsten zu finden ist. Im Zeichnen zum Beispiel wurde die Idee während der Renaissance entdeckt. Jetzt wird Ihnen fast jeder Zeichenlehrer sagen, dass der richtige Weg, um eine genaue Zeichnung zu erhalten, nicht darin besteht, sich langsam um die Kontur eines Objekts zu bewegen, weil Fehler sich ansammeln und Sie am Ende feststellen werden, dass sich die Linien nicht treffen. Stattdessen sollten Sie ein paar schnelle Linien an ungefähr der richtigen Stelle zeichnen, und dann diese erste Skizze schrittweise verfeinern.

In den meisten Bereichen, Prototypen wurden traditionell aus verschiedenen Materialien hergestellt. Schriftarten, die in Metall geschnitten werden sollten, wurden zunächst entworfen mit einem Pinsel auf Papier. Statuen, die in Bronze gegossen werden sollten, wurden in Wachs modelliert. Muster, die auf Wandteppiche gestickt werden sollten, wurden mit Tusche auf Papier gezeichnet. Gebäude, die aus Stein gebaut werden sollten, wurden in kleinerem Maßstab in Holz getestet.

Was Ölfarbe so aufregend machte, als sie erstmals im 15. Jahrhundert populär wurde, war, dass man das fertige Werk aus dem Prototyp machen konnte. Sie konnten eine Vorzeichnung machen, wenn Sie wollten, aber Sie waren nicht daran gebunden; Sie konnten alle Details ausarbeiten und sogar größere Änderungen vornehmen, während Sie das Gemälde fertigstellten.

Das können Sie auch in Software machen. Ein Prototyp muss nicht nur ein Modell sein; Sie können es zum fertigen Produkt verfeinern. Ich denke, Sie sollten das immer tun, wenn Sie können. Es ermöglicht Ihnen neue Erkenntnisse zu nutzen, die Sie auf dem Weg dorthin gewinnen. Aber vielleicht noch wichtiger, es ist gut für die Moral.

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 Sie sich langweilen, wenn Sie etwas zeichnen, wird die Zeichnung langweilig aussehen. Nehmen wir zum Beispiel an, Sie müssen ein Gebäude zeichnen, und Sie entscheiden sich, jeden Ziegel einzeln zu zeichnen. Sie können das tun wenn Sie wollen, aber wenn Sie auf halbem Weg gelangweilt sind und anfangen, die Ziegel mechanisch zu machen, anstatt jeden einzelnen zu beobachten, wird die Zeichnung schlechter aussehen, als wenn Sie nur die Ziegel angedeutet hätten.

Etwas zu bauen, indem man einen Prototypen schrittweise verfeinert, ist gut für die Moral, weil es Sie beschäftigt hält. In der Software, meine Regel ist: Haben Sie immer funktionierenden Code. Wenn Sie schreiben etwas, das Sie in einer Stunde testen können, dann haben Sie die Aussicht auf eine sofortige Belohnung, die Sie motiviert. Dasselbe gilt für die Künste, und insbesondere für die Ölmalerei. Die meisten Maler beginnen mit einer verschwommenen Skizze und verfeinern sie schrittweise. Wenn Sie auf diese Weise arbeiten, dann im Prinzip müssen Sie den Tag nie mit etwas beenden, das tatsächlich unfertig aussieht. Tatsächlich gibt es unter Malern sogar ein Sprichwort: "Ein Gemälde ist nie fertig, man hört einfach auf, daran zu arbeiten." Diese Idee wird jedem bekannt sein, der an Software gearbeitet hat.

Moral ist ein weiterer Grund, warum es schwierig ist, etwas zu entwerfen für einen unsophisticated Benutzer. Es ist schwer, sich für etwas zu interessieren, das man selbst nicht mag. Um etwas zu machen Gutes, man muss denken: "Wow, das ist wirklich toll", nicht "Was für ein Stück Scheiße; diese Idioten werden es lieben."

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

Beachten Sie, dass ich die ganze Zeit über "den Designer" gesprochen habe. Design muss in der Regel unter der Kontrolle einer einzigen 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.

Es gab berühmte Beispiele für Zusammenarbeit in den Künsten, aber die meisten von ihnen scheinen Fälle von molekularer Bindung gewesen zu sein, anstatt von Kernfusion. In einer Oper ist es üblich, dass eine Person das Libretto schreibt und eine andere die Musik. Und während der Renaissance, Handwerker aus dem Norden Europas wurden oft beschäftigt, um die Landschaften in den Hintergründen italienischer Gemälde zu malen. Aber das sind keine echten Kooperationen. Sie sind eher Beispiele für Robert Frosts "gute Zäune machen gute Nachbarn". Man kann Instanzen von gutem Design zusammenfügen, aber innerhalb jedes einzelnen Projekts, eine Person muss die Kontrolle haben.

Ich sage nicht, dass gutes Design erfordert, dass eine Person sich alles ausdenkt. Es gibt nichts Wertvolleres als den Rat von jemandem, dessen Urteil Sie vertrauen. 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 weiß nicht die Antwort. Vielleicht, wenn Design und Forschung konvergieren, ist die beste Forschung auch gutes Design, und kann tatsächlich 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 arbeiteten, als Zusammenarbeit weniger verbreitet war.

Was auch immer die Geschichte in den Wissenschaften ist, echte Zusammenarbeit scheint in den Künsten verschwindend selten zu sein. Design by Committee ist ein Synonym für schlechtes Design. Warum ist das so? Gibt es eine Möglichkeit, diese Einschränkung zu überwinden?

Ich neige dazu zu denken, dass es keine gibt - dass gutes Design erfordert einen Diktator. Ein Grund ist, dass gutes Design ein Ganzes sein muss. Design ist nicht nur für Menschen, sondern für einzelne Menschen. Wenn ein Design eine Idee repräsentiert, die in den Kopf einer Person passt, dann passt die Idee auch in den Kopf des Benutzers.