Design und Forschung | undefined | Paul Grahams Essays

Januar 2003

(Dieser Artikel basiert auf einer Keynote-Präsentation auf der NEPLS-Herbsttagung 2002.)

Besucher dieses Landes sind oft überrascht, dass Amerikaner ein Gespräch gerne damit beginnen, zu fragen: „Was machen Sie beruflich?“ Ich mochte diese Frage nie. Ich hatte selten eine passende Antwort darauf. Aber ich glaube, ich habe das Problem endlich gelöst. Wenn mich jetzt jemand fragt, was ich mache, sehe ich ihm direkt in die Augen und sage: „Ich entwerfe eine neue Lisp-Dialekt.“ Ich empfehle diese Antwort jedem, der nicht gerne gefragt wird, was er tut. Das Gespräch wird sich sofort auf andere Themen verlagern.

Ich betrachte mich nicht als Forscher im Bereich 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 einfach eine Sprache schaffen, die gut zum Programmieren ist. In gewisser Weise erleichtert diese Annahme das Leben erheblich.

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 glaube, diese beiden Wege konvergieren oben: Das beste Design übertrifft seine Vorgänger, indem es neue Ideen nutzt, und die beste Forschung löst Probleme, die nicht nur neu, sondern auch tatsächlich lohnenswert sind. Letztendlich streben wir also dasselbe Ziel an, 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 ist, dass Sie sich mehr auf den Benutzer konzentrieren. Design beginnt mit der Frage: Für wen ist das gedacht und was braucht er 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“ und nicht „was sie wollen“ gesagt habe. Ich möchte nicht den Eindruck erwecken, dass die Arbeit als Designer bedeutet, als eine Art Schnellkoch zu arbeiten, der genau das macht, was der Kunde sagt. Dies variiert von Bereich zu Bereich in den Künsten, aber ich glaube nicht, dass es irgendeinen Bereich gibt, in dem die beste Arbeit von den Leuten gemacht wird, die einfach genau das machen, was die Kunden ihnen sagen.

Der Kunde hat immer Recht in dem Sinne, dass das Maß für gutes Design darin besteht, 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 schlechte Arbeit geleistet, Punkt. Es ist keine Entschuldigung zu sagen, dass der Roman oder der Stuhl nach den fortschrittlichsten theoretischen Prinzipien entworfen wurde.

Und doch bedeutet das, was für den Benutzer funktioniert, nicht einfach nur das zu machen, was der Benutzer Ihnen sagt. Benutzer kennen nicht alle Möglichkeiten und irren sich oft darüber, was sie wirklich wollen.

Die Antwort auf das Paradoxon, denke ich, ist, dass man für den Benutzer entwerfen muss, aber man muss entwerfen, was der Benutzer braucht, nicht einfach, was er zu wollen vorgibt. Es ist sehr ähnlich wie bei einem Arzt. Man kann nicht einfach die Symptome eines Patienten behandeln. Wenn ein Patient Ihnen seine Symptome nennt, müssen Sie herausfinden, was wirklich mit ihm los ist, und das behandeln.

Dieser Fokus auf den Benutzer ist eine Art Axiom, von dem sich die meiste Praxis guten Designs ableiten lässt und um das sich die meisten Designfragen 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 nicht, dass gutes Design auf eine Art kleinsten gemeinsamen Nenner abzielt. Sie können jede beliebige Benutzergruppe auswählen. Wenn Sie zum Beispiel ein Werkzeug entwerfen, können Sie es für jeden entwerfen, vom Anfänger bis zum Experten, und was für die eine Gruppe gutes Design ist, kann für die andere schlecht sein. Der Punkt ist, Sie müssen eine Benutzergruppe auswählen. Ich glaube nicht, dass man überhaupt von gutem oder schlechtem Design sprechen kann, außer in Bezug auf einen bestimmten beabsichtigten Benutzer.

Sie werden höchstwahrscheinlich gutes Design erhalten, wenn die beabsichtigten Benutzer den Designer selbst einschließen. Wenn Sie etwas für eine Gruppe entwerfen, die Sie nicht einschließt, ist es tendenziell für Leute, die Sie für weniger anspruchsvoll halten als sich selbst, nicht für anspruchsvollere.

Das ist ein Problem, denn auf den Benutzer herabzublicken, wenn auch wohlwollend, scheint den Designer unweigerlich zu verderben. Ich vermute, dass nur sehr wenige Wohnprojekte in den USA von Architekten entworfen wurden, die selbst darin leben wollten. Dasselbe kann man bei Programmiersprachen sehen. C, Lisp und Smalltalk wurden für ihre eigenen Designer geschaffen. Cobol, Ada und Java wurden für andere Leute geschaffen.

Wenn Sie glauben, etwas für Idioten zu entwerfen, dann entwerfen Sie wahrscheinlich nichts Gutes, nicht einmal für Idioten.

