Warum Dokumentation unverzichtbar ist
Wissen, das nicht dokumentiert ist, verschwindet. Vielleicht ist der Entwickler im Urlaub. Vielleicht hat jemand das Projekt verlassen. Vielleicht sind schlicht zu viele Details im Spiel, um sie alle im Kopf zu behalten.
Dokumentation macht implizites Wissen explizit. Sie sorgt dafür, dass Entscheidungen nachvollziehbar bleiben, dass Zusammenhänge klar werden und dass Teams nicht immer wieder dieselben Fehler machen.
Ich habe oft erlebt, dass Teams Dokumentation unterschätzen, bis der erste Schock kommt. Ein Problem tritt auf, niemand erinnert sich an den ursprünglichen Grund einer Entscheidung, und das Rad wird neu erfunden. Das kostet Zeit, Geld und Nerven.
Dokumentation als Teil des Handwerks
Kein Handwerker würde ohne Skizze, Bauplan oder Massangabe arbeiten. Ein Tischler notiert, welche Materialien er verwendet hat. Ein Maurer hinterlässt exakte Masse. Ein Schneider erstellt Schnittmuster.
In der Programmierung gilt dasselbe: Dokumentation ist kein „Extra“, sondern Teil des Handwerks. Sie macht das Werkstück überhaupt erst nutzbar.
Wenn ich auf ein Projekt schaue, ist eines meiner ersten Signale: Wie ernst nimmt das Team Dokumentation? Ist sie sichtbar, verständlich und gepflegt, oder liegt irgendwo eine verstaubte Datei, die seit Jahren niemand mehr geöffnet hat?
Der richtige Umfang
Gute Dokumentation ist eine Gratwanderung. Zu viel Text liest keiner. Zu wenig Text hilft niemandem. Die Kunst liegt darin, den Kern zu treffen: so viel wie nötig, so wenig wie möglich.
Es ist keine Selbstverständlichkeit, gute Dokumentation zu schreiben. Auch das muss man erlernen. Viele Teams denken, Dokumentation entstehe von selbst, sie tut es nicht. Man muss sie bewusst pflegen.
Und: Teams brauchen einen gemeinsamen Dokumentationsstil. Sonst wirkt jedes Dokument wie aus einer anderen Welt. Ein einheitlicher Stil macht Dokumentation leichter lesbar und sorgt dafür, dass sie nicht als Last empfunden wird.
Ich empfehle Teams oft, klare Regeln zu definieren: Welche Arten von Informationen gehören in die README? Wie dokumentieren wir Architektur-Entscheidungen? Wo legen wir fest, welche Abkürzungen wir bewusst wählen? Solche Vereinbarungen sparen später unendlich viel Zeit.
„Zu viel liest keiner, zu wenig hilft niemandem, gute Dokumentation ist eine Kunst.“
Unterschiede in Programmiersprachen
Interessant ist auch, wie unterschiedlich Programmiersprachen mit Dokumentation umgehen. Im Java-Umfeld ist es üblich, viel Text direkt im Code zu hinterlassen. Jede Methode bekommt eine Erklärung, jeder Parameter eine Beschreibung. Die Kultur setzt auf ausführliche Kommentierung.
Im Ruby-Umfeld dagegen herrscht eine andere Haltung: Der Code selbst soll so lesbar sein, dass er keine zusätzlichen Erklärungen braucht. Statt Kommentare zu schreiben, investiert man hier in Ausdruckskraft und Klarheit der Sprache.
Beide Ansätze haben ihre Berechtigung. Entscheidend ist nicht, welcher besser ist, sondern dass ein Team sich bewusst für einen Stil entscheidet, und diesen konsequent lebt. Dokumentation ist immer auch Kultur.
Dokumentation schafft Zusammenarbeit
Dokumentation ist mehr als ein Archiv. Sie ist ein Werkzeug für Zusammenarbeit. Neue Teammitglieder können schneller einsteigen, wenn sie eine klare Einführung finden. Diskussionen verlaufen effizienter, wenn Argumente und Entscheidungen bereits schriftlich vorliegen.
Und vor allem: Dokumentation schafft Vertrauen. Wer weiss, dass er jederzeit nachschauen kann, worauf eine Entscheidung basiert, arbeitet entspannter. Niemand muss im Dunkeln tappen oder hoffen, dass jemand anderes sich erinnert.
Dokumentation ist damit auch ein soziales Werkzeug. Sie verhindert Reibung und stärkt die Zusammenarbeit.
Dokumentation als Haltung
Am Ende geht es nicht um Tools, sondern um Haltung. Dokumentation zeigt Respekt. Respekt gegenüber Kollegen, die nach dir kommen. Respekt gegenüber dir selbst in sechs Monaten, wenn du vergessen hast, warum du eine bestimmte Abkürzung genommen hast.
Ich sehe Dokumentation als Akt der Verantwortung. Sie signalisiert: Mir ist wichtig, dass andere verstehen, was ich tue. Mir ist wichtig, dass meine Arbeit nachvollziehbar bleibt. Mir ist wichtig, dass das Projekt auch ohne mich funktioniert.
„Dokumentation ist kein Beiwerk, sie ist das geteilte Gedächtnis eines Teams.“
Dokumentation muss aktuell bleiben
Eine der grössten Herausforderungen bei Dokumentation ist nicht das Schreiben, sondern das Pflegen. Inhalte, die einmal erstellt und nie mehr aktualisiert werden, sind gefährlicher als gar keine Dokumentation. Sie geben ein trügerisches Gefühl von Sicherheit, obwohl sie längst nicht mehr stimmen.
Darum braucht Dokumentation Abläufe. Teams müssen vereinbaren, wie Inhalte regelmässig überprüft und angepasst werden. Ob in Retros, bei grösseren Releases oder durch automatisierte Erinnerungen, wichtig ist, dass klar ist: Dokumentation lebt.
Nur so bleibt sie verlässlich. Eine veraltete Notiz führt in die Irre, eine aktuelle Dokumentation gibt Orientierung.
Kollektives Gedächtnis
Dokumentation ist kein Anhängsel, sondern das kollektive Gedächtnis der Softwareentwicklung. Sie bewahrt Wissen, macht Teams stabiler und Zusammenarbeit einfacher.
- Ohne Dokumentation: Vergessen, Chaos, wiederkehrende Fehler.
- Mit Dokumentation: Klarheit, Stabilität, Gemeinsamkeit.
Und wie jedes Handwerk verlangt auch Dokumentation Übung. Sie ist eine Fähigkeit, die Teams bewusst entwickeln müssen. Wer sie pflegt, investiert nicht in Papierkram, sondern in Zukunftsfähigkeit.