DESIGN UND FORSCHUNG

Januar 2003

(Dieser Artikel basiert auf einem Grundsatzvortrag der NEPLS-Tagung im Herbst 2002.)

Besucher dieses Landes sind oft überrascht, dass Amerikaner ein Gespräch gerne mit der Frage „Was machen Sie beruflich?“ beginnen. Mir hat diese Frage noch nie gefallen. Ich habe selten eine nette Antwort darauf bekommen. Aber ich glaube, ich habe das Problem endlich gelöst. Wenn mich jetzt jemand fragt, was ich mache, schaue ich ihm direkt in die Augen und sage: „Ich entwerfe einen neuen Lisp-Dialekt .“ Diese Antwort empfehle ich jedem, der nicht gerne gefragt wird, was er macht. Das Gespräch wird sich dann sofort anderen Themen zuwenden.

Ich betrachte mich nicht als jemanden, der Programmiersprachen erforscht. Ich entwerfe nur eine, so wie jemand ein Gebäude, einen Stuhl oder eine neue Schriftart entwirft. Ich versuche nicht, etwas Neues zu entdecken. Ich möchte nur eine Sprache schaffen, in der man gut programmieren kann. 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 laufen an der Spitze zusammen: Das beste Design übertrifft seine Vorgänger durch die Verwendung neuer Ideen, und die beste Forschung löst Probleme, die nicht nur neu sind, sondern es tatsächlich wert sind, gelöst zu werden. Letztendlich streben wir also dasselbe Ziel an, nähern uns ihm nur aus unterschiedlichen Richtungen.

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

Der größte Unterschied besteht darin, dass Sie sich stärker auf den Benutzer konzentrieren. Beim Design beginnt man mit der Frage: Für wen ist das gedacht und was braucht der Benutzer davon? Ein guter Architekt beispielsweise beginnt nicht damit, ein Design zu entwerfen, das er dann den Benutzern aufdrängt, sondern er studiert die beabsichtigten Benutzer und findet heraus, was sie brauchen.

Beachten Sie, dass ich „was sie brauchen“ und nicht „was sie wollen“ gesagt habe. Ich möchte nicht den Eindruck erwecken, dass die Arbeit als Designer bedeutet, eine Art Schnellkoch zu sein und alles zu machen, was der Kunde von Ihnen verlangt. Das ist in den Künsten von Bereich zu Bereich unterschiedlich, aber ich glaube nicht, dass es einen Bereich gibt, in dem die beste Arbeit von den Leuten geleistet wird, die genau das machen, was der Kunde von ihnen verlangt.

Der Kunde hat immer Recht, denn gutes Design wird daran gemessen, wie gut es für den Benutzer funktioniert. Wenn Sie einen Roman schreiben, der alle langweilt, oder einen Stuhl, auf dem man schrecklich unbequem sitzt, dann haben Sie einfach schlechte Arbeit geleistet. Es ist keine Verteidigung, wenn man sagt, der Roman oder der Stuhl sei nach den fortschrittlichsten theoretischen Prinzipien entworfen worden.

Und doch bedeutet das, was für den Benutzer funktioniert, nicht einfach das zu tun, was der Benutzer Ihnen sagt. Benutzer kennen nicht alle Möglichkeiten und liegen oft falsch, was sie wirklich wollen.

Die Antwort auf dieses Paradoxon ist meiner Meinung nach, dass man für den Benutzer designen muss, aber man muss designen, was der Benutzer braucht, und nicht einfach, was er sagt, dass er will. Das ist wie beim Arzt. Man kann nicht einfach die Symptome eines Patienten behandeln. Wenn ein Patient Ihnen seine Symptome schildert, muss man herausfinden, was ihm wirklich fehlt, und das behandeln.

Dieser Fokus auf den Benutzer ist eine Art Axiom, aus dem sich ein Großteil der Praxis guten Designs ableiten lässt und um das sich die meisten Designprobleme drehen.