Selbst wenn Sie etwas für die anspruchsvollsten Benutzer entwerfen, entwerfen Sie es immer noch für Menschen. In der Forschung ist das anders. In der Mathematik wählen Sie Abstraktionen nicht, weil sie für Menschen leicht zu verstehen sind; Sie wählen diejenigen, die den Beweis kürzer machen. Ich glaube, das gilt generell für die Wissenschaften. Wissenschaftliche Ideen sind nicht dazu gedacht, ergonomisch zu sein.

In den Künsten ist das ganz anders. Design dreht sich alles um Menschen. Der menschliche Körper ist eine seltsame Sache, aber wenn Sie einen Stuhl entwerfen, ist es das, wofür Sie entwerfen, und es gibt keinen Ausweg. Alle Künste müssen den Interessen und Einschränkungen der Menschen schmeicheln. In der Malerei zum Beispiel wird ein Gemälde mit Menschen darin interessanter sein als eines ohne, wenn alle anderen Dinge gleich sind. Es ist kein Zufall der Geschichte, dass die großen Gemälde der Renaissance voller Menschen sind. Hätten sie das nicht getan, hätte die Malerei als Medium nicht den Stellenwert, den sie hat.

Ob man es mag oder nicht, Programmiersprachen sind auch für Menschen, und ich vermute, das menschliche Gehirn ist genauso klumpig und eigenartig wie der menschliche Körper. Manche Ideen sind für Menschen leicht zu erfassen, manche nicht. Wir scheinen zum Beispiel eine sehr begrenzte Kapazität für den Umgang mit Details zu haben. Das ist der Grund, warum Programmiersprachen überhaupt eine gute Idee sind; wenn wir mit Details umgehen könnten, könnten wir einfach in Maschinensprache programmieren.

Denken Sie 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 Ihnen sagen, dass man für die beiden Situationen unterschiedliche Medien wünschen könnte. 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 ist, wie ein Beweis, eine beschnittene Version eines Baumes, der in der Vergangenheit überall falsche Anfänge hatte. Der Test einer Sprache ist also nicht einfach, wie sauber das fertige Programm darin aussieht, sondern wie sauber der Weg zum fertigen Programm war. Eine Designentscheidung, die Ihnen elegante fertige Programme liefert, liefert Ihnen möglicherweise keinen eleganten Designprozess. Ich habe zum Beispiel ein paar Makro-definierende Makros mit verschachtelten Backquotes geschrieben, die jetzt wie kleine Juwelen aussehen, aber das Schreiben hat Stunden hässlichster Versuche und Irrtümer gekostet, und ehrlich gesagt, bin ich mir immer noch nicht ganz sicher, ob sie korrekt sind.

Wir tun oft so, als wäre der Test einer Sprache, wie gut fertige Programme darin aussehen. Es wirkt so überzeugend, wenn man dasselbe Programm in zwei Sprachen sieht und eine Version viel kürzer ist. Wenn man sich dem Problem aus der Richtung der Künste nähert, ist man weniger geneigt, sich auf diese Art von Test zu verlassen. Man möchte nicht mit einer Programmiersprache wie Marmor enden.

Zum Beispiel ist es ein enormer Vorteil bei der Entwicklung von Software, eine interaktive Top-Level-Umgebung zu haben, die in Lisp als Read-Eval-Print-Loop bezeichnet wird. Und wenn man eine hat, hat das reale Auswirkungen auf das Design der Sprache. Es würde zum Beispiel nicht gut für eine Sprache funktionieren, in der man Variablen deklarieren muss, bevor man sie verwendet. Wenn man gerade Ausdrücke in die Top-Level-Umgebung eingibt, möchte man x einen Wert zuweisen und dann Dinge mit x tun können. Man möchte nicht zuerst den Typ von x deklarieren müssen. Man kann entweder von den Prämissen abweichen, aber wenn eine Sprache eine Top-Level-Umgebung haben muss, um bequem zu sein, und obligatorische Typdeklarationen mit einer Top-Level-Umgebung unvereinbar sind, dann kann keine Sprache, die Typdeklarationen obligatorisch macht, bequem zu programmieren sein.

In der Praxis muss man, um gutes Design zu erzielen, nah an seinen Benutzern sein und nah bleiben. Man muss seine 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 ihrer Familie laut vorgelesen hat. Deshalb versinkt sie nie in selbstverliebten künstlerischen Landschaftsbeschreibungen oder prätentiösem Philosophieren. (Die Philosophie ist da, aber sie ist in die Geschichte eingewoben, anstatt wie ein Etikett darauf geklebt zu werden.) Wenn Sie einen durchschnittlichen „literarischen“ Roman öffnen und sich vorstellen, ihn Ihren Freunden laut vorzulesen, als hätten Sie ihn geschrieben, werden Sie nur allzu deutlich spüren, welche Zumutung diese Art von Dingen für den Leser ist.

