It is all design – really?

Uncle Bob hat unlängst getwittert: “It is all design.” Und dafür hat er auch großes Lob aus Deutschland bekommen.

Ich frage mich hingegen: Wenn denn alles Design ist, warum sollte ich dann dieses Design in textuellem Quellcode durchführen?

Ja, ja, ich weiß, dass Jack W. Reeves schon in den 1990ern “bewiesen” hat, dass Programmierung nicht Herstellung, sondern Design ist. Dem stimme ich im Vergleich zum Baugewerbe oder der Autoproduktion auch zu. Softwareentwickler heißen nicht umsonst Entwickler und nicht Hersteller. Softwareentwicklung ist eine sehr kreative Tätigkeit. Ein Auto zu produzieren oder ein Haus hochzuziehen hingegen nicht. Da wird weitgehend nur ein Plan abgearbeitet. Softwareentwicklung hingegen ist Planerfindung.

Insofern produziert Codieren natürlich Design. “It is all design” könnte also wahr sein.

Aber: Design verhält sich zu Produktion wie Landkarte zu Terrain – das eine ist Abstraktion, das andere Detail, Konkretes. Was nun aber, wenn das Design so kompliziert ist, dass man es nicht einfach darlegen kann, wenn es selbst ein Terrain ist. Man kann es dann nicht runterschreiben. Selbst eine Landkarte will recherchiert sein. Sie kommt aus vielen Quellen zusammen und ist am Ende doch nur ein recht unkreatives Abbild der Realität. Software aber kann nicht irgendwo abgemalt werden. Software als Design muss erdacht werden. Code, der selbst ja nur ein Produktionsplan ist, muss selbst geplant, entworfen werden.

Und damit sind wir beim terminologischen Dilemma. Es ist eben nicht alles zu Design gesagt, wenn man konstatiert, Code sei Design. Man muss dazu sagen, was denn Design überhaupt seiner Natur nach sei. Man muss den allgemeinen Fall in den Blick nehmen:

Design ist ein Plan für etwas Konkretes.

Wenn etwas Konkretes kompliziert ist, dann kann man es nicht “einfach so” herstellen, sondern dann muss man sich darüber vorher mal Gedanken machen. Allemal, wenn das Konkrete etwas Neues ist.

Design braucht also selbst durchaus Design. Und das Design dann womöglich auch wieder usw. usf. Design ist mithin nur relativ, d.h. in Gegenüberstellung zu etwas Konkretem sein Vorläufer:

Design –> Konkretes

Nimmt man jedoch das Design selbst in den Blick, wird es ebenfalls etwas Konkretes, d.h. ein Produkt, das designt werden kann:

Design' –> Design

Und auch das Design des Designs könnte kompliziert sein, so dass es ein Design brauchen könnte:

Design'' –> Design'

So ergibt sich eine Hierarchie von Designs mit dem endgültig Konkreten als Ziel:

