Bauen versus Basteln

Vorsicht: Nestbeschmutzung

Tut mir ja wirklich leid, aber ich möchte an dieser Stelle mal ein wenig IT-Bashing betreiben - und mich über die teilweise grotesken Zustände der Softwareentwicklung beklagen.

TL;DR (aka Zusammenfassung)

Wir basteln oft, statt (systematisch) zu bauen. Das liegt manchmal weniger an uns Techies (Entwicklern, Architekten etc), sondern an negativen Wechselwirkungen vieler Parameter, die häufig miserabel gemanaged werden - und auf Dauer dann zu unwartbaren, unflexiblen und unverhältnismäßig teuren IT-Landschaften führen. Ziemlich drastisch hat das renommierte "Handelsblatt" es zuletzt unter dem Titel "Ramponierte IT" auf den Punkt gebracht:

"Die schlechten Computersysteme werden für viele Effizienzprobleme verantwortlich gemacht" (Handelsblatt)

Software "entwickeln" klingt systematisch...

Wir sagen fast alle "Softwareentwicklung" zu unseren Jobs - das klingt systematisch, fast so wie "Engineering". Wir erfreuen uns an Entwurfsprinzipien, verwenden etablierte Architekturmuster und arbeiten iterativ-agil. Stets streben wir nach Innovation und Verbesserung, und dauernd kommunizieren uns Blogs, Zeitschriften und Konferenzredner coole "Success Stories": Systeme in denen (scheinbar) alles richtig entschieden und ordentlich implementiert wurde.

"basteln" trifft es oft besser

In Wirklichkeit hat das so genannte "Entwickeln" von Software meiner Erfahrung nach in vielen Fällen deutlich mehr mit "Basteln" als mit systematischem Vorgehen zu tun. Die oben genannten "Erfolgsgeschichten" passieren oftmals "woanders", in ganz speziellen Situationen oder halten einer näheren Überprüfung nicht stand. Viele unserer mittleren bis großen Systeme sind "hysterisch gewachsen", man könnte auch "gewuchert" dazu sagen. Viele meiner aktuellen und ehemaligen KollegInnen können in ihren eigenen Systemen mehr Antipatterns aufzeigen, als Stellen, auf die Teams auch nach längerer Zeit noch stolz sind. Diese Probleme treten völlig unabhängig von (oder sogar trotz der...) so genannten Vorgehens- oder Reifegradmodellen auf.

Same Stupid Mistakes

Dabei wissen wir (SoftwerkerInnen) doch ziemlich genau, welche typischen Fehler auf lange Sicht zu übermässig komplexen Systemen führen - die wir im Team nicht mehr effizient weiter bearbeiten können... Aus meiner Sicht sind dabei folgende Themen besonders schlimm:

• Mangelhafte Anforderungen: Garbage in, garbage out. Wenn uns Product-Owner oder Fachbereiche unscharfe oder schwammige Anforderungen geben, werden wir möglicherweise stark konfigurierbare Systeme liefern, damit alle möglichen Interpretationen dieser Anforderungen noch erfüllbar sind. Uns allen ist aber klar, dass Konfigurierbarkeit mit hoher Komplexität einhergeht - und zu mehr Code führt, als wenn wir stärker abgrenzen und uns in Systemen stärker fokussieren.
• Unklare Qualitätsanforderungen:Teams haben immer "implizite" Vorstellungen, welche Qualitätsanforderungen ein System denn erfüllen müsste. Leider unterscheiden sich diese impliziten Annahmen manchmal gravierend von denen der Fachabteilungen, Auftraggeber oder sonstigen Systemverantwortlichen.
• Arbeit unter Zeitdruck: Es gibt im Durchschnitt immer mehr Arbeit als Zeit dafür. Daher gehen wir während der Arbeit an Systemen lauter kleine Kompromisse ein, die einzeln kaum auffallen, in ihrer Summe dann aber zu fatalen Mängeln der inneren Qualität führen - ein anderer Begriff dafür sind "technische Schulden".
• Kein Abbau technischer Schulden: Zu viele Abhängigkeiten, schlechte Modularisierung, geringe Konsistenz, übertriebene Inhomogenität, Nutzung veralteter Frameworks oder Technologie, unzureichende automatische Tests (um nur einige aufzuzählen) - das könnten wir ja alles bereinigen oder zumindest drastisch verbessern - sofern wir dafür etwas Zeit zugestanden bekämen. Aber: Der Abbau dieser technischen Schulden hat für unser Management kaum Priorität, ist mancherorts sogar als "nutzlose Zeitverschwendung" verschrien, die, so wörtlich, "ja keine neuen Features liefere".
• Mangelhafte Entwicklungsprozesse: Auch heute, im Jahre 2016, weigern sich Organisationen noch beharrlich, auf flexiblere und schnellere Entwicklungsprozesse zu setzen. DevOps und Continous-Integration werden als "funktioniert hier sowieso nicht" abgetan. Klar, das funktioniert ja wirklich nur, wenn Organisationen bereit sind, an ihren Prozessen als Ganzes zu arbeiten - also auch Anforderungen, Test, Deployment/Release und Betrieb zu optimieren. Einer meiner Kunden aus der Finanzbranche hat das letztens mal prägnant formuliert: "Da müsste mal von ganz oben jemand durchregieren - um den Silo-Fürsten die Macht über ihre Teilprozesse zu beschneiden."
• Lokale statt globale Optimierung: Entwickler besitzen einen fast unbändigen Drang zur Verbesserung, den sie gerne in Form von Refactorings oder kleinen lokalen Veränderungen ausleben. Solange umfassende und komplett automatisierte Tests diese Veränderungen auf mögliche Nebenwirkungen überprüfen, ist das gut. Manchmal verlieren Entwicklern jedoch den Überblick über die negativen Konsequenzen ihrer lokalen Änderungen auf andere Teile des Systems... Wir sollten Verbesserungen stets in etwas größerem Kontext betrachten - also über den Tellerrand einzelner Personen hinweg schauen. Das ist meiner Ansicht nach eine klassische Aufgabe für die Rolle "Softwarearchitektur".
• Wenig Verständnis für Zusammenhänge im Großen: Ich bekomme in realen Projekten oftmals zu hören: "Wir können ja die Wechselwirkungen auf andere Systemteile gar nicht mehr genau beurteilen".... Solange Projekte das Thema "Übersichtsdokumentation" weiter vernachlässigen, wird mangelnde Übersicht auch ein Problem bleiben.

