Software-Entwicklung im digitalen Großraumbüro

Aus unserer Erfahrung wissen wir, dass Integration meistens mühevoll und komplex ist. Irgend etwas soll mit etwas anders Geartetem verbunden werden. Das klingt nach harter Arbeit und Reibereien. Man bewegt sich aus der Komfort-Zone.

Die vielleicht häufigsten Assoziationen kommen zu dem Thema “Integration von Ausländern” bzw. Integration in der IT. Bei beiden könnten man sich zunächst fragen: Warum kommt es überhaupt dazu, dass anders geartete Konstrukte/Charaktere entstehen? Die Beantwortung dieser Frage ist vermutlich irgendwo zwischen Evolutionsbiologie, Psychologie und Soziologie angesiedelt – sie würde aber jedenfalls den Rahmen dieses Blogs sprengen. Also nehmen wir es einfach als gegeben hin, dass sich Dinge von Natur aus auseinander entwickeln und dann zu bestimmten Zeitpunkten wieder integriert werden sollen.

In der IT kennen wir das insbesondere in zwei Phasen des Life-cycle:

• in der Software-Entwicklungs-Phase beim Zusammenführen von unterschiedlichen Entwicklungs-Ständen (“Merge”)
• in der Produktion, wenn Daten zwischen IT-Systemen ausgetauscht werden müssen (“System Integration”)

Bei beiden IT-Aktivitäten existiert die Tendenz, die Integration möglichst lange hinauszuzögern. Kein Software-Entwickler steht in der Früh auf und denkt sich: “Jetzt schnell einen Kaffee und dann freue ich mich schon darauf, meine neu gebaute Funktionalität endlich mit den Änderungen meiner Kollegen zu integrieren!” Und kein IT-Manager denkt mit einem wohligen Gefühl im Magen über zusätzliche Integrationen in das SAP-System nach. 

Kurzum: Integration passiert, wenn es denn unbedingt sein muss. 

Wenn wir besonderes Glück haben, müssen wir uns nicht einmal darum kümmern, sondern können das an andere Personen delegieren: 

• Beim “Merge” der Software-Entwicklung z.B. an dedizierte “Deployment-Manager”. Diese müssen sich dann mit so mühsamen Dingen wie “Integrations-Tests” herumschlagen und sich von jedem einzelnen Software-Entwicklern erklären lassen, dass das Problem sicherlich nicht von ihnen verursacht wurde.

• Bei der “System Integration” an eine eigene “Enterprise Application Integration” – Plattform bzw. an gut bezahlte externe Berater (“System Integratoren”). Die bringen zwar jeden Budgetverantwortlichen zum Weinen, aber was getan werden muss, muss getan werden. Wen stört es dann schon, dass zwischen zwei IT-Systemen – symbolisch gesprochen – von englisch auf serbisch auf suahelisch und schlussendlich auf italienisch übersetzt wird. Integration gelungen, Effizienz im Keller.   

Integration hat also in den meisten Fällen die Anziehungskraft einer Wurzelbehandlung. Wir zögern sie hinaus, soweit es nur geht. Wenn wir mit Ach-und-Weh beginnen, uns damit zu beschäftigen, bleibt aber nur mehr wenig Zeit im Projekt übrig. Klar, wer beschäftigt sich schon gerne frühzeitig mit einer Wurzelbehandlung?! Menschlich verständlich, aber für den Projekterfolg sicherlich nicht dienlich.

Wie so oft lassen sich chronische Ineffizienzen nur mit einem radikalen Gegenansatz adressieren. Und so hat auch die schöne, neue Software-Welt einen Ansatz eingeführt, der den Spieß umdreht. Continuous Integration propagiert – wie der Name sagt – eine permanente Integration, frei nach dem Motto “Wenn etwas weh tut, dann mach es häufig!” oder “Putze Dir die Zähne, dass es nie zu einer Wurzelbehandlung kommt!”

Für Continuous Integration gibt es verschiedenste Umsetzungen:

Der radikalste Ansatz um die Gegensätzlichkeit zu klassischen Entwicklungs-Flüssen zu veranschaulichen, ist “Trunk-based Development”. Alle Entwickler arbeiten an einem Hauptstrang (“Trunk”), sozusagen in einem “digitalen Großraumbüro”. Das isolierte Arbeiten (“Private Brunches”) ist maximal für kurze Zeiträume erlaubt , üblicherweise muss aber spätestens am Ende des Tages die Arbeit wieder in den Hauptstrang integriert werden. Das soll zu große Abweichungen verhindern und sicherstellen, dass es permanent lauffähige Software gibt. 

Der Effekt von Continuous Integration ist enorm. Es müssen plötzlich Regeln eingehalten werden, alle sitzen buchstäblich in einem Boot. Wenn einer sich daneben benimmt, dann werden alle gestört. Das verlangt Disziplin und ist für die gesamte IT-Mannschaft eine große Umstellung. Es wird natürlich immer Entwickler geben, die sich massiv beschweren. „So kann ich nicht arbeiten! Meine Produktivität wird dadurch eingeschränkt!“ Das mag sogar sein. Aber was ist am Ende des Tages wichtiger? Die individuelle oder die kollektive Produktivität?

Richtig umgesetzt, sind die Vorteile beträchtlich. Das Auseinander-Driften und die enormen Aufwände, um diverse Software-Stände wieder zusammen zu führen, werden weitgehend vermieden. Es führt zu einer Beschleunigung von Entwicklungsprozessen und – sozusagen als nette Nebenerscheinung – dazu, dass Entwickler-Teams enger zusammenrücken müssen. Team-Denken wird nicht nur gefordert, sondern ist im System eingebaut. Daher funktioniert Continuous Integration auch am besten mit agilen Entwicklungs-Methoden wie SCRUM. Denn auch bei SCRUM geht es um Team-Denken, permanent lauffähige Software und kurze Iterations-Zyklen.

Natürlich ist auch “Continuous Integration” nicht für alle Szenarien die perfekte Lösung. 

In dem ausgezeichneten Blog “Git Flow vs Trunk-based Develpment” stellt Konrad Gadzinowski sehr nüchtern die Vor- und Nachteile von Software-Entwicklung im digitalen Großraumbüro (“Trunk-based / Continous Integration”) versus Software-Entwicklung im Einzelzimmer (“Git Flow”) gegenüber.

Kurz zusammengefasst: Continuous Integration ist gut für eingespielte, homogene Teams geeignet, die schnell greifbare Ergebnisse erzielen wollen. Das ist insbesondere bei Prototyping bzw. unklaren, dynamischen Zielvorgaben der Fall. 

Bei allen anderen Szenarien ist eine initiale Separierung vermutlich das kleinere Übel. Man ist aber gut beraten, die Integration nicht zu lange rauszuzögern bzw. die Integrations-Aufwände nicht zu unterschätzen.

In der gesellschaftlichen Frage der Integration wird man vermutlich auf ähnliche Schlussfolgerungen kommen. Integration immer und sofort wird vermutlich nicht funktionieren bzw. viel kaputt machen. So macht es vermutlich Sinn, vor dem Wiener Fussball-Derby Austria gegen Rapid, die Fans der beiden Mannschaften temporär zu separieren. Wenn die Gemüter und der Alkoholspiegel wieder abgekühlt sind, ist an eine einigermassen friedliche Integratieren zu denken.

Bevölkerungsgruppen dauerhaft in Ghettos unter Verschluss zu halten, hat in der Menschheitsgeschichte immer für Unglück gesorgt und Generationen gebraucht, um all die entstandenen Vorurteile und Antipathien zu beseitigen. Die damit verbundenen Kollateralschäden sind enorm.

Neben der nüchternen Kosten-Nutzen-Rechnung, kann Integration auch Spaß machen und enorm bereichern. Sie erinnert uns, dass wir zumeist mehr gemeinsam haben, als uns trennt. Wenn diese Erkenntnis auch bei allen Mitgliedern der Projektteams durchgedrungen ist, dann werden die Ergebnisse insgesamt besser sein. Egal, ob man den Prozess Continuous Integration nennt oder nicht.