Wenn gutes Design das tun muss, was der Benutzer braucht, wer ist dann der Benutzer? Wenn ich sage, dass Design für Benutzer sein muss, meine ich damit nicht, dass gutes Design auf irgendeine Art kleinsten gemeinsamen Nenner abzielt. Sie können jede beliebige Benutzergruppe auswählen. Wenn Sie beispielsweise ein Werkzeug entwerfen, können Sie es für jeden entwerfen, vom Anfänger bis zum Experten, und was für eine Gruppe ein gutes Design ist, kann für eine andere schlecht sein. Der Punkt ist, dass Sie eine bestimmte Benutzergruppe auswählen müssen. Ich glaube nicht, dass man überhaupt von gutem oder schlechtem Design sprechen kann, außer in Bezug auf einen bestimmten beabsichtigten Benutzer.

Ein gutes Design erhalten Sie am ehesten, wenn zu den vorgesehenen Benutzern auch der Designer selbst gehört. Wenn Sie etwas für eine Gruppe entwerfen, zu der Sie nicht gehören, ist es eher für Leute gedacht, die Sie für weniger anspruchsvoll halten und nicht für anspruchsvoller als Sie.

Das ist ein Problem, denn wenn man auf den Benutzer herabsieht, so wohlwollend man auch sein mag, scheint das den Designer unweigerlich zu korrumpieren. Ich vermute, dass nur sehr wenige Wohnbauprojekte in den USA von Architekten entworfen wurden, die erwarteten, darin zu leben. Dasselbe kann man bei Programmiersprachen beobachten. C, Lisp und Smalltalk wurden für die Verwendung durch ihre eigenen Designer geschaffen. Cobol, Ada und Java wurden für die Verwendung durch andere Leute geschaffen.

Wenn Sie meinen, Sie entwerfen etwas für Idioten, ist die Wahrscheinlichkeit groß, dass Sie nichts Gutes entwerfen, nicht einmal für Idioten.

Selbst wenn Sie etwas für die anspruchsvollsten Benutzer entwerfen, entwerfen Sie es dennoch für Menschen. In der Forschung ist das anders. In der Mathematik wählt man keine Abstraktionen, weil sie für Menschen leicht zu verstehen sind; man wählt die, die den Beweis kürzer machen. Ich denke, das gilt für die Wissenschaften im Allgemeinen. Wissenschaftliche Ideen sollen nicht ergonomisch sein.

In der Kunst sieht es ganz anders aus. Beim Design dreht sich alles um Menschen. Der menschliche Körper ist ein seltsames Ding, aber wenn man einen Stuhl entwirft, dann ist das eben das, wofür man designt, und daran führt kein Weg vorbei. Alle Künste müssen sich den Interessen und Grenzen des Menschen anpassen. In der Malerei zum Beispiel ist ein Gemälde mit Menschen interessanter als eines ohne, wenn alle anderen Bedingungen gleich sind. Es ist kein bloßer Zufall der Geschichte, dass die großen Gemälde der Renaissance alle voller Menschen sind. Wäre das nicht der Fall, hätte die Malerei als Medium nicht das Prestige, das sie heute hat.

Ob es einem gefällt oder nicht, Programmiersprachen sind auch für Menschen gedacht, 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, andere nicht. Wir scheinen zum Beispiel nur eine sehr begrenzte Fähigkeit zu haben, mit Details umzugehen. Das ist es, was Programmiersprachen überhaupt erst 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 für beide Situationen unterschiedliche Medien benötigen. Marmor ist beispielsweise ein schönes, haltbares Medium für fertige Ideen, aber ein hoffnungslos unflexibles Medium für die Entwicklung neuer Ideen.

Ein Programm ist, wie ein Beweis, eine beschnittene Version eines Baumes, der in der Vergangenheit Fehlstarts hatte, die sich überall verzweigten. Der Test einer Sprache besteht also nicht einfach darin, wie sauber das fertige Programm darin aussieht, sondern wie sauber der Weg zum fertigen Programm war. Eine Designentscheidung, die Ihnen elegante fertige Programme liefert, führt möglicherweise nicht zu einem eleganten Designprozess. Ich habe zum Beispiel einige Makrodefinitionsmakros voller verschachtelter Backquotes geschrieben, die jetzt wie kleine Juwelen aussehen, aber sie zu schreiben, hat Stunden des hässlichsten Ausprobierens gekostet, und ehrlich gesagt bin ich mir immer noch nicht ganz sicher, ob sie richtig sind.

