Engineering-Philosophie: Rich Hickey, einfach ist nicht leicht

Die wichtigsten Erkenntnisse

• Einfach ist nicht leicht. Einfach heißt entflochten – eine Sache pro Ding – und ist objektiv; leicht heißt vertraut und griffnah und ist subjektiv. Ständig wählen wir das Leichte und etikettieren es fälschlich als einfach.
• Verflechtung ist die Wurzel der Komplexität. Komplexität bemisst sich nicht an der Zahl der Teile, sondern daran, wie verwoben sie sind. Zustand an Zeit, Identität an Verhalten oder Richtlinie an Mechanismus zu flechten – das macht ein System, über dem Sie nur noch beten können.
• Entflechten Sie unerbittlich. Lösen Sie verflochtene Belange in eigenständige Teile auf, die Sie bewusst zusammensetzen. Einfachheit ist „eine Entscheidung”, die „ständige Wachsamkeit erfordert” – sie stellt sich niemals ein, indem man zum vertrauten Werkzeug greift.
• Werte vor Orten, Daten vor Objekten. Machen Sie Unveränderlichkeit zum Standard und lassen Sie die Vergangenheit als unveränderliche Fakten anwachsen, statt Zustand an Ort und Stelle zu überschreiben – die Disziplin hinter Clojure wie hinter Datomic.

Das Prinzip

„Die Wurzeln dieses Wortes sind ‚sim’ und ‚plex’, und das bedeutet ‚eine Falte oder ein Geflecht’ […] direkt neben oder im Gegensatz zu ‚complex’, was ‚zusammengeflochten’ oder ‚zusammengefaltet’ bedeutet.” – Rich Hickey, Simple Made Easy¹

Fast jede Debatte über Softwarequalität ist in Wahrheit eine Debatte, die zwei Argumente unter einem Wort verbirgt, und Rich Hickeys Beitrag besteht darin, sie auseinanderzuziehen. Einfach und leicht sind keine Synonyme. Sie liegen nicht einmal auf derselben Achse: das eine misst die Sache, das andere Ihren Abstand zu ihr. Einfach stammt vom lateinischen simplex – eine Falte, ein Geflecht, eine Windung. Es beschreibt die Sache selbst: wie viele Belange in ihr verwoben sind. Es ist objektiv, und sein Gegenteil ist komplex – zusammengeflochten, in sich gefaltet. Leicht hingegen leitet sich von einer Wurzel ab, die „nahe liegen” bedeutet, derselben Wurzel wie adjazent.² Leicht beschreibt Ihr Verhältnis zur Sache: wie griffnah sie ist, wie vertraut, wie wenig Mühe es Sie kostet, anzufangen. Es ist subjektiv, und sein Gegenteil ist schwer.¹²

Hat man die Unterscheidung einmal gesehen, lässt sie sich nicht mehr übersehen. Das Werkzeug, zu dem Sie greifen, weil es nur ein npm install entfernt ist, ist leicht. Ob es einfach ist – ob es Persistenz in Ihre Validierung in Ihre UI in Ihre Geschäftslogik verflicht – ist eine völlig andere Frage, und die Antwort lautet meist nein. Wir wählen unablässig das Leichte und nennen es einfach, und dann ertrinken wir in der Komplexität, die wir selbst herbeigerufen haben. Hickeys Wort für den Akt des Verflechtens ist complect (verflechten): „verweben, verschlingen oder flechten”.³ Das Verflechten ist die Erbsünde. Es verwandelt ein System, über das Sie nachdenken konnten, in eines, über dem Sie nur noch beten können, denn sobald zwei Belange zusammengeflochten sind, können Sie den einen nicht mehr anfassen, ohne den anderen zu verstehen und zu gefährden.

Die Disziplin besteht also darin, zu entflechten – verflochtene Belange unerbittlich in eigenständige Teile aufzulösen – und Hickey benennt den Preis dafür unverblümt. „Einfachheit ist eine Entscheidung”, sagt er. „Es ist Ihre Schuld, wenn Sie kein einfaches System haben.”⁴ Sie stellt sich nicht von selbst ein, indem man zum vertrauten Werkzeug greift; sie entsteht durch „ständige Wachsamkeit” und bewusste Sorgfalt.⁴ Das ist das ganze Prinzip in vier Worten: einfach ist nicht leicht. Einfachheit ist der schwerere, gewählte, entflochtene Weg, und sie ist der einzige, dessen Wirkung sich verzinst. Dieselbe Überzeugung liegt der Argumentation zugrunde, dass Qualität die einzige Variable ist – man landet nicht durch den jeweils bequemen Schritt in einem sauberen System; man entscheidet sich dafür, gegen das Gefälle, jedes Mal aufs Neue.

