Dokumentation – ein gern vermiedenes Thema unter Software-Entwicklern, denen natürliche Sprache berufsbedingt nicht immer formell genug ist – „Wenn du wissen willst, wie es funktioniert, schau halt in den Code“. Theoretisch vielleicht richtig, denn wie die Anwendung funktioniert, ist dort eindeutig nachvollziehbar. Trotzdem nicht ausreichend, denn die Intention dahinter, die zugrundeliegenden Entscheidungen und eventuelle Implikationen oder verworfene Alternativen findet man dort nicht.

Wenn man überlegt, wie Software-Dokumentation im Alltag üblicherweise entsteht, kann man durchaus nachvollziehen, warum mancher Entwickler sie eher dünn hält. (Dabei sollte erwähnt sein, dass ich in hier von einem im weitesten Sinne agilen Entwicklungsprozess ausgehe – eine umfangreiche Vorab-Dokumentation, vom Elfenbeinturm aus diktiert und in Steintafeln festgehalten wäre nichts, worüber ich hier schreiben wollen würde.) Wenn ich nun also als agil arbeitender Entwickler ein neues Feature gebaut habe oder ein größeres Refactoring durchgeführt habe, stelle ich mir die Frage: „Sollte ich diese Änderung dokumentieren?“.