Montag, 20. Oktober 2014

Einfachheit - eine kurze Einführung

Verstoß gegen das Prinzip der Einfachheit: 
eine Rube-Goldberg-Maschine (Quelle: Wikipedia)
Dies ist der erste Artikel einer kleinen Serie über das "Prinzip der Einfachheit". Da insbesondere die Terminologie sowie die grundlegenden Annahmen, welche der Vorstellung von Einfachheit zu Grunde liegen, sich in der Literatur teils stark unterscheiden, werde ich in dieser Einführung festlegen, wovon im Kontext der Softwaretechnik die Rede ist, wenn wir von "Einfachheit" sprechen, und mit welcher Bedeutung ich die damit zusammenhängenden Begriffe nutzen werde.


1. Einfachheit als Gegenbegriff

Einfachheit (engl. simplicity) ist in vielerlei Hinsicht ein Gegenbegriff. Autoren, die über Einfachheit schreiben, gehen oftmals implizit von einer Skala aus, auf deren einen Seite die Einfachheit steht und deren andere Seite sie durch einen Gegenbegriff festlegen oder nicht eindeutig benennen. Kandidaten für die Gegenseite sind beispielsweise "Komplexität", "Kompliziertheit" oder "Schwierigkeit". Insofern sich die jeweiligen Modelle auf die Gegenbegriffe konzentrieren, bedeutet Einfachheit für diese Autoren das Fehlen von bzw. eine niedrige Ausprägung von Komplexität, Kompliziertheit, Schwierigkeit usw.


2. Einschränkung auf Systeme

Ein weiteres Problem, das sich beim Einstieg in die Thematik stellt, ist der gemeinte Gegenstandsbereich, dessen Objekte die Eigenschaft der Einfachheit aufweisen können. Im Kontext der Softwaretechnik dürfen wir uns dabei zunächst auf Systeme einschränken und ignorieren andersartige Forderungen nach Einfachheit, wie sie beispielsweise im Bereich der Kunst ("Weniger ist mehr!") oder der wissenschaftlichen Theoriebildung ("Ockhams Rasiermesser") vorkommen. 

2.1. Struktur und Verhalten

Bei der Betrachtung von Systemen kann man sich wiederum einerseits auf die Struktur oder andererseits auf das Verhalten eines Systems beziehen. Dass diese beiden Aspekte nicht notwendigerweise eng zusammenhängen, zeigt beispielsweise die Komplexitätstheorie (engl. computational complexity theory) als Teilbereich der Informatik, die sich auf den Ressourcenverbrauch von Algorithmen bezieht und somit das Verhalten in den Vordergrund stellt. Auch sehr "komplexe" Algorithmen im Sinne der Komplexitätstheorie können jedoch strukturell vergleichsweise einfach sein.


3. Kognition und das System als ihr Gegenstand

Schließlich hat jede Form von Einfachheit und ihr Gegenbegriff zwei Seiten, die untrennbar zusammengehören: Auf der einen Seite befindet sich der Gegenstand, um den es geht, im Falle der Softwaretechnik also das System. Auf der anderen Seite steht der Mensch, der mit dem System umgeht. Dieses Mit-dem-Sytem-umgehen wird oftmals dem Bereich der Kognition zugeordnet, da kognitive Prozesse im Umgang mit einem System eine Hauptrolle spielen und insbesondere, da diese Prozesse natürlichen Beschränkungen unterliegen. Der mit dem System umgehende Mensch muss also beispielsweise das System verstehen, er muss vorhandene Probleme lösen oder die Korrektheit einer Systemfunktion überprüfen.

3.1. Kognitiver Aufwand und Vorhersagbarkeit

Dabei ist er sowohl mit der Struktur als auch mit dem Verhalten des Systems konfrontiert: Die Struktur liegt ihm in Form der Artefakte des Software-Systems vor, insbesondere in Form von Quellcode und zugehörigen Ressourcen. Eine Struktur erscheint in diesem Sinne einfacher, wenn sie kognitiv leichter verarbeitet werden kann. Auf der kognitiven Ebene korrespondiert also mit einer weniger einfachen Struktur ein erhöhter kognitiver Aufwand

Der Mensch muss jedoch auch mit dem Verhalten des Systems umgehen, und dies keineswegs nur zur Laufzeit. Auch bei der Erstellung oder beim Lesen von Programmcode muss er häufig das Systemverhalten im Geiste simulieren, um vorhersagen zu können, ob sich das System unter allen denkbaren Umständen angemessen verhält. Die kognitive Ebene, die mit dem Verhalten des Systems korrespondiert, bezeichne ich mit [Url:Appelo2010] als Vorhersagbarkeit (engl. ability to predict).


4. Zusammenfassung

Der oben vorgenommenen begrifflichen Festlegungen lassen sich wie folgt veranschaulichen:
Ich lehne mich mit dieser Einordnung an das Structure-Behavior Model von Jurgen Appelo an [Url:Appelo2010], weiche aber in folgender Hinsicht von seinem Modell ab:
  • Appelo spricht lediglich von Verständlichkeit (engl. ability to understand) und nicht von kognitivem Aufwand. Verstehen ist jedoch im Umgang mit Software-Systemen nur eine von mehreren kognitiven Tätigkeiten, die durch fehlende strukturelle Einfachheit erschwert werden. Beispielsweise wird auch die Lösung von Problemen oder das Überprüfen der Korrektheit einer Systemfunktion durch fehlende Einfachheit aufwändiger.
  • An Hand seines Modells unterscheidet Appelo zusätzlich die Begriffe Komplexität und Kompliziertheit. Für Appelo ist "Kompliziertheit" eine reine Struktur-Eigenschaft, die sich aus der Anzahl der Elemente und Relationen im betrachteten System ergibt. Komplexität entsteht für ihn jedoch erst dann, wenn zusätzlich zu einer hohen Kompliziertheit die Vorhersagbarkeit des Systems problematisch wird. Beispielsweise ist eine mechanische Uhr kompliziert, doch ihr Verhalten ist dennoch sehr vorhersagbar, und somit ist sie nicht komplex. Im Sprachgebrauch der Softwaretechnik sprechen jedoch die meisten Autoren auch dann von Komplexität, wenn sie nur strukturelle Eigenschaften untersuchen. Ich folge hier dem etablierten Sprachgebrauch und werde explizit kenntlich machen, wenn verhaltensabhängige Aspekte für meine Betrachtung relevant sind.

Quellen

[Url:Appelo2010] - Simplicity - A New Model, Jurgen Appelo, siehe http://www.noop.nl/2010/09/simplicity-a-new-model.html (2010)