Kontext

Rich Hickey ist ein unabhängiger Programmierer, der rund zwei Jahrzehnte lang beruflich Systeme in C++, Java und C# schrieb, bevor er das schuf, wofür er bekannt ist.⁵ Er wusste, wie man große Systeme in diesen Sprachen baut, und seine Schlussfolgerung nach zwanzig Jahren lautete nicht, dass ihnen Funktionen fehlten. Sie lautete, dass sie Verflechtungsmaschinen waren – sie machten es mühelos, Belange zusammenzuflechten, und boten kaum Hilfe, sie wieder auseinanderzuziehen.

Also baute er die Alternative selbst, allein. Ab etwa 2005 verbrachte Hickey rund zweieinhalb Jahre mit der Entwicklung von Clojure – größtenteils selbst finanziert und ohne Gehalt an einem Lisp für die Java Virtual Machine, das Unveränderlichkeit und Einfachheit zum Weg des geringsten Widerstands machen sollte statt zum Heldenakt.⁵ 2007 veröffentlichte er es öffentlich. Dahinter stand keine Firma, kein Gremium, kein Förderbeitrag. Es war ein einzelner Programmierer, der die Krankheit aus nächster Nähe gesehen hatte und sich entschied, Jahre seiner eigenen Reserven in den Bau der Heilung zu stecken. Später schuf er Datomic, eine unveränderliche Datenbank,⁵ und hielt eine Reihe von Konferenzvorträgen – Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet? –, die zusammengenommen das einflussreichste Werk an Designphilosophie in der modernen funktionalen Programmierung bilden.⁶

Das Werk

Simple Made Easy: Einfach gegen leicht, und das Verflechten

Gehalten auf der Strange Loop im September 2011, ist Simple Made Easy der Vortrag, der neu ordnete, wie eine ganze Generation von Programmierern über Komplexität spricht.¹ Seine ganze Wucht entspringt der Weigerung, einfach und leicht dasselbe bedeuten zu lassen. Einfach betrifft das Konstrukt – ist es eine Falte oder sind es viele zusammengeflochtene? Leicht betrifft Sie – ist es griffnah, vertraut, innerhalb Ihres derzeitigen Könnens? Es gibt Dinge, die einfach, aber unvertraut sind (schwer zu erlernen, leicht zu leben), und Dinge, die leicht, aber komplex sind (vertraut, bequem und leise verheerend). Das meiste, was die Branche als Produktivität verkauft, ist von der zweiten Sorte.¹

Das Verb im Zentrum ist complect: flechten, verweben, verschlingen.³ Das Verflechten ist es, was ein System komplex macht – nicht die Zahl der Teile, sondern wie verwoben sie sind. Zustand verflicht Wert und Zeit. Objekte verflechten Zustand, Identität und Verhalten. Vererbung, ORMs, über eine Methode verstreute Bedingungen – jedes flicht Belange zusammen, die hätten getrennt bleiben können. Und der Preis eines Geflechts wird nicht einmal entrichtet; er wird bei jeder künftigen Änderung fällig, denn Sie können einen Strang nicht mehr anfassen, ohne alle anderen zu stören.

Die Heilung besteht darin, zu entflechten – die Stränge in eigenständige Dinge zu trennen, die Sie später zu Ihren eigenen Bedingungen zusammensetzen können. Hickeys Behauptung, und es ist eine starke, lautet, dass Entflechten kein Verlust an Mächtigkeit ist. „Sie können ein ebenso ausgeklügeltes System mit dramatisch einfacheren Werkzeugen schreiben”, sagt er – dieselben Programme, nur solche, über die Sie tatsächlich nachdenken, die Sie ändern und denen Sie vertrauen können.⁴ Einfachheit ist nicht die Anfängerteilmenge des Könnens. Sie ist die Disziplin des Experten, sich dem Flechten zu verweigern.

Clojure: Ein Lisp für die JVM, Daten vor Objekten