Design''(Design'(Design(Konkretes)))

Das halte ich für ein allgemeines Bild vom Verhältnis von Design zu Produkt. Der Entwurf geht dem Konkreten voraus. Und was bedeutet das für die Softwareentwicklung? Deren endgültig Konkretes ist klar: ausführbarer Code. Quellcode ist laut Reeves ein Design dafür. Uncle Bob sieht das ähnlich, wenn er sagt, Testing und Refactoring seien Designtätigkeiten (weil sie Quellcode formen). Für Sie ist die Hierarchie deshalb nur zweistufig:

Quellcode(Maschinencode)

Ich hingegen behaupte mal, dass das eine ganz und gar unnötig beschränkende Sichtweise ist. Wenn wir sie als Ende der Fahnenstange ansehen, dann müssen wir uns bei der Softwareentwicklung nur noch stärker bemühen, den textuellen Quellcode in den Griff zu bekommen. Refactoring-Tools müssen besser werden, Test-Tools müssen besser werden, die Ausbildung zum Quellcodeschmied muss besser werden… dann wird es schon gehen.

In den letzten 60 Jahren ist die Softwareentwicklung aber nicht besser geworden, weil sie auf der jeweils höchsten Abstraktionsstufe stehengeblieben wäre. Wir entwickeln heute natürlich Komplizierteres viel schneller als vor 60 Jahren. Nur tun wir das nicht mit besseren Maschinencode-Tools. Die Hierarchie sieht vielmehr so aus:

OO-3GL(IL-Code(Machinencode))

Oder sie sah sogar einmal so aus:

OO-3GL(3GL(Assembler(Maschinencode)))

Wir sind voran gekommen, weil wir uns auf höhere Abstraktionsebenen geschwungen haben!

Statt besser mit Maschinencode umgehen zu können, lassen wir ihn lieber generieren. Statt besser mit Assembler umgehen zu können, lassen wir den Code lieber generieren. Statt C zu schreiben, lassen wir den Code von einem C++-Compiler generieren. (Zumindest habe ich das noch 1990 erlebt. Es war aber eine vorübergehende Phase, die hier jedoch eine schöne Illustration des generellen Trends gibt.)

Warum also sollten wir da stehenbleiben? Was ist so heilig an der Hierarchie

C#(IL-Code(Maschinencode))

oder

Java(JBC(Maschinencode))

Ist denn der Softwareentwicklung die Phantasie ausgegangen? Haben sich alle im Schmerz eingerichtet, den es macht, 3GL-Code direkt zu schreiben und auch noch fehlerfrei und evolvierbar zu halten?

Nein, ich finde Uncle Bobs Position uninspirier(t/end). Er hat in “Clean Code” das Richtige gesagt und Gutes bewirkt. Danke dafür! Bei Refactoring und Test-first (und seinem Hobby Clojure) jedoch stehenzubleiben und auszurufen “It is all design.”, das finde ich zuwenig.

Warum nicht einen Schritt weiter denken? Wer füllt das Fragezeichen in dieser Hierarchie mit Leben:

<?>(C#(IL-Code(Maschinencode)))

Ist das der Platz für UML? Das glaube ich nicht. UML führt nicht direkt zu 3GL-Code – oder wenn, dann nur sehr umständlich. UML ist de facto ein Werkzeug, das vor allem der Beruhigung von Management dient. Regelmäßig geben auf Entwicklerveranstaltungen (in der .NET-Community) höchstens 15% der Anwesenden an, dass sie mit UML entwerfen.

Oder ist das der Platz für DSLs? Martin Fowler scheint das zu glauben, wenn er nicht gerade derselben Meinung wie Uncle Bob ist. Dagegen spricht für mich, dass DSLs selbst zunächst entworfen werden müssen, bevor sie helfen, 3GL-Code zu entwerfen:

Meta-DSL(DSL(C#(IL-Code(Maschinencode))))

Das scheint mir einer breiten Adoption entgegen zu stehen. Die Konzepte und Notation auf einer Ebene anzuwenden ist kompliziert genug wie wir am Beispiel C# sehen. Da hilft es wenig, Entwicklermassen zu empfehlen, zuerst Kompetenz auf einer Meta-Ebene zu erwerben, um immer wieder neue Konzepte und Notationen zu entwickeln, die dann erst zum Entwurf von Quellcode eingesetzt werden können. Der begrenzte Erfolg von MDSD scheint mir diese Sicht zu bestätigen.

Und nun? Ich kann leider nicht umhin, einen Anwärter auf die Position einer Entwurfssprache für 3GL in Flow-Design zu sehen. (Wer hätte das gedacht? ;-)

Flow-Design(C#(IL-Code(Maschinencode)))

Die bisher entwickelten Konzepte und die Formensprache für Flow-Design ist einfach zu erlernen und deckt viele typische Entwurfsbedürfnisse für Quellcode ab. Es gibt klare Übersetzungsregeln für Flow-Design Entwürfe in 3GL-Code. Die Ergebnisse sind übersichtlich und skalieren. Flow-Design ist nicht domänenspezifisch; einmaliger Lernaufwand zahlt sich also in allen Problemlebenslagen aus.

Soweit mal mein kühnes Statement :-) Aber ich bin natürlich offen dafür, dass man mir die Nutzlosigkeit einer Design-Abstraktionsebene oberhalb von Quellcode erklärt. Einstweilen erlaube ich mir jedoch, Uncle Bob bewusst misszuverstehen. Ich sage auch: It is all design. Aber ich meine damit etwas anderes. Für mich findet Design auf einer höheren Ebene statt als “Quellcoderumgeschubse”.