Immanuel Kant unterschied drei Arten des Wohlgefallens: Das Schöne, das Angenehme und das Gute. Kann man diese Betrachtungsweise auch sinnvoll auf Software anwenden? Ein Beitrag zu einer überfälligen Debatte zur Ästhetik von Programmen.
Ist Software schön? Kann eine Softwarelösung schön, elegant oder hässlich, gar abstoßend sein? Benutzer, Softwarearchitekten, Programmierer und Tester haben verschiedene Perspektiven, haben einen unterschiedlichen Zugang zu einer konkreten Software. Sätze wie „Das ist eine schöne Lösung“, „Das ist elegant“ oder „Das ist entsetzlich“ beziehen sich, je nach Blickwinkel, auf verschiedene Aspekte eines Programms. Der Anwender findet eine Benutzeroberfläche oder eine Bedienführung schön, der Architekt die Klarheit der Komponentenstruktur, der Programmierer die Umsetzung eines Algorithmus. Und der Tester findet es schön, wenn Testfälle gut erkennbar und ausführbar sind.
Die Frage ist, was solche Aussagen eigentlich bedeuten. Sind sie vielleicht nur Umschreibungen für Antworten auf die Frage, ob die Software die funktionalen und nicht funktionalen Anforderungen erfüllt? Oder steckt mehr dahinter?
Man könnte zunächst geneigt sein, Urteile über die Schönheit und Eleganz einer Software für Aussagen über die Erfüllung nicht funktionaler Anforderungen zu halten. Dann wäre eine Benutzerführung elegant, wenn der Bediener sie intuitiv versteht und er die Funktionen der Software effizient ausführen kann. Für den Architekten wäre die Struktur der Applikation schön, wenn sie Wartbarkeit, Erweiterbarkeit und Performance unter einen Hut bringt. Der Programmierer urteilt ähnlich und findet einen Code schön, wenn er flexibel, robust, verständlich und damit gut anpassbar und wartbar ist.
Diese Vorstellung von der Schönheit einer Softwarelösung entspricht ungefähr den Ideen in der Bau-Architektur und dem Produkt-Design der ersten Hälfte des 20. Jahrhunderts, die im Umfeld des Bauhauses mit dem Slogan „Form follows function“ verbunden waren. Die schwebten wohl auch dem amerikanischen Informatiker und Kulturjournalisten David Gelernter vor, als er vor einigen Monaten in der FAZ ein Bauhaus für die Softwarebranche forderte. Gelernter, den die Zeitung als jemanden, der „die Grundlagen des World Wide Web geschaffen“ hat, vorstellte, verspricht nicht weniger als ein „Plädoyer für eine Software-Kritik“ – ähnlich der Kunst-, Architektur- und Literaturkritik.
Er meint, für Software, die im Leben wenigstens der Menschen in den westlichen Zivilisationen eine ebenso große Rolle spielt wie die verschiedenen Erzeugnisse des Bauwesens, sei eine kritische Architektur- und Designdebatte ebenso notwendig wie die zu Beginn des 20. Jahrhunderts vom Bauhaus angestoßene. Er fordert eine Besinnung auf die Grundwahrheiten der Informationsstrukturen, ihre Basiselemente müssten identifiziert und Konsequenzen für die Gestaltung der Software daraus abgeleitet werden.
Dabei macht er zwei „orthogonale(n) Grundelemente der Cyberwelt“ aus: die räumliche Struktur und die zeitliche, wobei die zeitliche Sicht wie in alten Vor-Software-Zeiten auf eine Raum-Struktur abgebildet werden muss. Räumliche Strukturen sind, so Gelernter, an der Erfahrungswelt des Schreibtisches, des Schaufensters oder des Bücherschranks orientiert, während zeitliche Strukturen „wie Partituren, Skripte, Drehbücher oder Tagebücher“ arbeiten.
So weit, so gut. Leider löst Gelernter im Folgenden sein Versprechen einer Software-Design-Kritik nicht ansatzweise ein. Stattdessen führt er eine Reihe kleiner Detail-Wünsche auf, von denen er meint, dass Software dann gut strukturiert sei, wenn sie diese erfüllt. Bei den meisten dieser Wünsche sagt sich der Leser: „Gut, so wird es sicher bald sein, aber was hat das mit Softwarekritik zu tun?“
Kritik muss ein ganzes Stück grundsätzlicher sein, als Gelernter im Artikel Glauben macht. Wenn er eine Softwarekritik fordert, die einer Literatur-, Kunst- und Designkritik entspricht, muss man wenigstens einmal darüber nachdenken, ob so etwas wie Ästhetik einer Software existiert. Ob es möglich ist, ein eigenständiges Urteil über die Schönheit einer Anwendung zu treffen, so wie man eine Vase schön finden kann, unabhängig davon, ob sie dicht ist, kippelt oder vernünftig Blumen aufnimmt.
Nicht zufällig orientiert sich Gelernter ja am Bauhaus und damit an einer Schule, für die ein Produkt dann schön war, wenn es seine Funktionen gut, effektiv, dauerhaft und fehlerfrei erfüllte. Das Produkt-Design, die Bau-Architektur und die Stadtplanung sind über diese Idee längst hinaus. Dort hat man erkannt, dass Ästhetik sich nicht auf Nützlichkeit und schon gar nicht auf pure Funktionserfüllung reduzieren lässt. Gelernter bleibt aber bei den nicht funktionalen Anforderungen stehen, er scheint anzunehmen, dass die Schönheit oder Eleganz einer Lösung in Bedienerfreundlichkeit, Wartbarkeit und Performance besteht.
Kritik der Urteilskraft: Auch wenn Immanuel Kant nie ein Stück Software gesehen hat, ist sein Werk hilfreich zur Beurteilung moderner Technik (Abb. 1).
Aber wäre damit alles über die Schönheit einer Software gesagt? Wahrscheinlich nicht. Irgendwie steckt mehr dahinter, eine Benutzerführung muss nicht unbedingt intuitiv und schon gar nicht effizient sein, um als schön empfunden zu werden. Auch dass ein Algorithmus elegant programmiert ist bedeutet nicht unbedingt, dass er optimal ist hinsichtlich Performance oder Wartbarkeit, noch, dass er den idealen Kompromiss zwischen Performance und Wartbarkeit darstellt.
Man könnte an dieser Stelle einwenden, dass es ja durchaus sein mag, dass irgendjemand einen feinen Unterschied zwischen der Erfüllung nicht funktionaler Anforderungen wie Performance, Wartbarkeit und Bedienerfreundlichkeit auf der einen Seite und „Schönheit“ oder „Eleganz“ auf der anderen Seite macht. Dass es dann aber völlig unerheblich sei, ob eine Software, ihre Architektur oder ihr Code in irgendeinem esoterischen Sinne schön sei. Wesentlich und letztlich entscheidend wäre doch nur, dass die nicht funktionalen Anforderungen der Spezifikation erfüllt sind. Das aber ist nicht so sicher.
Der Harvard-Professor David A. Garvin hat sich vor einem Vierteljahrhundert mit der Frage beschäftigt, was der Begriff „Produktqualität“ bedeutet. Er identifizierte drei Ansätze, aus denen sich die Qualität eines Produktes bestimmen lässt: den nutzer-, den produkt- und den produktionsbasierten Ansatz. Diese drei hängen zusammen: Die Marktsicht des nutzerbasierten Ansatzes macht die Vorgaben für die produktbasierten Qualitätsparameter, die wiederum die produktionsbasierten Qualitätseigenschaften bestimmen.
Es gibt nach Garvin drei nutzerbasierte Qualitätsdimensionen: Performance im Sinne der Funktionserfüllung als Ganzes, Aesthetics und Perceived Quality. Während die Perceived Quality so etwas wie Markenwahrnehmung betrifft, geht es bei den Aesthetics ganz im ursprünglichen Sinne um die Frage, wie die Sache sich anfühlt, wie sie erscheint. Eben, ob sie als schön und attraktiv oder hässlich und abstoßend wahrgenommen wird. Ästhetik ist also ein ganz wesentlicher Aspekt der Produktqualität.
Mit dem Stichwort Attraktivität kommt ein anderer Klassiker der Bestimmung von Produktqualität ins Spiel, der ja auch im Software-Requirements-Engineering kein Unbekannter ist: der Artikel „Attractive Quality and Must Be Quality“ des japanischen Qualitätsmanagement-Gurus Noriaki Kano und Kollegen. „Attractive Quality“ – das ist das, was beim Kunden Begeisterung auslöst. Schaut man sich die irrationale Freude von Benutzern mancher schwarzer Smartphones oder weißer Notebooks an, weiß man schnell, was gemeint sein könnte.
(js)
Den vollständigen Artikel finden Sie in iX 2/2012.
Heft bestellen Dieser Text ist der Zeitschriften-Ausgabe 02/2012 von iX entnommen. Das Heft kann online portokostenfrei bestellt werden.