Clojure ist das Prinzip in ausführbarer Form: ein dynamischer, funktionaler Lisp-Dialekt, der auf der JVM läuft und von Hickey als „ein Lisp für funktionale Programmierung in Symbiose mit einer etablierten, auf Nebenläufigkeit ausgelegten Plattform” entworfen wurde.⁷ Zwei Entscheidungen verschlüsseln die Philosophie. Erstens: Unveränderlichkeit ist der Standard, keine Option – Clojures grundlegende Datenstrukturen sind unveränderlich und persistent, sodass das Natürlichste, was man schreiben kann, zugleich das ist, was sich durch eine weit entfernte Mutation nicht beschädigen lässt.⁷ Zweitens: Daten vor Objekten – statt eines Wildwuchses maßgeschneiderter Klassen, jede mit eingeflochtenem privatem Zustand und Verhalten, bevorzugt Clojure „viele Funktionen, definiert auf wenigen primären Datenstrukturen” – Sequenzen, Maps, Vektoren, Sets.⁷ Nehmen Sie einfach Maps. Nehmen Sie einfach Daten.

Diese Trennung ist Entflechtung auf der Ebene der Grammatik einer Sprache. Objekte flechten Zustand, Identität und Verhalten zu einem einzigen versiegelten Ding zusammen; Clojure zieht sie auseinander – unveränderliche Werte für das, was ein Ding ist, schlichte Funktionen für das, was Sie damit tun, explizite Referenztypen für verwalteten Wandel über die Zeit. Indem er die JVM zur Plattform machte, statt gegen sie anzukämpfen, entflocht Hickey auch Sprache von Ausführungsumgebung: Clojure erhält die Reife, die Bibliotheken und die Leistung der JVM umsonst und gibt sein Budget an Neuerung vollständig für das Modell von Zustand und Zeit aus.⁷

The Value of Values: Unveränderlichkeit und Datomic

The Value of Values hebt das Argument der Unveränderlichkeit eine Ebene höher, hin zur Datenbank selbst. Hickeys Zielscheibe ist das, was er ortsorientierte Programmierung (Place-Oriented Programming, PLOP) nennt: „Immer wenn neue Information alte Information ersetzt, betreiben Sie ortsorientierte Programmierung.”⁸ Wir aktualisieren einen Datensatz an Ort und Stelle, der alte Wert ist fort und mit ihm die Geschichte. Er argumentiert, dies sei ein Überbleibsel aus einer Ära knappen Speichers und werfe genau das weg, was ein Unternehmen zum Schlussfolgern braucht – die Vergangenheit. Ein Wert hingegen ist per Definition unveränderlich: ein Fakt ist „etwas, das geschehen ist, etwas, von dem bekannt ist, dass es geschehen ist”, und ein Fakt kann nicht aktualisiert, sondern nur durch einen neueren Fakt abgelöst werden.⁸ Ein neuer Präsident überschreibt nicht den alten; er wird angefügt.

Datomic ist diese Idee, als Datenbank gebaut. Sie ist grundlegend unveränderlich: „Eine Datomic-Datenbank ist eine Menge unveränderlicher atomarer Fakten, genannt Datoms”, und „Datomic-Transaktionen fügen Datoms hinzu, ohne sie je zu aktualisieren oder zu entfernen, sodass Sie eine vollständige Prüfspur haben.”⁹ Weil nie etwas überschrieben wird, lässt sich die Datenbank als Wert zu einem Zeitpunkt behandeln – Sie können sie „as-of” jedem vergangenen Augenblick mit denselben Abfragen befragen, die Sie gegen die Gegenwart laufen lassen, ohne jede Änderung.⁹ Die Datenbank ist nicht länger ein einzelner veränderlicher Ort, sondern wird zu einer Reihe von Werten über die Zeit. Zustand, Identität und Zeit – entflochten, in einem produktiven Datenspeicher.

Hammock-Driven Development: Erst denken

Das Gegenstück zu all dem ist ein Vortrag darüber, wann die eigentliche Arbeit geschieht, und Hickeys Antwort lautet: bevor Sie die Tastatur berühren. In Hammock-Driven Development argumentiert er, dass „der billigste Ort, Fehler zu beheben, der Entwurf Ihrer Software ist”, und dass die meisten ernsten Softwarefehler Fehler der Fehlvorstellung sind – wir haben das Problem nicht verstanden, bevor wir mit dem Lösen begannen.¹⁰ Das Heilmittel besteht darin, das Problem ausdrücklich zu benennen, die Fakten und Beschränkungen zusammenzutragen und dann zu denken – auch indem man das Problem dem „Hintergrundgeist” übergibt, der jene Verbindungen knüpft, die der analytische „wache Geist” nicht erzwingen kann.¹⁰ Die Hängematte ist das buchstäbliche Möbelstück, um nichts zu tun als ungestört zu denken.

