Wie wahrscheinlich die meisten von Euch sind auch wir hauptsächlich in Projekten unterwegs, in denen die Entwicklung agil organisiert ist. Das finden wir grundsätzlich erstmal gut, denn viele der Werte und Ansätze agiler Entwicklung (und solche in deren Dunstkreis) halten wir für äußerst sinnvoll: das Arbeiten in kurzen Iterationen, das kontinuierliche Liefern von Geschäftswert, die enge Zusammenarbeit mit Kund:innen und Nutzer:innen, Pair Programming, Fokus auf Testen, flexibles Reagieren auf Änderungen, etc., etc.

Was wir dabei nicht so gut finden (und das ist noch zurückhaltend formuliert), ist eine gewisse Skepsis gegenüber Architekturkonzepten und die Zurückhaltung, Aufwand in deren detaillierte Ausarbeitung zu investieren, die wir dabei immer wieder wahrnehmen. Und das führt in vielen Fällen zu großen Problemen, vor allem in größeren Projekten. Insbesondere weil man sich gerne auf „Entscheidungen im letzten vernünftigen Moment“ verlässt, hat man eine perfekte Begründung, um Konzepte und Entscheidungen erst mal nicht zu bearbeiten, sondern offen zu lassen. Genau darum geht es in diesem Artikel.

”Konzeption ist überbewertet”

Um das genauer einzuordnen: Im Kontext agiler Entwicklungsansätze wird die Entwicklung besonders generischer Lösungen eher kritisch gesehen, weil die Erfahrung zeigt, dass man die damit erreichte Flexibilität häufig gar nicht benötigt und sich der dafür notwendige Mehraufwand häufig nicht rechnet. Das Akronym „YAGNI“ steht für „You ain’t gonna need it“ und steht genau für diesen Grundgedanken. Und obwohl diese Idee als grundsätzliche Leitlinie in der Entwicklung natürlich überaus sinnvoll ist, gibt es häufig die Überinterpretation: „Lieber nicht so viel Nachdenken, wer weiß, ob sich das hintenraus lohnt.“ Das ist wenig hilfreich bis maximal schädlich. Besonders kontraproduktiv ist diese Haltung, wenn in der unmittelbaren Aufgabenstellung schon erkennbar ist, dass ein wiederholtes Problem zu lösen ist, für das sich eine einheitliche Lösung förmlich aufdrängt und aber trotzdem nicht die elegante übergreifende Lösung gewählt wird, sondern jedes Vorkommen individuell gelöst wird. Und jetzt denkt Ihr sicher: In dem Fall ist ja klar, dass man hier eine etwas generischere Lösung für eine einheitliche Umsetzung wählen würde. Leider passiert sehr häufig das Gegenteil!

”Programmieren statt konzipieren”

Dieser Ansatz führt nicht selten zu folgendem Vorgehen: Ein rudimentär ausgestaltetes Konzept soll jetzt möglichst zügig umgesetzt werden. Wir müssen loslegen! In diesem Zuge entdecken wir einen Spezialfall, den wir nicht auf dem Zettel hatten. Deswegen müssen wir den Scope des Tasks nochmal etwas erweitern und das Konzept entsprechend umbauen. Kurz vor Ende entdecken wir, dass wir mit einer Entscheidung in eine Sackgasse gelaufen sind, deswegen müssen wir nochmal was ändern.  Wir ändern und erweitern das Konzept und gehen dann im nächsten Sprint nochmal an die Umsetzung. Eineinhalb Monate später rutscht dann noch eine Anforderung in den Scope, die wir ehrlicherweise schon die ganze Zeit kannten aber mal noch zurückgestellt hatten, weswegen wir nochmal einen großen Umbau starten müssen. Etc.

So ersetzen wir quasi zwei Tage Nachdenken durch drei Sprints Programmierung. Das ist jetzt zugegebenermaßen etwas überspitzt dargestellt; aber nicht viel. So vorzugehen ist vor allem aus ökonomischen Aspekten extrem ungünstig:

Programmieren ist die teuerste aller Möglichkeiten, um herauszufinden, ob ein Konzept tragfähig ist und wie dessen beste Ausgestaltung aussieht. Programmieren ist natürlich schön, weil es uns hilft, die Dinge konkret zu machen, weil wir viel dabei lernen und direktes Feedback bekommen. Aber um ein Konzept umzusetzen, sind nicht selten mehrere Personen Stunden, Tage und manchmal sogar Monate beschäftigt, um den Code für Logik, Test und Infrastruktur zu schreiben. Das macht Änderungen von zentralen Entscheidungen extrem teuer. Solche Änderungen auf Ebene der Konzeption vorzunehmen ist viel günstiger, weil man viel weniger hat, das geändert werden muss, nämlich eigentlich nur das mentale Modell und die Dokumentation. Ein gut durchdachtes Konzept zu entwickeln, und dabei Beispiele zu machen, zu experimentieren und Ergebnisse mit anderen zu diskutieren, etc. sind Alternativen, die viel weniger risikobehaftet und gleichzeitig billiger umzusetzen sind.

Refactoring als vermeintlicher Rettungsanker

