2015-01-08 digital life Unzulaenglichkeiten Ein Scheisstag Das Jahr ist noch so jung und ich habe es richtig entspannt be- gonnen. Jetzt beschaeftige ich mich aber mit fremder Software und muss schon aufstoehnen. Es ist ja nicht so, dass ich nicht wuesste, wie ich das hinnehmen sollte, es ist nur so, dass es mir so unendlich schwer faellt. Ich tue mir enorm schwer mit den vermeidbaren (!) Unzulaenglichkeiten den Welt zurechtzukommen. Sie tun mir weh, in der gleichen Weise, wie einem das Ansehen von Massentierhaltungen oder Folterungen weh tut. Da ist ein scheinbar wunderbares Handbuch geschrieben worden, das macht echt was her ... aber halt leider nur an der Oberflaeche. Fast zweihundert Seiten ist es fett, alles bunt, anschaulich, mit Screenshots und so. Aber, es beginnt damit, zu beschreiben, wie man in Windows eine Zip-Datei entpackt ... als Klickanleitung, mit Screenshots, auf drei Seiten. Und dann nochmal vier Seiten darueber, wie man eine ausfuehrbare Datei startet und wie man ein grafisches Programm beendet. WTF! Das ist eine Anleitung fuer Idioten, fuer Computernutzer die nicht wissen was die linke Maus- taste ist! Was ist das fuer ein Ansatz? Wo ist der muendige und faehige Computernutzer? Kann man denn nicht erwarten, dass ein Mausnutzer weiss was die linke Maustaste ist? Kann man nicht erwarten, dass ein Linkshaender weiss, dass seine Tasten an- dersrum sind? Will man sonst auch noch dazu schreiben wie man bei einer Zwei-Tasten-Maus die mittlere Taste betaetigt, und wie man beim Mac rechts klickt, und dass ein Touchpad eigentlich das gleiche ist wie eine Maus nur ganz anders aussieht? Muss also jede Anleitung auch noch erklaeren wie man einen Computer ein- schaltet? Nein! Wir sollten doch wirklich gelernt haben, dass unser deutsches Rechtssystem, das vom muendigen Buerger ausgeht, grosse Vorteile hat gegenueber dem amerikanischen Rechtssystem, bei dem man ueberall dazuschreiben muss, dass man keine Hamster in die Microwelle stecken darf ... und auch keine Katzen und auch keine Hunde und noch nicht mal Krokodile! ... und dass Rauchen uebrigens schaedlich kein kann. Ich dreh' echt am Rad! Aber das ist an meinem Schreibstil ja schon ersichtlich. Also: Nachdenkende Menschen sollten erkannt haben, dass es struk- turell schlecht ist, ueberall alles nochmals aufzufuehren und so sollten sie konsequenterweise darauf verzichten einem gegenteili- gen Bauchgefuehl nachzugehen. Wir muessen anfangen Menschen fuer vollwertig zu erachten und wir muessen anfangen zu erwarten, dass Menschen, die einen Computer nutzen, ihn auch bedienen koennen, d.h., dass sie diese Grundkonzepte woanders gelernt haben. Und folglich muessen wir ihnen auch unsere Grundkonzepte vermitteln. Sie muessen Grundfaehigkeiten lernen, nicht Klickanleitungen be- folgen. Also, entweder man schafft es endlich *intuitive* Oberflaechen *und* Systeme zu schaffen, oder -- falls man zu dem Schluss kommt, dass dies nicht moeglich ist (wovon ich ueberzeugt bin) --, dann muss man dazu uebergehen ein Set an Grundkonzepten und -faehigkeiten je System und Oberflaeche zu definieren und an- schliessend zu vermitteln, eben in der gleichen Weise, wie wir in der Grundschule Lesen, Schreiben und Rechnen lernen, oder zuhause wieviel eine Messerspitze Mehl oder eine Prise Zucker ist. Das ist der einzige Weg, der mir bekannt ist, wie man effizient kom- plexe Systeme aufbauen und benutzbar halten kann. Eigentlich ergibt sich das letztlich ueberall so in der Art, nur halt nicht explizit. Und dann gibt es da sowas wie dieses Hand- buch, dessen Autoren dachten, sie taeten dem Benutzer etwas Gutes, wenn sie Grundwissen von ausserhalb ihrer Domaene nochmal mit aufnehmen wuerden, und das auch noch auf Idiotenart. Nein, sie tun dem Nutzer nichts Gutes damit, sie schaden ihm. Sie schaden sogar der ganzen Softwarekultur. Sie tragen zu ihrem Un- tergang bei. Sie setzen Drachen in die Welt. Wie wenn wir nicht schon genug von den Biestern haetten! Wenn ich nur an all die Drachen denke, die wir aus historischen Gruenden jetzt schon bekaempfen muessen! Man koennte meinen, langsam muesste man doch gelernt haben, dass man vorsichtig damit sein muss. Man muesste doch gelernt haben wo die Probleme, die wir heute haben, herkom- men. Und man muesste doch sehen, was wir heute vermeiden muessen, dem Morgen zuliebe. Lernen wir denn gar nichts aus der Ver- gangenheit? Oder steht nur jeden Tag ein neuer Idiot auf? Nein, sie tun dem Nutzer nichts Gutes. Was ist denn wichtig bei so einem Handbuch? Das wuerde ich gerne fragen. Warum sollte es dick oder warum duenn sein? Die Autoren haetten mal Dijkstra lesen sollen! Dijkstra hat die Erkenntnisse schon offen dar- gelegt, man haette sie nur aufsammeln muessen! Ist nicht das der Sinn unserer Schulbildung: Aufzunehmen was schlaue Leute heraus- gefunden haben? My point today is that, if we wish to count lines of code, we should not regard them as ``lines produced'' but as ``lines spent'': the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. [0] Der Autor des Handbuchs weiss nicht, was es noch kosten wird, dass dieser idiotische Abschnitt vorhanden ist. Hier meine ich nicht nur die Auswirkung auf die Erwartungen unserer Gesellschaft und deren Folgen, nein, es gibt ganz konkrete Kosten: Fuer jedes Betriebssystem, fuer jede Oberflaeche muss der Abschnitt angepasst werden. Mit jeder neuen Windows-Version muessen neue Screenshots gemacht werden. Die muessen vermutlich manuell nach- bearbeitet werden. Alle Sonderfaelle muessen bedacht und beschrieben werden, denn wenn man eine Idiotenanleitung schreibt, dann muss man davon ausgehen, dass sich der Nutzer wie ein Idiot verhaelt -- und ganz im Ernst, das sollte er auch, denn wenn er anfaengt zu denken, dann faellt er aus dem Zielpublikum der An- leitung und wird dann erst recht Probleme hervorrufen. Und dann die Kosten, fuer alle, die das 200 Seiten Handbuch lesen muessen! Die Kosten es auszudrucken! Die Kosten es korrekturzulesen. Die Kosten das Handbuch zu aktualisieren! Es scheint noch immer nicht die Erkenntnis angekommen zu sein, dass die meiste Arbeit in der Betreuung und Entwicklung stecken und die erste Erstellung nur einen Bruchteil davon ausmacht. Geschrieben wurde das Dokument aber mit einer One-Shot-Mentalitaet. Wer wuerde sonst so viele Screenshots wie moeglich darin verbauen? Screenshots sind super teuer zu pflegen, viel viel teurer als Text. Grafiken sind ungemein wertvoll, aber sie kosten -- das ist es, was Dijkstra sagt. Das ist es, was die Erfahrung zeigt. Das ist es, was scheinbar immer noch nicht erkannt wurde. Ich kann es mir einfach nicht erklaeren! Ausser, ja, ausser es liegt an der Schnelllebig- keit der Zeit: Diejenigen, die es erstellen sind schon nicht mehr diejenigen, die es betreuen muessen. Diejenigen, die die Er- fahrungen gemacht haben, haben keine Zeit aus ihnen zu lernen. (In der Bildung werden sie schon gar nicht vermittelt.) Oder wenn sie sie gelernt haben, dann sind sie anderen Einfluessen un- terworfen, so dass ihr Erfahrungswissen nicht einfliessen kann. Aber gerade wenn die Zeit schnelllebig ist, wie kann man dann so ein fettes Handbuch erstellen? Wuerde man nicht versuchen, es so duenn wie moeglich zu machen, ohne etwas Wesentliches wegzu- lassen? Dann waeren wir bei der mathematischen Eleganz: Die kuerzeste ausreichende Loesung ist die beste. (Man darf das nicht zu hart auslegen, aber es ist weit besser diese Regel hart auslegen als das momentan uebliche Verhalten anzuwenden.) Das Handbuch wird deshalb nicht kuerzer gemacht, weil Kuerze Aufwand bedeutet, v.a. intellektuellen Aufwand. Dumm und fett, das geht schnell und das optisch schoen Machen geht dann auch noch fix genug. Optisch muss es zumindest nett sein, und dick muss das Buch sein, denn sonst gibt es ja nichts was daran zu bewerben waere. Man taete besser daran, das Optische zu ignori- eren und dafuer die Energie in die Destillation der Information in ein kleines Set an Grundkonzepten und -kenntnissen zu stecken. Provokant formuliert: Wenn es mir moeglich ist, die wesentliche Information in zehn Grundkonzepten zu destillieren, dann ersetze ich dieses 200-Seiten-Handbuch durch ein 10-Seiten-Dokument und habe dem Nutzer damit ein wertvolleres Hilfsmittel an die Hand gegeben. Ob mir das gelingt, haengt aber von der Software ab. Da sind wir nun am zweiten Aspekt meines Frustes: Das Handbuch ist auch deshalb so lang, weil die Software so scheisse ist. Wenn ich fuer fuenf aehnliche Funktionen fuer unterschiedliche Beschreibungen brauche, dann muss das Handbuch fett werden. Stattdessen haette schon im Programm die Destillation auf Grundkonzepte stattfinden sollen. Wenn ich zwei Seiten Text brauche, um zu erklaeren welcher Menueeintrag was tut, dann ist das Menue sowohl schlecht strukturiert als auch schlecht beschriftet. Haette man sich einen ganzen Tag genommen, um das Menue gut zu strukturieren und um gute Begriffe zu finden, dann haette man in allen nachgelagerten Schritten zusammen hundert Tage eingespart. So aber schleppt man diesen Drachen viele Jahre mit sich rum und alle anderen Beteiligen ebenso. Da versteht man erst, was Fred Brooks' Erkenntnis (hier in Scott Rosenbergs zusammenfassenden Worten) wirklich bedeutet: A great programmer was typically able to produce ten times as much work in a given amount of time as a mediocre one, and the work was typically five times as good [...] [1] Naemlich: The conclusion is simple: if a 200-man project has 25 managers, who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming. [2] Programmierer sollten, ganz im Sinne Dijkstras, fuer Codeueber- laenge Strafe zahlen muessen! Programmierer sollten auch Strafen zahlen muessen, wenn umfangreiche Handbuecher noetig sind! Strafen sind natuerlich doof; es geht hier auch nur um die Sichtweise. Die Programmierer sollten natuerlich viel eher selbst die Handbuecher schreiben und dabei erkennen wo ihre Programme schlecht entworfen sind, wo klare Konzepte fehlen. -- Ich haenge sehr an den Konzepten, denn sie sind fuer mich die Essenz von guter Software, von Texten ... von Information. Konzepte bedeu- ten klare Strukturierung. Konzepte bedeuten Kuerze. Konzepte bedeuten vielfache Anwendbarkeit. Konzepte bedeuten lange Halbwertszeiten. Konzepte bedeuten Effektivitaet. Ach! Wie ich nun so von den schoenen Aspekten der Softwarewelt -- Konzepte, Klarheit, Struktur, ... -- schreibe, da beruhige ich mich emotional auch wieder. Gerade wollte ich noch hin klatschen, dass ich gerne mal Programmierer und Dokumentationsschreiber zu jedem Abschnitt, zu jedem Absatz, zu jeder Zeile fragen wuerde, warum er es wert ist, dass dafuer Kosten in Kauf genommen werden. Da wuerde ich erbarmungslos neben den armen Opfern sitzen und sie jede einzelne Zeile ihrer Werke verteidigen lassen ... und dabei waere das keinesfalls unangebracht, es ist naemlich gerade umgekehrt: Ich bin das Opfer und sie die Verursacher, die mir das Leben zur Hoelle machen. Es waere nur fair, wenn sie fuer ihre Verbrechen gerade stehen muessten. (Ich habe nichts gegen notwen- dige Komplexitaet, ich bekaempfe nur ihre vermeidbare Abart.) Ich denke, ich habe mich inzwischen wieder soweit beruhigt, dass ich zum Abschluss nicht mehr schreiben muss, dass heute ein Scheisstag ist und dass mich alles ankotzt. Vorhin war das noch so ... und ich fuerchte, dieses Gefuehl wird sich wieder einstel- len, sobald ich mich der verursachenden Aufgabe erneut widmen werde, was leider unabkoemmlich ist. :-( [0] Dijkstra, EWD1036 (Dieses EWD ist so ueberaus lesenswert, dass seine Lektuere in Ergaenzung zu diesem Text hiermit verord- net wird.) [1] Scott Rosenberg: Dreaming in Code, S. 18 [2] Fred Brooks: The Mythical Man-Month, S. 30 http://marmaro.de/apov/ markus schnalke