Hammock-Driven Development ist die Praxis, die Einfachheit überhaupt erst möglich macht. Sie können ein System nicht entflechten, das Sie noch nicht verstehen, und Sie können es nicht verstehen, während Sie zum Kompilieren hetzen. Hammock-Driven Development ist die unglanzvolle erste Hälfte von einfach ist nicht leicht: das bewusste, langsame, wachsame Denken, das geschehen muss, bevor der entflochtene Entwurf erscheinen kann.

Die Methode

Die Methode ist eine einzige Unterscheidung – einfach ist nicht leicht –, mit ungewöhnlicher Hartnäckigkeit angewandt über eine Sprache, eine Datenbank und einen Arbeitsstil hinweg.

Trennen Sie „einfach” von „leicht” vor jeder Entscheidung. Fragen Sie sich bei jedem Werkzeug oder Entwurf: Ist dies entflochten (einfach) oder bloß vertraut und griffnah (leicht)? Es sind unterschiedliche Achsen, und ihre Vermengung ist der Weg, auf dem sich Komplexität als Produktivität getarnt einschleicht.¹²

Spüren Sie Verflechtung auf und entflechten Sie sie. Komplexität ist nicht die Zahl der Teile; sie ist, wie verwoben sie sind. Finden Sie heraus, wo Zustand an Zeit, Identität an Verhalten, Richtlinie an Mechanismus geflochten ist – und ziehen Sie die Stränge in eigenständige Teile auseinander, die Sie bewusst zusammensetzen.³

Bevorzugen Sie Werte und Daten gegenüber Orten und Objekten. Machen Sie Unveränderlichkeit zum Standard. Stellen Sie Information als schlichte Daten dar – Maps, Vektoren – und operieren Sie mit Funktionen darauf, statt Zustand und Verhalten in Objekten zusammenzusiegeln.⁷⁸

Behandeln Sie die Vergangenheit als Wert, nicht als überschriebenen Zustand. Neue Information sollte anfügen, nicht zerstören. Ein System, das über die Zeit unveränderliche Fakten anhäuft, lässt sich durchdenken, prüfen und „as-of” jedem Augenblick abfragen – was ein Ort, der an Ort und Stelle überschrieben wird, niemals kann.⁸⁹

Denken Sie, bevor Sie tippen. Der günstigste Ort, einen Defekt zu beheben, ist der Entwurf. Benennen Sie das Problem, geben Sie es Ihrem Hintergrundgeist und verdienen Sie sich den einfachen Entwurf, indem Sie das Problem zuerst verstehen.¹⁰

Akzeptieren Sie, dass Einfachheit schwer und gewählt ist. Sie stellt sich nicht ein, indem man zum Leichten greift. „Einfachheit ist eine Entscheidung”, und sie erfordert „ständige Wachsamkeit”. Der bequeme Weg und der einfache Weg sind selten derselbe Weg.⁴

Einflusskette

Wer ihn prägte

Lisp und John McCarthy. Clojure ist, in Hickeys eigener Formulierung, „ein Lisp, das nicht durch Rückwärtskompatibilität eingeschränkt ist” – die Homoikonizität von Code als Daten und die Mächtigkeit der Makros stammen direkt aus McCarthys Linie, erweitert auf Maps und Vektoren statt nur auf Listen.⁷ (Direkter Einfluss)

John Backus und die Tradition der funktionalen Programmierung. Backus’ Turing-Award-Vortrag von 1977, Can Programming Be Liberated from the von Neumann Style?, ist das kanonische Argument gegen zuweisungsgetriebenes, ortsorientiertes Rechnen. Hickeys Krieg gegen die ortsorientierte Programmierung und den veränderlichen Zustand ist dieses Argument, in die Produktion getragen. (Prägender Einfluss)

Die Java Virtual Machine. Statt die Ausführungsumgebung als zu wegabstrahierenden Feind zu behandeln, machte Hickey die JVM zur Plattform und baute die Sprache obenauf – eine bewusste Entflechtung von „Sprache” und „Ausführungsumgebung”, die Clojure von Tag eins an Reife und Reichweite verlieh. (Direkter Einfluss)