Wir tun oft so, als ob der Test einer Sprache darin bestünde, wie gut fertige Programme in ihr aussehen. Es wirkt so überzeugend, wenn man dasselbe Programm in zwei Sprachen geschrieben sieht und eine Version viel kürzer ist. Wenn man das Problem aus künstlerischer Sicht angeht, ist es weniger wahrscheinlich, dass man sich auf diese Art von Test verlässt. Man möchte schließlich nicht mit einer Programmiersprache wie Marble enden.

Beispielsweise ist es bei der Softwareentwicklung ein großer Vorteil, eine interaktive Toplevel-Schleife zu haben, die in Lisp als Read-Eval-Print-Schleife bezeichnet wird. Und wenn Sie eine solche haben, hat dies echte Auswirkungen auf das Design der Sprache. Sie würde beispielsweise für eine Sprache nicht gut funktionieren, in der Sie Variablen deklarieren müssen, bevor Sie sie verwenden. Wenn Sie nur Ausdrücke in die Toplevel-Schleife eingeben, möchten Sie x auf einen Wert setzen und dann anfangen, Dinge mit x zu tun. Sie möchten nicht zuerst den Typ von x deklarieren müssen. Sie können jede der Prämissen anfechten, aber wenn eine Sprache eine Toplevel-Schleife haben muss, um praktisch zu sein, und obligatorische Typdeklarationen mit einer Toplevel-Schleife inkompatibel sind, dann könnte keine Sprache, die Typdeklarationen obligatorisch macht, praktisch zum Programmieren sein.

Um ein gutes Design zu erhalten, müssen Sie in der Praxis nah an Ihren Benutzern sein und nah bei ihnen bleiben. Sie müssen Ihre Ideen ständig auf die tatsächlichen Benutzer abstimmen, besonders am Anfang. Einer der Gründe, warum Jane Austens Romane so gut sind, ist, dass sie sie ihrer Familie vorgelesen hat. Deshalb versinkt sie nie in selbstgefälligen, kunstvollen Landschaftsbeschreibungen oder überheblichem Philosophieren. (Die Philosophie ist da, aber sie ist in die Geschichte eingewoben, anstatt wie ein Etikett darauf geklebt zu sein.) Wenn Sie einen durchschnittlichen „literarischen“ Roman aufschlagen und sich vorstellen, ihn Ihren Freunden vorzulesen, als ob Sie ihn selbst geschrieben hätten, werden Sie nur zu deutlich spüren, was für eine Zumutung das für den Leser ist.

In der Softwarewelt ist diese Idee als „Schlimmer ist besser“ bekannt. Tatsächlich sind mehrere Ideen in dem Konzept „Schlimmer ist besser“ vermischt, weshalb die Leute immer noch darüber streiten, ob „schlimmer“ tatsächlich „besser“ ist oder nicht. Aber eine der Hauptideen in dieser Mischung ist, dass Sie, wenn Sie etwas Neues bauen, den Benutzern so schnell wie möglich einen Prototyp präsentieren sollten.

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

Was Menschen außerhalb der Softwarewelt vielleicht nicht wissen, ist, dass der Grundsatz „Schlimmer ist besser“ in allen Künsten zu finden ist. Beim Zeichnen beispielsweise wurde dieser Grundsatz während der Renaissance entdeckt. Heute wird Ihnen fast jeder Zeichenlehrer sagen, dass der richtige Weg zu einer genauen Zeichnung nicht darin besteht, sich langsam um die Kontur eines Objekts herumzuarbeiten, da sich die Fehler sonst anhäufen und Sie am Ende feststellen werden, dass die Linien nicht zusammentreffen. Stattdessen sollten Sie ein paar schnelle Linien an ungefähr der richtigen Stelle zeichnen und diese anfängliche Skizze dann schrittweise verfeinern.

In den meisten Bereichen wurden Prototypen traditionell aus unterschiedlichen Materialien hergestellt. In Metall zu schneidende Schriftarten wurden zunächst mit einem Pinsel auf Papier entworfen. 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 die Ölmalerei so spannend machte, als sie im 15. Jahrhundert zum ersten Mal populär wurde, war, dass man das fertige Werk tatsächlich vom Prototypen aus anfertigen konnte. Man konnte eine vorläufige Zeichnung anfertigen, wenn man wollte, aber man war nicht daran gebunden; man konnte alle Details ausarbeiten und sogar größere Änderungen vornehmen, während man das Gemälde fertigstellte.

