Das Prinzip der minimalen Verwunderung

Name, Kurzform	Prinzip der minimalen Verwunderung
Synonyme	Prinzip der geringsten Überraschung, Principle/Rule/Law of Least Astonishment (PLA, POLA), Principle/Rule/Law of Least Surprise (POLS)
Beschreibung	Software sollte so konstruiert sein, dass sie von allen mit ihr befassten Akteuren mit minimaler Verwunderung wahrgenommen werden kann.
Erläuterung	Das Prinzip der minimalen Verwunderung kommt in zahlreichen unterschiedlichen Formulierungen vor, die jeweils einen bestimmten Aspekt der Interaktion mit einer Software hervorheben. Die folgende Abbildung stellt einige wesentliche auf Software bezogene menschliche Handlungen dar, die wir bereits bei der Kategorisierung der Prinzipien zusammengetragen hatten: Einige dieser Perspektiven forcieren den Begriff der Schnittstellle: Ein Benutzer, der die Software ausführt, verwendet eine Benutzungsschnittstelle (User Interface, UI). Ein Entwickler, der eine Software ändert oder wiederverwendet, interagiert mit der Enwickler-Schnittstelle (Application Programming Interface, API). Für andere Sichten liegt der Schnittstellen-Begriff weniger nahe, doch die betreffenden Akteure dürfen mit derselben Berechtigung darauf hoffen, dass die Software nur minimale Verwunderung bei ihnen auslöst. Ich habe daher eine möglichst allgemeine Formulierung gewählt, die keine wesentliche Benutzergruppe vom Prinzip ausschließt. Selbst nicht-menschliche Akteure sind vorstellbar, wenn man den anschaulichen Begriff der Verwunderung im Sinne der Einhaltung technischer Standardlösungen interpretiert.
Beispiel(e)	Für jeden der oben abgebildeten Akteure beziehen sich die folgenden Beispiele auf unterschiedliche Element-Typen. Z. B. sind für den Benutzer die Elemente der Benutzungsoberfläche wie Buttons, Menüeinträge, Links (usw.) relevant, für den Entwickler sind es Quellcode-Elemente wie Klassen, Interfaces, Methoden (usw.), für den Betreiber hingegen Dateien, Adressen, Tabellen (usw.). Für all diese Elemente sollte erreicht werden: Vermeidung irreführender Namensgebung Positionierung an erwartbaren Stellen Konsistente Behandlung ähnlicher Probleme Vermeidung von Seiteneffekten Berücksichtigung von Standardlösungen
Historie	Im Jahr 1987 taucht das Prinzip erstmals in zwei Publikationen auf: In einem wissenschaftlichen Artikel über Constraint-Hierarchien erwähnen Alan Borning und Kollegen das Prinzip beiläufig [Borning1987]. Am Xerox PARC, wo Borning zu dieser Zeit tätig war, wurden Konzepte und Technologien grafischer Benutzerschnittstellen damals intensiv untersucht, so dass nicht auszuschließen ist, dass das Prinzip dort so geläufig war, dass Borning es nicht für nötig hielt, es eigens zu erläutern. Die zweite Publikation, in der das Prinzip erwähnt und auch erläutert wurde, ist das „Tao of Programming“ von Geoffrey James. Dort heißt es: „A program should follow the `Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.“ Als relativ gesichert darf gelten, dass das Prinzip zunächst ausschließlich auf die Benutzung von Software bezogen war und erst später auch auf Programmierschnittstellen übertragen wurde. Im Lauf der Zeit fanden sich auch prominentere Zeitgenossen, die dass Prinzip anführten: Grady Booch erwähnt das Prinzip in [Booch2003] aus der Sicht des Entwicklers und führt explizit die Vermeidung von Seiteneffekten bei Systemänderungen an. Eric Raymond hebt 2004 in „The Art of Unix Programming“ die Bedeutung des Prinzips für alle Arten von Benutzerschnittstellen (nicht nur Software) hervor [Raymond2004]. In einer Keynote zur OOPSLA-Konferenz 2005 führt Joshua Bloch das Prinzip als ein Qualitätsmerkmal guter Programmierschnittstellen an [Bloch2005].
Art des Prinzips	Grundlegende Einteilung: Produktprinzip. Technologiebezug: Allgemeingültig. Entwurfsgüte: Allgemein. Handlungsbezug: Allgemein. Kognitionsbezug: Standardisierung, Komplexitätsreduktion, Konsistenz. (Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation	Keine formale Spezifikation.
Vorteile	Einfach nachvollziehbar. Auf alle Arten von Interaktion mit Software anwendbar.
Nachteile	Informelles Prinzip, daher viel Spielraum für Interpretationen.
Übergeordnete Prinzipien	-
Abgleitete Prinzipien	-
Qualitätsmerkmale	(+) Verständlichkeit, (+) Wartbarkeit, (+) Änderbarkeit, (+) Wiederverwendbarkeit

Quellen

[Bloch2005] - How to Design a Good API and Why it Matters, siehe Foliensatz unter http://lcsd05.cs.tamu.edu/, Joshua Bloch (2005)

[Booch2003] - The illusion of simplicity, Grady Booch (2003)

[Borning1987] - Constraint Hierarchies, Borning A., Duisberg R., Freeman-Benson, B., Kramer A., Woolf, M. (1987)

[Raymond2004] - The Art of Unix Programming, Applying the Principle of Least Surprise, Eric Raymond (2004)