Relationales und wertorientiertes Denken. Datomics Sicht auf Daten als unveränderliche, über die Zeit angehäufte Fakten, abfragbar „as-of” jedem Punkt, entstammt der Trennung der relationalen Tradition von Fakten und ihrer Speicherung – der Idee, dass Information eine Existenz unabhängig von dem Ort hat, der sie gerade hält.⁸⁹ (Prägender Einfluss)

Wen er prägte

Die Renaissance der funktionalen Programmierung. Clojure half, neben Scala und anderen auf der JVM, die funktionale Programmierung von der akademischen Kuriosität in die Mainstream-Produktion zu überführen, und Hickeys Vorträge wurden zum gemeinsamen Vokabular – „einfach”, „leicht”, „complect” –, mit dem berufstätige Programmierer heute über Design streiten.

Unveränderlichkeit, in den Mainstream getragen. Die Idee, dass standardmäßig unveränderliche Daten der vernünftige Standard sind und keine exotische Beschränkung, breitete sich weit über Clojure hinaus aus. Sie ist heute Grundvoraussetzung im Sprach- und Bibliotheksdesign der ganzen Branche.

React, Redux und die Welt des Frontends. Das wertorientierte Modell – unveränderlicher Zustand, reine Transformationen über Daten, Identität und Zustand auseinandergezogen – ist das gedankliche Rückgrat von React und besonders von Redux. Eine Generation von Frontend-Entwicklern saugte Hickeys Wertdenken auf, ohne immer zu wissen, von wem es stammte.

Der rote Faden

John Carmack reduziert einen Renderer auf den schnellen, einfachen Kern und verweigert jede Funktion, die Langsamkeit in die innere Schleife flechten würde; Hickey reduziert ein System auf seine entflochtenen Belange und verweigert jede Abstraktion, die sie verflechten würde. Beide behandeln Einfachheit als das schwere, gewählte Ding statt als den Standard. Und wo Linus Torvalds den „guten Geschmack” schätzt, der einen Sonderfall im allgemeinen Fall verschwinden lässt, schätzt Hickey das Entflechten, das zwei verwobene Belange als je eigenständige hervortreten lässt – derselbe Instinkt von entgegengesetzten Enden betrachtet: die richtige Struktur ist keine Verzierung am Problem, sie ist das Problem, korrekt in seine wirklichen Teile zerlegt. Yukihiro Matsumoto optimierte Ruby danach, wie es sich anfühlt, sie zu schreiben – das Leichte, in Hickeys Vokabular –, während Hickey danach optimierte, was die Sache ist – das Einfache; zusammen vermessen sie die beiden Achsen, auf deren Nichtverwechslung Hickey einen ganzen Vortrag lang beharrte. (Reihenbrücke)

Was ich daraus mitnehme

Die Lektion, die mir bleibt, ist, dass leicht eine als Tugend verkleidete Falle ist. Fast jedes Bedauern in einer Codebasis begann als vernünftiger Griff zum Griffnahen – die bequeme Bibliothek, die schnelle Mutation, die eine zusätzliche Zuständigkeit, in eine bereits bestehende Klasse hineingefaltet. Nichts davon fühlte sich wie ein Fehler an, weil sich das Leichte nie so anfühlt. Hickeys Geschenk ist das Vokabular, es im Augenblick zu erwischen: innezuhalten und zu fragen ist das einfach oder bloß leicht? und zu wissen, dass die ehrliche Antwort meist die unbequeme ist. Das ist derselbe Maßstab wie der, dass Qualität die einzige Variable ist – die Frage lautet nie „Wonach kann ich am schnellsten greifen?”, sondern „Was ist hier eigentlich entflochten?”.

In der Welt, in der ich jetzt baue – Agenten, Werkzeugschleifen, Code für Agentensysteme, wo Zustand, Prompts, Wiederholungen und Seiteneffekte sich nur zu gern zu einem unregierbaren Ding verflechten – ist die Versuchung maximales Leicht: Frameworks stapeln, Zustand über die Schleife verschmieren, die Entscheidungslogik mit dem I/O mit dem Logging verflechten, bis niemand mehr einen Teil ändern kann, ohne das Ganze zu gefährden. Der Hickey-Zug ist, zu entflechten: die Richtlinie aus dem Mechanismus herauszuziehen, den Zustand unveränderlich zu machen, wo es geht, jeden Durchlauf als Wert zu behandeln statt als Ort, den ich überschreibe. Diese Überzeugung – dass Geschmack ein technisches System ist, das man mit Wachsamkeit wählt, kein Bauchgefühl, das man durch Greifen zum Nächstliegenden erbt – ist der rote Faden vom selbst finanzierten Lisp im Jahr 2007 bis zu einem Agentensystem im Jahr 2026. Einfach ist nicht leicht. Wählen Sie es trotzdem.

FAQ

Was ist der Unterschied zwischen einfach und leicht?

In Rich Hickeys Rahmung aus Simple Made Easy sind einfach und leicht völlig unterschiedliche Achsen. Einfach stammt vom lateinischen simplex – „eine Falte oder ein Geflecht” – und beschreibt die Sache selbst: wie wenige Belange in ihr verwoben sind. Es ist objektiv, und sein Gegenteil ist komplex („zusammengeflochten”).¹ Leicht leitet sich von einer Wurzel mit der Bedeutung „nahe liegen” ab, derselben Wurzel wie adjazent; es beschreibt Ihr Verhältnis zur Sache – wie vertraut und griffnah sie ist.² Es ist subjektiv, und sein Gegenteil ist schwer. Etwas kann einfach, aber unvertraut sein, oder leicht, aber zutiefst komplex. Hickeys Punkt ist, dass wir ständig das Leichte wählen und es fälschlich als einfach etikettieren – und die Komplexität später bezahlen.¹

Was bedeutet „complect”?

Complect ist das Verb, das Hickey in Simple Made Easy für den Akt des Zusammenflechtens von Belangen wiederbelebte. Er definiert es direkt: „Es bedeutet verweben, verschlingen oder flechten.”³ Das Verflechten ist es, was ein System komplex macht – nicht die Zahl der Teile, sondern wie verwoben sie sind. Wenn zwei Belange verflochten sind (etwa Zustand und Zeit oder Identität und Verhalten), können Sie den einen nicht mehr ändern, ohne den anderen zu verstehen und zu gefährden. Das Heilmittel ist das Entflechten: die Stränge in eigenständige Teile auseinanderzuziehen, die Sie bewusst zusammensetzen können. Hickey behandelt das Entflechten als die Kerndisziplin beim Bau einfacher Systeme.³

Was hat Rich Hickey gebaut?

Rich Hickey ist ein unabhängiger Programmierer, der Clojure schuf, einen dynamischen, funktionalen Lisp-Dialekt, der auf der Java Virtual Machine läuft. Er entwickelte es weitgehend allein über rund zweieinhalb Jahre, vieles davon selbst finanziert und ohne Gehalt, und veröffentlichte es 2007.⁵⁷ Später schuf er Datomic, eine unveränderliche Datenbank, die Daten nie überschreibt, sondern unveränderliche Fakten („Datoms”) über die Zeit anhäuft, sodass die Datenbank als Wert „as-of” jedem vergangenen Punkt abgefragt werden kann.⁹ Er ist außerdem weithin bekannt für eine Reihe von Konferenzvorträgen – Simple Made Easy, The Value of Values, Hammock-Driven Development und Are We There Yet? –, die prägten, wie die Branche über Komplexität, Unveränderlichkeit und Design spricht.⁵⁶

Hat Rich Hickey gesagt, „Programmierer kennen den Nutzen von allem und die Kompromisse von nichts”?

Dieser Einzeiler wird sehr breit Hickey zugeschrieben und trifft sein Denken genau, doch er taucht in den Transkripten seiner Hauptvorträge nicht wörtlich auf; es ist eine kristallisierte Paraphrase, die durch Bücher und Konferenzvorträge zirkuliert ist.¹¹ Die nächste wörtliche Primärfassung steht in Design, Composition, and Performance, wo er dazu auffordert, eine Lösung auseinanderzunehmen, „um nicht nur den Nutzen zu sehen, nicht wahr? Der ist meist recht offensichtlich. Sondern auch die Kompromisse: Welcher Teil davon wird nicht funktionieren?”¹² Die Aussage ist unzweideutig die seine – dass Ingenieure überbewerten, was ein Werkzeug ihnen gibt, und unterprüfen, was es kostet –, doch der pointierte Aphorismus wird am besten als Paraphrase und nicht als direktes Zitat behandelt.

Quellen