Reif für die Hängematte

Letzte Woche sagte jemand in einem Gespräch ganz beiläufig zu mir, dass beim Programmieren nur 20% der Zeit auf das Tippen des tatsächlichen Quelltextes entfallen - den Rest verbrächte man mit Nachdenken. Die Aussage fand ich bemerkenswert, weil sie in meinen Augen zum einen sehr knapp eine der Hauptanforderungen an gute Softwareentwicklung ausdrückte, zum anderen aber die Andeutung einer besorgniserregenden Entwicklung gerade im agilen Umfeld mitschwang: eine dominanter werdende Subkultur des Zusammenhackens.

Die Problematik an sich ist nicht neu, und nicht selten beruht sie schlicht auf einem oder mehreren gravierenden Missverständnissen der agilen Prinzipien. Die geringere Gewichtung von Prozessen, Dokumentation und langfristiger Planung im Manifesto wird nur allzu häufig als Rechtfertigung verstanden, alle Probleme mit einem Kopfsprung in den Quelltext anzugehen. Hinzu kommen natürlich ständig neue Überlegungen, Trends und Konzepte, die Entwickler scheinbar in solchen Vorgehensweisen bekräftigen. Ein Beispiel: Letztes Jahr etwa wurde ausgiebig über "Emergent Architecture" diskutiert, bei der Architektur aus konsequenter und kontinuierlicher Anwendung von Designprinzipien und Refactoring ganz automatisch entstehen soll. Die an sich hervorragenden Überlegungen in solchen Konzepten werden leider häufig schlicht missverstanden oder falsch transportiert, und nicht zuletzt auch oft unbewusst zur eigenen Bestätigung einseitig interpretiert. In der Konsequenz wird schließlich Ad-hoc-Tastenklappern in voller Überzeugung als Vorteil betrachtet, weil man scheinbar schnell auf alle geänderten Anforderungen reagieren kann und unglaublich fix Ergebnisse liefert. Tatsächlich habe ich aber in all den Jahren nicht ein einziges Projekt gesehen, auch nicht solche mit den besten Entwicklern und Architekten, in denen diese Vorgehensweise langfristig zum Erfolg geführt hätte.

Agile Entwicklung entbindet nicht von Analyse und Design.

What? Wer heutzutage Worte wie "Analyse" und "Design" in Gegenwart agiler Teams erwähnt, muss fast schon damit rechnen, spontan am nächsten Deckenbalken aufgeknüpft zu werden. Die Begrifflichkeiten sind einfach zu sehr vorbelastet durch die schwergewichtigen, problembehafteten Prozesse, die man aus dem klassischen Projektmanagement kennt. Aus diesem Grund versuchen bekannte Größen der Szene stattdessen, neue und unbelastete Begriffe zu finden, oder sie ziehen sich auf Botschaften zurück, die extrem einfach zu transportieren sind. Im Kern der Sache aber wollen alle auf dasselbe hinaus: Entwickler zum Nachdenken bewegen. Bob Martin etwa könnte es in seinem Artikel "When should you think?" nicht deutlicher und einfacher ausdrücken:

Think before you code. Then think as you code. Then think after you code.

Am anderen Ende der Skala finden sich Überlegungen von Menschen wie Rich Hickey, dem Erfinder von Clojure, der für seine Botschaft sogar einen eigenen Begriff geprägt hat: "Hammock-driven development", zu deutsch etwa: "hängemattengetriebene Entwicklung". Sein inzwischen legendärer Vortrag ist zwar unter dem Original-Link nicht mehr verfügbar, aber beispielsweise noch auf YouTube eingestellt. Gleich zu Beginn fragt er provokant, wann man als Entwickler denn das letzte Mal eine Stunde lang nur über etwas nachgedacht habe. Wann zuletzt einen ganzen Tag? Wann einen Monat, oder ein Jahr? Schließlich entwickelt er eine Methode, die sich zunächst darauf konzentriert, ein Problem zu formulieren(!), zu verstehen und zu analysieren, um schließlich darüber nachdenken zu können, bis man in einem ggfs. auch lange andauernden "Inspirationsprozess" (hier kommt die Hängematte ins Spiel) zu potenziellen Lösungen gelangt, die es gegeneinander abzuwägen gilt.

Letzteres ist sicherlich das Extrembeispiel und ein Luxus, den sich kaum jemand leisten kann. Ein Jahr lang über ein Problem nachdenken? Das wird im täglichen Trott für die allermeisten eher Wunschdenken bleiben. Es geht aber um den Kern der Sache: dass Nachdenken wichtig ist, um im Rahmen seiner Möglichkeiten zur wirklich bestmöglichen Lösung eines Problems zu gelangen. Es geht darum, das Ziel nicht aus den Augen zu verlieren und verlockend aussehende, täuschende "lokale Maxima" zu vermeiden. Die Idee ist, durch das Verständnis der Umstände und die Bewertung möglicher Lösungswege die optimale Herangehensweise zu finden, die dann durchaus auch mit Kompromissen behaftet sein kann. Um es kurz zu machen: es geht um Analyse und Design.

Wer mich mal dabei beobachtet hat, wie ich Software entwickle, konnte sicher schon ein etwas seltsames Verhalten beobachten: von Zeit zu Zeit scheine ich minutenlang die Struktur der Rauhfasertapete an der Wand gegenüber zu studieren, oder ich wandere abwesend durch die Flure und sehe mir ausführlich das höchst interessante Fussel-Muster des Industrieteppichs an. Das ist meine Hängematte. Es mag seltsam klingen, aber überspitzt ausgedrückt habe ich einem Meter Rauhfasertapete mehr gute Ideen zu verdanken als den meisten Büchern und StackOverflow zusammen.

Was ist deine Hängematte?