Gesehen: der Vortrag von der RubyConf.au „A Branch in Time – a story about revision histories“ von Tekon Süleyman.
Auf der Basis einer fiktiven Geschichte einer Entwicklerin, verdeutlicht Süleyman, welche zentrale Rolle Git in Projekten einnimmt – nicht nur als bloßes Source-Verwaltungs-Werkzeug, sondern idealerweise als Dokumentation, warum bestimmte Dinge im Code so umgesetzt worden sind, wie sie umgesetzt wurden. Das ist eine weitaus weniger banale Frage, als es sich für Außenstehende anhört.
Süleyman dockt seine Geschichte und Vorschläge an ein Thesenpapier von Peter Naur an: „Programming as Theory Building“ (PDF).
Programmieren ist demnach nicht die Produktion von Code, sondern der Aufbau einer Theorie oder eines Gedankenmodells, wie die Software zu arbeiten hat. Code ist demnach nur ein Artefakt/Ausdruck dieser Denkprozesse.
Software-Projekte werden fast nur noch iterativ (in kleinen Schritten) entwickelt. Schritt für Schritt wird innerhalb des Teams das oder die Gedanken-Modelle entwickelt. Aber es gibt keine Prozesse und kein Format, um die entwickelten Modelle expressis verbis niederzuschreiben und dann weiter zu entwickeln. Stattdessen handelt es sich um „institutional knowledge“, also eine Art kollektives Wissen, dass sich entwickelt.
An dieser Stelle ist Code der Ausdruck für eine konkrete Umsetzung: “was ist wie umgesetzt worden”. Git kann und sollte an dieser Stelle die Rolle spielen, die Motivation und Abwägungen, also das „warum ist es so umgesetzt worden“, zu dokumentieren. Für Git Commits gilt daher der Leitsatz: „Capture the why, not the what“.
Naur geht in seinem Papier so weit, und spricht von einem Sterben der Software, wenn das Entwicklungsteam aufgelöst wird. Mit dem Verschwinden des kollektiven Wissens, schwindet auch die Wartbarkeit der Software.
IMHO setzt der Zerfall von Software schon sehr viel früher ein: wenn unter Zeitdruck und/oder Komfort Abkürzungen genommen werden. Das Wissen wird statt eines „nachschlagbaren“ (dokumentierten) Kollektiv-Wissens, zu einem individuellen Wissen, zu einem Herrschafts-Wissen.
Es fängt mit Petitessen an. Aber wenn der Damm löchrig ist, ist der Dammbruch nicht weit.
Code-Reviews können nicht mehr sauber geführt werden, weil der zu prüfende „Soll-Zustand“ für den Reviewer nicht mehr nachzuvollziehen ist. Die Code-Review verkommt zu einem menschlichen Linting-Prozess.
Es schleichen sich immer stärkere Inkonsistenzen ins Projekt rein, weil es keine eindeutige Referenz mehr gibt, sondern mehrere entstanden sind. Es gibt mangels eindeutiger Referenz keinen Konsens mehr, was richtig oder falsch ist, sondern nur noch mehr oder weniger kompetente Interpretationen.
Das Entwicklungstempo wird abnehmen. Entwickler, die einen anderen Teilausschnitt des „kollektiven Wissens“ haben, werden den Code falsch interpretieren oder andere Rahmenbedingungen bzw. Maßstäbe anlegen und Probleme mit dem Bestandscode bekommen.
Ich weiß nicht, wie dieser Kreislauf rückgängig zu machen ist.