arrow arrow--cut calendar callback check chevron chevron--large cross cross--large download filter kununu linkedin magnifier mail marker media-audio media-blog media-video menu minus Flieger phone play plus quote share youtube

Finde die Dokumentation!

„Der Designer verweist auf Confluence, der Entwickler auf den Code.“

Anfang des Monats startet man in ein neues agiles Kundenprojekt. Der Sprint läuft an, die Tasks sind vorbereitet, Zeit loszulegen.

Ich schnappe mir einen fachlichen Task: Eine Schnittstelle soll überarbeitet werden. Klingt spannend, ein guter Einstieg ins Projekt, denke ich.

Foto von Mustafa Cakar
Mustafa Cakar

Software Developer

Das Projekt selbst ist zentral und läuft schon seit Jahren. Man erkennt schnell: Es begann einmal als saubere Microservice-Architektur und ist mittlerweile in eine Sammlung aus Monolith-Modulen übergegangen. Die Spuren der ursprünglichen Pfade sind längst verloren.

Im Ticket steht nicht viel. Also spreche ich mit dem Designer, um herauszufinden, was genau gemeint ist. Wahrscheinlich wüsste der Kollege, der gerade im Urlaub ist, sofort, worum es geht, aber das ist ja das Ideal des agilen Arbeitens: Jeder soll theoretisch jede Aufgabe übernehmen können, besonders neue Teammitglieder.

Also frage ich nach: „Gibt es dazu eine fachliche oder architektonische Dokumentation?“

Ich ernte verwunderte Blicke und den Hinweis: „Das steht alles in Confluence.“

Confluence: Dieser sagenumwobene Ort, an dem Informationen wild wachsen, und wo die Suche natürlich immer das findet, was man nicht braucht. Nach dem ersten Blick auf die verlinkten Seiten merke ich: Entweder sind sie veraltet oder auf einer so hohen fachlichen Ebene geschrieben, dass sie mir für den Task nicht wirklich helfen.

Sackgasse.

Ich frage einen Entwickler weiter: „Gibt’s vielleicht irgendwo eine aktuelle technische Beschreibung?“

Die Antwort kommt prompt und klassisch:
„Der Code ist die Dokumentation.“

Warum ist das eigentlich so?

Jedes Projekt beginnt mit den besten Vorsätzen: „Wir dokumentieren alles sauber!“ Und am Anfang klappt das sogar. Neue Architekturdiagramme, ein sauberer Confluence-Bereich, vielleicht sogar ein README, das wirklich hilfreich ist.

Doch dann kommt die Realität:

Deadlines rücken näher.

Anforderungen ändern sich.

Neue Features müssen schnell umgesetzt werden.

Und die Doku? Die wird später aktualisiert.

Spoiler: Später kommt nie.

Außerdem sind viele Entwickler*innen überzeugt, dass der Code ohnehin die Wahrheit enthält. Das stimmt sogar, aber nur, wenn man bereits alles über das System weiß. Für Neulinge, Fachabteilungen oder externe Teams ist das, als würde man ein Buch lesen, bei dem das Inhaltsverzeichnis fehlt und die Seiten in zufälliger Reihenfolge angeordnet sind.

Ein Vergleich: Wenn IT-Projekte wie Häuser gebaut würden

Stellen wir uns vor, wir kaufen ein Grundstück und möchten ein Haus bauen. Wir finden einen Bauträger, endlich kann das Projekt starten. Gesamtbudget: 600.000 €. Davon sind 300.000 € schon für das Grundstück weg, der Rest muss für das Haus reichen.

Die Stakeholder sind klar: Wir als Bauherr*in, der Bauträger mit Architekt*in, Statiker*in, Handwerker*innen und natürlich die zuständigen Behörden.

Der/die Architekt*in nimmt unsere Anforderungen auf und erstellt eine erste Entwurfsskizze, eine Art Proof of Concept. Wir schauen sie uns an, bringen ein paar Änderungswünsche ein, und dann geht’s los.

Ab jetzt wird dokumentiert, und zwar alles:

Architekturpläne

Statikberechnungen

Wärmeschutzkonzepte

Materialbeschreibungen

Pläne für Elektrik, Wasser, Heizung usw.

Diese Dokumentation dient nicht nur uns, sondern auch den Behörden. Sie ist die Grundlage für die Baugenehmigung. Ohne sie läuft gar nichts. Die Genehmigung kommt, und der Bau beginnt. Hurra!

Doch wie das so ist, kommen während des Bauprozesses Änderungen: Die Küche soll doch anders geschnitten werden. Eine Steckdose muss versetzt werden. Ein Schrank passt nicht wie geplant. Jede dieser Änderungen wird nachgezogen, dokumentiert und abgestimmt. Manche Dokumente müssen erneut bei Behörden eingereicht werden.

Nach acht Monaten ist es geschafft: Das Haus steht, und wir können einziehen. 

Am Ende liegen mehrere volle Ordner mit Plänen, Berechnungen und Beschreibungen auf dem Tisch – eine vollständige Dokumentation des finalen Zustands.

Und jetzt die entscheidende Frage: Wenn bei einem Haus für 600.000 € alle Beteiligten und Behörden auf eine vollständige Dokumentation bestehen, warum ist das bei IT-Projekten, die mehrere Millionen kosten, oft nicht der Fall? Warum finden wir dort keine aktuelle, nachvollziehbare und vollständige Dokumentation?

Fazit

Dokumentation ist wie Aufräumen: Niemand hat Lust drauf, aber alle freuen sich, wenn’s gemacht ist.

Der Satz „Der Code ist die Dokumentation“ klingt cool, bis man den Code das erste Mal wirklich verstehen muss.

Gute Doku ist kein Luxus, sondern ein Beschleuniger. Sie spart Diskussionen, verhindert Missverständnisse und hilft neuen Leuten, schnell produktiv zu werden.

Und wer weiß, vielleicht ist ja das nächste Mal, wenn jemand fragt „Wo finde ich die Dokumentation?“, die Antwort: „Frag mal den, der im Urlaub ist.“

Last but not least: Finde die Dokumentation. Sie ist der Schlüssel zu Effizienz und Erfolg!