Risiken und Nebenwirkungen von Wiederverwendung

24.01.2010 Permalink

Die Situation kommt sicherlich häufiger vor: Ein Softwareprojekt übergibt erfolgreich seine erste Version an den Betrieb, und es dauert nicht lange, da steht bereits das nächste fachlich und technisch ähnliche Projekt vor der Tür. Im letzten Projekt hatte man sich einige Mühe gegeben, eine saubere Infrastruktur bestehend aus Entwicklungsumgebung, Buildverfahren, Generatoren, Laufzeitprodukten, Bibliotheken und kodierten querschnittlichen Lösungen zu etablieren. Und was liegt näher als diese Infrastruktur gleich weiter zu verwenden?

Für die Widerverwendung gibt es jetzt zwei Wege. Man kann a) alle Projekte dieselbe Infrastruktur gleichzeitig nutzen lassen, oder b) man erschafft einen dauerhaften Branch, den man dann den Wünschen des neuen Projekts ohne sonderliche Rücksicht anpasst.

Der Reflex des guten Softwareingenieurs ist klar: Keine Duplikation, um keinen Preis! Das würde zu Mehrfachpflege führen, oder schlimmer noch: man lässt zeitweise die Divergenz zu und muss sich dann wieder mit der Konsolidierung mühen. Dieser Reflex ist gesund, aber man sollte eine bewusste Entscheidung treffen, ob man eine gemeinsame Infrastruktur oder verschiedene ähnliche haben möchte, denn die technischen und organisatorischen Konsequenzen, die dem Nachgeben des Reflexes folgen, können teurer und unerfreulicher sein als das divergierende Nebeneinander. Letztlich ist hier eine Entscheidung mit strategischem Weitblick und langfristiger Kosten-Nutzen-Betrachtung nötig.

Konsequenzen bei Zusammenhalten:

Fachprojekte müssen sich bewusst für Releases der Infrastruktur entscheiden und sind dann von dieser abhängig.
Änderungen an der Infrastruktur können nicht mehr ad-hoc aus Projektsicht durchgeführt werden, sondern müssen durch einen Change Prozess. Teilnehmer des Entscheider-Boards sind Experten der Infrastruktur und je ein Vertreter der Fachprojekte.
Dementsprechend müssen beschlossene Änderungen in Releases gebündelt werden, was die Beweglichkeit stark einschränkt.
Durch z.T. widersprüchliche Anforderungen an Features wird die Infrastruktur weit generischer und damit wahrscheinlich schwerer zu verstehen und schwerer zu ändern.
Es muss eine explizite Qualitätssicherung der Infrastruktur geben.
Die Kosten der Pflege und Weiterentwicklung müssen getragen werden. Beteiligen sich Projekte anteilig? Oder gibt es ein fixes Budget der Kostenstelle? Gibt es eine eigene Organisationseinheit, in der die Pflege und Weiterentwicklung gebündelt wird?

Konsequenzen bei Nichtzusammenhalten:

Neue Features und Bugfixes, die für n Fachprojekte relevant sind, müssen n-mal nachgepflegt werden. Der Aufwand steigt linear mit der Anzahl der parallelen Infrastrukturen.
Die Informationen, was sich in welchem Branch geändert hat, müssen verfolgt werden. Projekte müssen sich entscheiden, was sie übernehmen wollen und das jeweils selbst organisieren.
Es kann zu inkonsistenten Weiterentwicklungen kommen, die dauerhaft verschiedenes Verhalten bedeuten. Das verteuert möglicherweise die Einarbeitung von Mitarbeitern, die zwischen Projekten mit ähnlichen, aber nicht gleichen Infrastrukturen wechseln sollen.

Die Frage ist letztlich: wieviele technisch ähnliche neue Projekte wird die Organisation in Zukunft haben, die den weitgehend unveränderten Einsatz dieser Infrastruktur erfordern?

Wenn die Antwort ist: ja, noch einige, dann sollte man über eine gemeinsame Infrastruktur nachdenken.
Wenn die Antwort ist: nicht viele oder nur mit stärkeren Abweichungen untereinander, dann würde ich die Finger davon lassen und die projektweise Weiterentwicklung nebst informellem Austausch vorziehen.