Agile Entwicklungsansätze betonen häufig die Bedeutung von Refactoring, um die Umsetzungsqualität zu verbessern und um auf Änderungen reagieren zu können. Dies wird dann im beschriebenen Kontext gerne umgedeutet zu: „Wir müssen jetzt nicht so viel durchdenken, wir können ja später alles durch Refactoring wieder ändern.“  So sind wir aber in keinem der beiden genannten Fälle (Qualitätsverbesserung, Reaktion auf Änderungen) unterwegs. Natürlich können wir alles, auch zentrale Entscheidungen später wieder umbauen, dann aber nur zu substanziellen Kosten. Ökonomisch ist das äußerst fragwürdig, insbesondere weil wir diese Mehrkosten auch leicht durch mehr Nachdenken vermeiden können. Ganz häufig wird Agilität und die Möglichkeit zum Refactoring so zur Ausrede für mangelnde Konzeption oder zu viel Bequemlichkeit beim Nachdenken und manchmal leider auch zum Ausweg, wenn man es nicht so genau weiß. Außerdem sinkt auch mit der Menge des bereits investierten Aufwandes die Bereitschaft, fundamentale Aspekte zu ändern und birgt so die Gefahr, dass wir uns mit einer sehr suboptimalen Lösung dann doch langfristig zufrieden geben. Außerdem konkurriert Refactoring ja immer mit neuen Features und zieht dann gerne den Kürzeren.

Der ”letzte vernünftige Moment” …

Der Titel dieses Artikels lautet „Wie Agilität den letzten vernünftigen Moment verschleiert“. Der „letzte vernünftige Moment“ beschreibt eine Idee aus dem Bereich agiler Softwarearchitektur, die besagt, dass es vorteilhaft ist, schwierige Entscheidungen tendenziell eher länger offen zu lassen, weil man mit fortschreitender Zeit mehr über das System lernt und damit eine informiertere Entscheidung treffen kann. Man könnte meinen, da reichen sich doch Agilität und Softwarearchitektur die Hände, nicht so genau planen, alles möglichst lange offen lassen! Dann wäre man aber schief gewickelt, denn beim „letzten vernünftigen Moment“ liegt die Betonung nämlich auf „vernünftig“.

… wird gerne künstlich nach hinten geschoben …

Bei genauer Betrachtung stehen uns häufig viele Informationen schon früh zur Verfügung und viele Sachverhalte ändern sich über die Zeit nicht grundlegend. Die folgende Abbildung zeigt exemplarisch, dass für verschiedene Entscheidungen in einem System erst zu unterschiedlichen Zeitpunkten eine ausreichende Informationsmenge als solide Basis für die Entscheidung vorliegt. Wenn man diese Informationen grundsätzlich zur Verfügung hat, ist es nur wenig vernünftig, diese nicht auch ins Konzept einzubeziehen, nur weil man den Aufwand fürs detaillierte Nachdenken scheut. Damit kompromittiert man dann eine der wichtigsten Vorteile von Softwarearchitektur: Schon früh Voraussagen über die Erreichbarkeit von Anforderungen und Qualitätszielen machen zu können und damit Irrwege erkennen und Alternativen entwickeln zu können. Umgekehrt hat es zusätzlich erhebliche Vorteile Pflöcke einzurammen, weil man damit Leitlinien schafft und die Komplexität zur Entscheidungsfindung reduziert.

… und dann verpasst

Trügerischerweise klingt es einfach entscheidbar, wann dieser letzte vernünftige Moment ist: In der Praxis ist diese Entscheidung aber alles andere als einfach. Der Zeitpunkt geht gerne im Tagesgeschäft unter und schon ist es zu spät. Und wird dann „irgendwie“ umgesetzt, ohne vernünftige Entscheidung und ohne durchdachtes Konzept.

Die folgende Abbildung zeigt typische Extreme, die entstehen können in einem Projekt, je nachdem, wie das Treffen von Entscheidungen sich über die Projektlaufzeit verteilt. Verteufelt wird heute „Big Design Upfront“, das heißt das möglichst frühe Treffen nahezu aller zentralen Entscheidungen. Dieses Vorgehen hat sich als wenig zielführend herausgestellt, weil es das iterative Lernen in Projekten nicht genug einbezieht und zu früh viele Pflöcke einrammen möchte. Weit weniger in Verruf, aber nicht minder gefährlich ist das „Konzeptionelle Vakuum“. Dieses entsteht, wenn möglichst viele zentrale Entscheidungen in einem Entwicklungsprojekt möglichst lange offen gehalten werden sollen. Dann ist alles fluide und nichts greifbar. Wie immer liegt die Wahrheit in der Mitte, wo eine „ausgewogene Konzeption“ frühzeitig wichtige Eckpfeiler einrammt, aber trotzdem über die Projektlaufzeit offen bleibt für später zu treffende wichtige Entscheidungen.

Wie könnte es also klappen?

Abschließend, zur Klarstellung: wir haben absolut nichts gegen die Ideen und Ansätze agiler Entwicklung; im Gegenteil, wir sind überzeugt davon, dass Architekturarbeit und agile Entwicklung extrem gut Hand-in-Hand gehen. Dem Hang zu den beschriebenen Fehlinterpretationen vor dem Hintergrund agiler Entwicklung begegnen wir aber trotzdem immer wieder. Deswegen möchten wir an den gesunden Menschenverstand appellieren: Nutzt die Informationen, die Euch zur Verfügung stehen, entwerft gut durchdachte Konzepte, prüft und durchdenkt sie mit Euren Kolleg:innen und wenn Ihr Konfidenz aufgebaut habt, dass Ihr damit auf dem richtigen Weg seid, dann setzt Ihr sie zielstrebig um. Natürlich kein Over-Engineering und nichts zu-Tode-Analysieren. Aber immer mit dem sicheren Blick für die wesentlichen Aspekte eures Produkts, die möglichst klar und einfach gestaltet werden sollten. Damit seid Ihr schlussendlich auch um ein Vielfaches schneller.