In der Softwarewelt ist diese Idee als „Worse is Better“ bekannt. Tatsächlich sind mehrere Ideen in dem Konzept „Worse is Better“ vermischt, weshalb die Leute immer noch darüber streiten, ob schlimmer tatsächlich besser ist oder nicht. Aber eine der Hauptideen in diesem Mix ist, dass man, wenn man etwas Neues baut, so schnell wie möglich einen Prototyp vor die Benutzer bringen sollte.

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

Was Leute außerhalb der Softwarewelt vielleicht nicht erkennen, ist, dass „Worse is Better“ in den Künsten allgegenwärtig ist. In der Zeichenkunst zum Beispiel wurde die Idee während der Renaissance entdeckt. Jetzt wird Ihnen fast jeder Zeichenlehrer sagen, dass der richtige Weg, eine genaue Zeichnung zu erhalten, nicht darin besteht, langsam um die Kontur eines Objekts herumzuarbeiten, da sich Fehler ansammeln und Sie am Ende feststellen, dass die Linien nicht zusammenpassen. Stattdessen sollten Sie ein paar schnelle Linien an der ungefähr richtigen Stelle zeichnen und dann diese anfängliche Skizze schrittweise verfeinern.

In den meisten Bereichen wurden Prototypen traditionell aus verschiedenen Materialien hergestellt. Schriftarten, die in Metall geschnitten werden sollten, wurden zunächst 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 Tusche auf Papier gezeichnet. Gebäude, die aus Stein gebaut werden sollten, wurden im kleineren Maßstab in Holz getestet.

Was Ölfarben so aufregend machte, als sie im fünfzehnten Jahrhundert populär wurden, war, dass man das fertige Werk tatsächlich aus dem Prototyp machen 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 kann man auch in der Software. Ein Prototyp muss nicht nur ein Modell sein; man kann ihn zum fertigen Produkt verfeinern. Ich denke, das sollte man immer tun, wenn man kann. Es ermöglicht Ihnen, neue Erkenntnisse zu nutzen, die Sie unterwegs gewinnen. Aber vielleicht noch wichtiger ist, es ist gut für die Moral.

Moral ist entscheidend im Design. Ich bin überrascht, dass die Leute nicht mehr darüber reden. Einer meiner ersten Zeichenlehrer sagte mir: Wenn Sie sich beim Zeichnen von etwas langweilen, wird die Zeichnung langweilig aussehen. Angenommen, Sie müssen zum Beispiel ein Gebäude zeichnen und beschließen, jeden Ziegelstein einzeln zu zeichnen. Das können Sie tun, wenn Sie wollen, aber wenn Sie auf halbem Weg gelangweilt sind und die Ziegel mechanisch zu malen beginnen, anstatt jeden einzelnen zu beobachten, wird die Zeichnung schlechter aussehen, als wenn Sie die Ziegel nur angedeutet hätten.

Das schrittweise Verfeinern eines Prototyps ist gut für die Moral, weil es Sie engagiert hält. In der Software lautet meine Regel: Immer funktionierenden Code haben. Wenn Sie etwas schreiben, das Sie in einer Stunde testen können, dann haben Sie die Aussicht auf eine sofortige Belohnung, die Sie motiviert. Dasselbe gilt in den Künsten, und besonders in der Ölmalerei. Die meisten Maler beginnen mit einer verschwommenen Skizze und verfeinern sie allmählich. Wenn Sie so arbeiten, müssen Sie den Tag im Prinzip nie mit etwas beenden, das tatsächlich unfertig aussieht. Tatsächlich gibt es unter Malern sogar den Spruch: „Ein Gemälde ist nie fertig, man hört nur 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 anspruchslosen Benutzer zu entwerfen. Es ist schwer, sich für etwas zu interessieren, das man selbst nicht mag. Um etwas Gutes zu machen, muss man denken: „Wow, das ist wirklich großartig“, nicht: „Was für ein Mist; 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.

Beachten Sie, 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 und nicht 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 Gesellen aus Nordeuropa oft eingestellt, um die Landschaften im Hintergrund 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 gute Designinstanzen zusammenfügen, aber innerhalb jedes einzelnen Projekts muss eine Person die Kontrolle haben.

Ich sage nicht, dass gutes Design erfordert, dass eine Person alles bedenkt. Der Rat von jemandem, dessen Urteilsvermögen Sie vertrauen, ist von unschätzbarem Wert. Aber nachdem das Gespräch beendet ist, muss die Entscheidung, was zu tun ist, bei einer Person liegen.

Warum kann Forschung von Kollaborateuren 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 tatsächlich kann sie nicht von Kollaborateuren 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 arbeiteten, als Zusammenarbeit weniger üblich war.

Was auch immer die Geschichte in den Wissenschaften ist, echte Zusammenarbeit scheint in den Künsten verschwindend selten zu sein. Design im Ausschuss 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 das nicht gibt – 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 repräsentiert, die in den Kopf einer Person passt, dann passt die Idee auch in den Kopf des Benutzers.

Verwandt: