Das Schöne und der Code

Inhaltsverzeichnis

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.

Schönheit und Anforderungserfüllung

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.

Mehr Infos

iX-Tract

• Da Software alle Bereiche des Lebens durchdringt, ist eine rein funktionale Beurteilung von Programmen nicht mehr ausreichend.
• Sowohl Programmoberflächen als auch Programmcode müssen sich einem ästhetischen Urteil unterwerfen.
• Zu klären ist, was Schönheit in diesem Zusammenhang bedeutet.
• Anleihen bei der Philosophie sind für diese längst überfällige Debatte hilfreich.

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.

Gelernter bleibt in Detailkritik stecken

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.

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.

Die Frage nach der Produktqualität

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.

Schön, angenehm und nützlich

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.

Den vollständigen Artikel finden Sie in iX 2/2012. (js)