W.T.F.M. – Write the fucking manual

/*

Das Akronym RTFM („read the fucking manual“) gibt es vermutlich so oder in ähnlicher Form schon so lange wie es Computer und technische Systeme gibt. Milliardenfach zitiert und in Boards und Foren fast allgegenwärtig eingefügt wurde dieser Terminus von Nutzern, Entwicklern und Technikern auf der gazen Welt sicher viel gehasst aber auch geliebt.

In der heutigen schnellebigeren Internetzeit, in der Systemlebenszyklen von Dekaden auf Monatsbalancen schrumpfen, verkehrt sich die Meinung dieses knappen Satzes zwischenzeitlich in eine ganz andere als ursprünglich gemeinte Richtung. War es früher üblich Systeme umfangreich zu dokumentieren, mit Beispielen zu versehen und von Entwicklerseite her Zweck und Anwendung aller Bestandteile eindeutig klarzustellen, ist das heute schon fast die glänzende Ausnahme.

Da gibt es heute hochkomplexe APIs, Schnittstellen, Tools und ganze Anwendungen die kaum dokumentiert sind. Früher wurde ein Benutzer mit einem System im ersten Moment alleine gelassen, ohne befähigung zur Hilfe oder nur zu einem direkten Kontakt; eine Doku war zwingende Voraussetzung das das System überhaupt benutzbar war. Das erste Modem kam in der Regel mit einer Bibel an Befehlen, Referenzen und oft sogar mit einem Demo-Terminalprogramm das gewisse Dinge sofort zugänglich machte.

Heute werden Nutzer, Admins und entwicler öfter vor Herausforderungen gestellt, die mit „da ist ein System das kann X“ beginnen. Ganze Serverclusterzugriffe kommen mit einer hauchdünnen Briefmarke an „Schnelleinstiegsdokumentation“, in-System Beschreibungen sind oft zu einer ungepflegten Kür verkommen und ganze Datenbanken ändern von Version zu Version ihr Schema – dokumentierne aber immer nur die letzte Änderung. Für langfriste Systemerfolger macht das vielleicht sogar Sinn, aber jeden Frischling stößt diese scheinbar allgegenwärte Philosophie mit voller Härte vor den Kopf.

Vielleicht mag dieser Aufruf ungehört verhallen. Aber im Namen aller Nutzer, Admin sund Entwickler dieser Welt: Dokumentiert für euch – auch gegenseitig. Entwickler die ihren Code lieben, Lebenszeit und Herzensblut investieren: Dokumentiert euer Meisterwerk. an vielen Stellen muss es auch nicht die NASA-Kompatible Totalübersich sein, aber sagt uns doch was Ihr im Sinn hattet wenn ihr Dinge gebaut habt. Dokumentiert Parameter, dokumentiert Ausgaben und vielleicht sogar bekannte Szenarien. Admins die das Rückrat ihres Unternehmens lebendig halten, jede Menge Vorgänge automatisieren und Konfigurationen verteilen: Dokumentiert Sinn un dZweck von dem was ihr tut. Nutzer die Dokumente, Tabellen oder Workflow nutzen, entwerfen, Anpassen oder Meisterwerke vollenden: Teilt euch in einer Doku mit. Was wo warum und oft auch wann geschah ist der Schlüssel zum Effizienten Einsatz, zur frustfreien Nutzung, zum motivierten Start und zur (nicht zu unterschätzendem) Effekt-Toleranter Einsicht in bestimmten Situationen.

Dokumentiert, aber sinnvoll.

*/

Vielen, vielen Dank. Ein zu beginn des Wochenendes  von Amazon, Apple und verschiedenen Open-Source-Projekten genervter Administrator.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*