Bin ich zu pessimistisch?

Klar, wir können auch "gut": Homogene Teams, ohne Fluktuation, über viele Sprints hinweg mit ausreichend Zeit und Budget ausgestattet, denen verständige und kundige Managerinnen den Rücken freihalten, und denen exzellente Product-Owner ordentliche und konsistente Anforderungen geben. Ich arbeite seit fast 30 Jahren in der Softwareentwicklung, habe praktisch alle Branchen von innen erlebt. Meine Teams reichten von 3 bis zu mehr als 200 Personen, Informationssysteme, Embedded-Systeme, Business-Intelligence, moderne und ziemlich alte Technologie, große und kleine, arme und reiche Auftraggeber... und die stets wiederkehrende Konstante all dieser Situationen ist die massive Unordnung. Nein - ich selbst glaube nicht, dass ich hier zu pessimistisch schreibe.

Abhilfe: Systematische Verbesserung

Unsere Grundthese bei der Verbesserung lautet:

"Reduktion technischer Schulden führt zu Kostensenkung in der Entwicklung neuer Features."

Sie müssen mit Ihrem Management über systematische Verbesserung sprechen, über zielgerichtete und gesteuerte Modernisierung und Evolution. Dabei müssen Sie zwischen "Features-liefern" und "Schulden abbauen" abwägen, denn Sie können einerseits niemals für längere Zeit auf neue Fachlichkeit verzichten, und müssen andererseits garantiert mit beschränktem Budget zurecht kommen. Als zentral erweisen sich dabei zwei Parameter:

• Innere Qualität der Systeme, die sich in Themen wir niedriger Kopplung, hoher fachlicher Kohäsion, hoher Codequalität, Konsistenz (Homogenität) der Implementierung und Verständlichkeit äussern.
• Äußere Qualität der Systeme. Anders ausgedrückt: Business-Wert, die Menge fachlicher Features, fachliche Leistung, Performance, Benutzerfreundlichkeit, Skalierbarkeit, Menge der erfüllten Kundenwünsche.

Argumentieren Sie gegenüber Ihrem Management, dass bei systematischer Verbesserung (d.h. Steigerung der inneren Qualität) die fachlichen Features wirtschaftlich günstiger ("preiswerter") werden - und wir zukünftig damit bessere time-to-market erreichen! Ihr Management kennt sicherlich den traurigen Normalfall: Über die Zeit werden bei (vielen) Systemen Features immer teurer, bzw. die Entwicklung immer langsamer (in der folgenden Abbildung die rote Linie). Ihr Management benötigt einen Überblick, welche Probleme es bei Systemen gibt- und wie "schlimm" diese wirklich sind, am besten in Geldeinheiten ausgedrückt. Damit werden verschiedene Probleme miteinander vergleichbar. Wenn Sie unsicher sind, geben Sie diese Problemkosten in Intervallen an, oder beschränken Sie sich auf die Angabe von Größenordnungen. Dazu stellen Sie Ihrem Management vor, welche Abhilfen es für welche Probleme gibt - am besten jeweils mehrere Alternativen. Hüten Sie sich davor, von der "einzigen Möglichkeit" zu sprechen, die angeblich ein Problem löst: Normalerweise gibt es zu jedem (!!) Problem nämlich eine Vielzahl möglicher Abhilfen. Erklären Sie, dass systematische Verbesserung längerfristig angelegt ist, und durchschnittlich sowohl den "business value" der Systeme verbessert (also für die Anforderungs-/Fachseite den Wert der Systeme steigert), gleichzeitig (!) aber auch die technischen Schulden reduziert. Das (Open-Source) Projekt aim42 (architecture improvememt method) stellt für die systematische Verbesserung fast 100 "good practices" zusammen, etablierte und bewährte Vorgehensmuster.

Fazit: Das klappt wirklich!

Vorsicht - Eigenwerbung: Sie können systematische Verbesserung lernen - wir bieten dazu den dreitägigen Workshop "IMPROVE" an.

An dieser Stelle möchte ich Ihnen Mut zusprechen: Hartnäckigkeit und Systematik lohnt sich: Ich habe in unterschiedlichen Branchen IT-Systeme verschiedener Größe und Komplexität "systematisch verbessert". Mit Teams zusammen habe ich time-to-market deutlich verkürzt, Test- und Entwicklungsaufwände gesenkt, Performance verbessert und in praktisch allen Fällen die Zufriedenheit der Teams signifikant erhöht. Ich habe (skeptische) Manager überzeugen können, dass Verbesserung sich wirtschaftlich lohnt. In diesem Sinne - bleiben Sie "am Ball". Erklären Sie, wie schlimm ihre Probleme sind, und welche direkten und indirekten Kosten sie verursachen. Update 9. Oktober 2016: Fixed typos.