2017-10-30 digital life Komplexitaetsarten Bewusstsein Zu den wichtigsten Lektionen eines Studenten der praktischen In- formatik gehoert meiner Meinung nach die Bewertung von Komplexi- taet und ihre Unterscheidung in zufaellig und essenziell (um Brooks' Begriffe zu verwenden). Leider spiegelt sich dies in den Lehrplaenen nicht wider. Die Praxisprobleme von realen Softwaresystemen zeigen uns die Folgen. Zufaellige Komplexitaet ist diejenige, die vermieden werden muss. Man tut dies durch bessere Konzepte, bessere Datenstrukturen und bessere Algorithmen. Dies zu tun ist eine der Kernaufgabe von Software-Entwicklern. Essenzielle Komplexitaet ist diejenige, die nicht reduziert wer- den kann, da sie dem Problem eigentuemlich ist. Sie muss angenom- men werden. Die Kernkonzepte muessen sich an ihr orientieren. Sie verringern zu wollen fuehrt im Allgemeinen zu Folgeproblemen. Nehmen wir ein Praxisbeispiel: Emailadressen koennen neben der eigentlichen Adresse auch einen Anzeigenamen anbieten. Die eigentliche Adresse ist eine essenzielle Komplexitaet. Sie hinter dem Anzeigenamen zu verstecken, um es dem unbedarften User einfacher zu machen, macht es auch den Spammern und Phishern ein- facher den unbedarften User zu irritieren. Sein Mainprogramm sug- geriert ihm naemlich, der Anzeigename sei eine essenzielle Infor- mation und die eigentliche Emailadresse nur zufaellige Komplexi- taet (aehnlich wie Domainnamen und IP-Adressen) ... dabei ist aber die tatsaechliche Mailadresse die essenzielle Information. Da aber auch Absenderadressen gefaelscht werden koennen, muss dem User Zugriff auf die Received-Header angeboten werden, um Rueck- schluesse zuzulassen. RFC 821/822-Header in ihrer ``Quelltextform'' lesen zu muessen kann man als zufaellige Kom- plexitaet ansehen, den Transport von Email zu verstehen sollte man aber als essenzielle Komplexitaet werten. Eine ebensolche essenzielle Komplexitaet ist die Unterscheidung zwischen der persoenlichen Antwort, der Antwort an alle und der Antwort an die Mailingliste. Die Frage, wie man antworten will, muss intellektuell entschieden werden. Darum braucht der User mehr als einen Reply-Button. Es gibt schlimmere Probleme als die beiden hier skizzierten, aber ich finde, dass diese zwei anschaulich zeigen, wie falsche Entscheidungen bezueglich der Komplexitaetsarten in den Email- Clients die User auf falsche Pfade fuehren und in Folge ein ver- faelschtes Gedankenmodell des unterliegenden Systems praegen. Dies ist kaum noch zu korrigieren. Letztlich wird mit dieser ``Computer sind einfach!''-Werbeidee eine Erwartungshaltung geschaffen, die nicht erfuellt werden *kann*. Die Folgen sind scheiternde User. Dabei kann die Compu- ternutzung durchaus auch einfach sein, bloss nicht an jeder Stelle. Man muss vermitteln, dass die essenzielle Komplexitaet an den User weitergereicht werden muss und dass dieser, wenn er den Computer fuer Anwendungen von komplexem Inhalt nutzen will, diese inhaltliche Komplexitaet natuerlich verstehen muss. Das ist wie einem kein Computer und keine Software helfen kann richtig zu re- chnen, wenn man den Sachverhalt, den man berechnen will, nicht versteht. Als Beispiel fuer das gegensaetzliche Problem moechte ich PGP an- fuehren. Korrekterweise wird dort all die essenzielle Komplexi- taet an den User weitergereicht. Das ist viel und fordernd, doch geht es hier um Vertrauen und das ist hoch komplex und indivi- duell. Die Komplexitaet ist der Sache inherent. Was in dem Umfeld aber schlecht gelaufen ist, ist der Umgang mit der zufaelligen Komplexitaet, die nicht in ausreichendem Masse reduziert worden ist. Man kann und muss von Usern fordern, mit der essenziellen Kom- plexitaet umzugehen. Man kann und darf aber nicht von ihnen for- dern, mit zufaelliger Komplexitaet umgehen zu muessen. Darauf kommt es meiner Meinung nach in der praktischen Informatik an. Das wuerde ich gerne im Studium (mindestens an der Uni) erk- ennen koennen. http://marmaro.de/apov/ markus schnalke