Hastige Dringlichkeit ist fast nie richtig

Ach ja, ich erinnere mich, warum Sie niemals Sprichwörter direkt von einer Sprache in eine andere übersetzen sollten. Diejenigen, die kein Niederländisch sprechen, müssen mir wohl glauben, dass "Haastige spoed is zelden goed" viel besser klingt. Die Bedeutung des Sprichworts ist natürlich ziemlich offensichtlich: "Überstürzen Sie nichts, es kommt meist zurück, um Sie zu verfolgen." Wir alle wissen das, und in der IT-Branche gilt es noch mehr, denn hier können kleine Fehler schlimme Folgen haben. Aber wir fallen allzu oft darauf herein, denn bei den komplexen Systemen von heute ist es schwer zu überblicken, was alles schief gehen kann. Und noch schwieriger ist es, abzuschätzen, was es Sie kosten wird, wenn etwas schief geht. Ich möchte Ihnen einen Fall schildern, in dem ich erkläre, was schief gelaufen ist, und versuche, einen Überblick darüber zu geben, was uns und unseren Kunden das gekostet hat. Um eine der von unserem Kunden gewünschten Funktionen bereitzustellen, musste ich ein sehr kleines Servlet unter einer anderen URL als der unserer normalen Anwendung ausführen. Es gab keine andere Möglichkeit, dies zu umgehen. Das Problem war, dass es viel Aufwand bedeutete, ein neues Modul in Subversion zu erstellen, ein Maven-Projekt einzurichten, eine separate Anwendung für nur 15 Zeilen Java-Code und 6 Zeilen JSP bereitzustellen und zu pflegen. Die "Lösung", die mir einfiel, bestand also darin, diese eine URL als Proxy zu verwenden und sie auf ein Servlet in unserer normalen Anwendungsdomäne umzuleiten. Das hat wirklich gut funktioniert. Die neue Funktionalität funktionierte und alles schien in Ordnung zu sein. Erst ein paar Tage später, etwa einen Tag vor dem Abgabetermin, stellten wir bei einem gründlichen Test fest, dass eine obskure Funktion, die wir in den letzten 4 Wochen nicht einmal angefasst hatten, nicht mehr funktionierte. Wir waren einen Tag lang völlig verblüfft, bis ich schließlich erkannte, was das Problem war. Für den Browser war die externe URL nicht Teil der Anwendung, so dass er seine Sitzungscookies nicht mit der Anfrage sendete. Das Servlet befand sich jedoch in der Anwendungsdomäne und kam daher zu dem Schluss, dass keine Sitzung vorhanden war, woraufhin es sofort eine neue Sitzung startete und den gesamten Status der vorherigen Sitzung entfernte. Alle Funktionen, die auf die Sitzung angewiesen waren, schlugen also fehl. Man kann natürlich argumentieren, dass unsere automatischen Tests nicht ausreichend waren. Das ist eine stichhaltige Beobachtung, aber es handelt sich hier um eine vererbte, schlecht geschriebene JSF-Anwendung, die sich nur sehr schwer automatisch testen lässt, und es gab kein Budget, um im Vorfeld umfassende Tests durchzuführen. Eine lausige Ausrede, ich weiß. Das war also der Fall einer Abkürzung, die ich für machbar hielt, die sich aber letztendlich als falsch erwies. Ich habe versucht, vielleicht einen halben Tag Entwicklungszeit und vielleicht einen weiteren Tag oder so an Zeit für die Bereitstellung und Dokumentation zu sparen. Das Endergebnis ist, dass es mehr als zwei zusätzliche Tage an verschwendeter Entwicklungs- und Fehlersuchzeit gekostet hat. Das sind mehr als 2000 Euro für unseren Kunden, 2 Tage weniger Entwicklungszeit für andere Funktionen, ein Reputationsverlust für mein Team und mein Unternehmen und noch einige andere Probleme, die dafür sorgten, dass wir unser Zeitfenster für den vorzeitigen Produktionsstart nicht einhalten konnten und diesen um eine weitere Woche verschieben mussten. Das alles hat mich daran erinnert, dass es immer wichtig ist, eine angemessene Risikobewertung vorzunehmen, wenn man diese Abkürzungen nimmt. Das habe ich versäumt, als ich die Entscheidung traf, weil ich unter Druck stand, die Dinge schnell zu erledigen. Diese Lektion habe ich gut gelernt - wieder einmal. Hoffen wir, dass dieser Beitrag die Leute daran erinnert, wenn sie das nächste Mal in einer solchen Lage sind... Ich weiß, dass ich es zumindest für eine Weile nicht vergessen werde :)