Das ist auch mit Software möglich. Ein Prototyp muss nicht nur ein Modell sein; man kann ihn bis zum fertigen Produkt verfeinern. Ich finde, das sollte man immer tun, wenn man kann. So kann man von neuen Erkenntnissen profitieren, die man unterwegs gewonnen hat. Aber was vielleicht noch wichtiger ist: Es ist gut für die Moral.

Die Moral ist der Schlüssel zum Design. Ich bin überrascht, dass die Leute nicht mehr darüber reden. Einer meiner ersten Zeichenlehrer sagte mir: Wenn Sie sich beim Zeichnen langweilen, wird die Zeichnung langweilig aussehen. Nehmen wir zum Beispiel an, Sie müssen ein Gebäude zeichnen und beschließen, jeden Stein einzeln zu zeichnen. Sie können das tun, wenn Sie möchten, aber wenn Sie sich auf halbem Weg langweilen und anfangen, die Steine mechanisch herzustellen, anstatt jeden einzelnen zu betrachten, wird die Zeichnung schlechter aussehen, als wenn Sie die Steine nur angedeutet hätten.

Etwas zu bauen, indem man einen Prototyp nach und nach verfeinert, ist gut für die Moral, weil es einen bei der Sache hält. Bei Software lautet meine Regel: Immer funktionierenden Code haben. Wenn man etwas schreibt, das man in einer Stunde testen kann, hat man die Aussicht auf eine sofortige Belohnung, die einen motiviert. Dasselbe gilt in der Kunst und insbesondere in der Ölmalerei. Die meisten Maler beginnen mit einer verschwommenen Skizze und verfeinern sie nach und nach. Wenn man so arbeitet, muss man den Tag im Prinzip 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 schon einmal an Software gearbeitet hat.

Die Moral ist ein weiterer Grund, warum es schwierig ist, etwas für einen unbedarften Benutzer zu entwickeln. Es ist schwer, das Interesse an etwas aufrechtzuerhalten, das man selbst nicht mag. Um etwas Gutes zu machen, muss man denken: „Wow, das ist wirklich toll“, und nicht: „Was für ein Scheiß; diese Idioten werden es lieben.“

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

Beachten Sie, dass ich die ganze Zeit über „den Designer“ gesprochen habe. Design muss normalerweise unter der Kontrolle einer einzelnen Person stehen, um gut zu sein. Und dennoch scheint es möglich zu sein, dass mehrere Personen an einem Forschungsprojekt zusammenarbeiten. Dies scheint mir einer der interessantesten Unterschiede zwischen Forschung und Design zu sein.

Es gibt berühmte Beispiele für Zusammenarbeit in der Kunst, aber die meisten davon scheinen eher Fälle von molekularer Bindung als von Kernfusion gewesen zu sein. Bei 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 damit beauftragt, die Landschaften im Hintergrund italienischer Gemälde zu gestalten. Aber das sind keine echten Kooperationen. Sie ähneln eher Beispielen für Robert Frosts „Gute Zäune machen gute Nachbarn“. Man kann Beispiele guten Designs zusammenfügen, aber bei jedem einzelnen Projekt muss eine Person die Kontrolle haben.

Ich sage nicht, dass für gutes Design eine Person an alles denken muss. Es gibt nichts Wertvolleres als den Rat einer Person, deren Urteil man vertraut. Aber nachdem das Gespräch beendet ist, muss die Entscheidung darüber, was zu tun ist, bei einer Person liegen.

Warum kann Forschung von Mitarbeitern durchgeführt werden, Design jedoch nicht? Das ist eine interessante Frage. Ich kenne die Antwort nicht. Wenn Design und Forschung zusammentreffen, ist die beste Forschung vielleicht 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 sagen zu können, ob es hier ein Muster gibt. Es könnte einfach sein, dass viele berühmte Wissenschaftler zu einer Zeit arbeiteten, als Zusammenarbeit noch weniger üblich war.

Was auch immer in den Wissenschaften der Fall ist, echte Zusammenarbeit scheint in den Künsten verschwindend selten zu sein. Design durch Komitees ist gleichbedeutend mit schlechtem Design. Warum ist das so? Gibt es eine Möglichkeit, diese Einschränkung zu überwinden?

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