Wir hatten also dieses neue Projekt, welches hunderttausende von Dateien verarbeiten musste. Das Problem war, dass wir nicht sicher sein konnten, wie schnell die Performance im laufenden Betrieb schlussendlich sein würde. Und in den Testumgebungen hatten wir nicht genügend Testdaten, um die Auslastung im Produktionsumfeld auch nur annähernd zu erreichen.

Das war damals eine Java Spring JMS Webapplikation. Wie es zu deren Natur gehört, hatten wir eine Konfigurationsdatei, in der wir etliche Parameter (Anzahl Threads etc.) einstellen konnten.

Nun waren wir aber alles andere als „Agile“ aufgestellt. Wir hatten jeweils nur wenige Releases pro Jahr. Natürlich gab es einen Prozess für ausserordentliche Lieferungen: Wenn es irgendwo brannte, musste man schnell reagieren und eventuelle Bugs beseitigen. Diese Prozesse gingen aber relativ lange und brauchten immer eine Unmenge von administrativem Aufwand. Und wenn man etwas liefern/beheben wollte, war das meistens ein recht negatives Erlebis. Man musste sich quasi das Recht erkämpfen, doch bitte die Software korrigieren zu können, damit der Kunde die Applikation funktionsgerecht verwenden konnte.

Verstehen Sie mich nicht falsch. Natürlich muss man mit allen Mitteln (Unittests, automatisierten Integrationstests etc.) verhindern, dass eine solche Situation entsteht. Doch eine solche Abneigung gegenüber Veränderung empfand ich als sehr lästig. Und heutige Informatiksysteme sind so gross, komplex und unüberschaubar geworden und miteinander verwoben, dass es durchaus Folgereaktionen geben kann, die man so nicht erwartet hätte. Nur schon die Vorstellung, man könnte alle Folgereaktionen und Abhängigkeiten einer Einlieferung wissen, ist absurd.

Wir wollten also Fehler beheben. Wir wollten auch eine möglichst gute Performance hinkriegen. Doch in der Realität haben wir die Parameter der Konfigurationsdatei initial bestimmt, so gut wir diese verstanden haben, und nachfolgend nur noch einmal angepasst. Wenn man jedesmal einen Marathon laufen muss, um einen Wert in einer Datei zu ändern, lässt man es irgendwann sein und hofft, dass doch alles noch gut kommt.

Ich hätte mir gewünscht, dass wir die Parameter öfters hätten ändern können – Und zwar in kleinen Schritten, um zu verstehen, welche Parameter wirklich etwas an der Performance verändern und das System beschleunigen oder verlangsamen. Aber was wir uns auch überlegten, jeder Schritt endete in einem administrativen Prozess, bei denen wir höchstens zwischen „mühsam“ und „einigermassen erträglich“ haben wählen können.

Wenn ich dann höre, dass in „fully agile Projekten“ eine unkomplizierte Anpassung der Produktion jeden Tag möglich ist, werde ich schon ein wenig neidisch. Ob es in der Realität in agilen Projekten wirklich so unkompliziert vonstatten geht?