Kolumne

Knigge für Softwarearchitekten: Ändern als Normalfall

Peter Hruschka, Gernot Starke

©iStockphoto.com/gunnar3000

Willkommen zu einer neuen Serie unserer Kolumne für Softwarearchitekten. In den bisherigen Folgen hatten wir Sie mit Verhaltensmustern und der Ausbildung von Softwarearchitekten traktiert. Nun geht’s in eine andere Richtung weiter: Wir beleuchten das Thema „Ändern bestehender Software“ aus architektonischer Sicht.

Einstieg in die dritte Staffel: Warum ändern wir Software?

Genau genommen muss die Frage lauten: Warum beauftragen die Eigentümer von Software Änderungen? Änderungen, die wir als Entwickler und Architekten dann umsetzen. Dazu gibt es eine Reihe unterschiedlicher Antworten – von denen erschreckend viele mehr mit Geld als mit Technik zu tun haben:

  1. Unsere Software enthält Fehler, die Einsatz oder Benutzung der Software verhindern oder erschweren.
  2. Es gibt neue oder geänderte Anforderungen an unsere Software. Dies umfasst sowohl funktionale Erweiterungen (sprich: die Software soll zukünftig neue Aufgaben lösen) wie auch nicht funktionale Merkmale (landläufig auch Qualitätsmerkmale genannt).
  3. Änderungen in Ablauf-/Betriebsumgebung: Technische Änderungen an der Infrastruktur (Hardware, Betriebssystem oder irgendwelche Basissoftware) erfordern Änderungen an der Software.
  4. Relevante externe Systeme ändern ihre Schnittstellen – unsere Software ist davon betroffen.
  5. Änderungen im organisatorischen Umfeld: Neue Anwender, Manager, Sponsoren – ein Spezialfall von Punkt 2 (neue Anforderungen).
  6. Hohe Betriebskosten: Betrieb und Administration der Software sind zu teuer.
  7. Hohe Änderungs- oder Reparaturkosten: Bugfixing, Weiterentwicklung, Erweiterung oder Änderung der Software (aus den Gründen 1–6) ist zu teuer.
  8. Intrinsische Motivation der Entwickler: Die innere Struktur oder der Quellcode der Software entsprechen nicht den Zielvorstellungen der Entwickler.

Bei den ersten sieben Gründen spielen Geld und Zeit eine tragende Rolle. Die Art, wie wir als Entwickler Änderungen umsetzen, wird dabei sehr stark durch finanzielle oder zeitliche Randbedingungen bestimmt (sprich: wir arbeiten praktisch immer unter Zeitdruck). Lediglich bei intrinsisch motivierten Änderungen könnten Entwickler ohne Blick auf die Uhr Software ändern.

Theoretisch ist Änderung leicht

Wenn ein eingespieltes, sachkundiges und motiviertes Team nach konsistenten, expliziten Anforderungen und unter Nutzung effizienter Technologien ein System domänen- und testgetrieben entwickelt, konzeptionell durchgängig arbeitet und dazu angemessen dokumentiert, dann ist dieses System (zumindest von diesem Team) leicht änderbar. Keine Leichen im Keller, keine unschönen Altlasten, keine störenden Randbedingungen, keine versteckte Komplexität und keine unbeherrschten Risiken – welch wunderbare Situation zur Änderung von Software.

In über zwanzig Jahren Berufspraxis haben wir dieses Software-Schlaraffenland leider (extrem) selten angetroffen. Entweder wir sind vom Pech verfolgt oder in der Praxis funktioniert Softwareentwicklung suboptimal – mit dem Resultat suboptimaler, schlecht strukturierter, übermäßig komplexer und unverständlicher Systeme, deren Wartung und Pflege sehr viel Mühe bereitet. Personalwechsel, fehlende oder inkonsistente Dokumentation, fehlende Testautomatisierung, mangelnde Modularisierung und Entkopplung, übermäßiger Zeitdruck, ignorierte Komplexität, Vermischung von Technik und Fachlichkeit … Sie kennen das. Viele von uns leiden jeden Tag darunter – von wegen Schlaraffenland und leichte Änderbarkeit.

Änderung als Normalfall

An solchen Systemen (zu denen einige Entwickler despektierlich „Altlasten“ sagen, andere „Legacy“) arbeiten wir den größten Teil unseres Informatiker-, Entwickler- oder Architektenlebens, unter so verschiedenen Bezeichnungen wie Änderung, Erweiterung, Pflege, Wartung, Evolution oder Sanierung.

Aus den oben genannten Gründen (zumindest den ersten sieben) werden große Teile bestehender Software ständig geändert – und das über viele Jahre lang. Unserer Erfahrung in unterschiedlichen Branchen nach bleibt Individualsoftware zwischen fünf und 25 Jahre in Betrieb, und wird meistens über so lange Zeit kontinuierlich verändert. Größere Systeme benötigen teilweise mehrere Jahre an „Reifungszeit“, bevor sie überhaupt sinnvoll einsetzbar sind (Joel Spolsky belegt an einigen Beispielen: „Good Software Takes 10 Years.“ [1] – bei kleinen bis mittleren Systemen geht’s sicherlich auch kürzer.)

Daher wagen wir die These, dass für Entwickler und Architekten die Fähigkeit, Software zu ändern, langfristig wichtiger ist, als Software komplett neu zu konstruieren und zu bauen.

Wenn wir nur könnten …

… wie wir wollten … dann würden wir viele Systeme sicherlich anders bauen, und für manche für uns wesentliche Aufgaben etwas mehr Zeit und Budget spendieren. Von Anfang an würden wir mehr und bessere Vorkehrungen für die (spätere) Änderbarkeit treffen, wir würden sauber entkoppeln und eine Menge automatischer Tests zur Absicherung von Änderungen schreiben. Typischerweise stehen diesem hären Ziel jedoch einige klassische Hindernisse im Weg: Die Interessen (und Budgets) unserer Auftraggeber fokussieren auf dem „Jetzt“, auf aktuell benötigten Features, auf aktuell vorhandener Technologie. Nur sehr eingeschränkt besteht Investitionsbereitschaft in „zukünftiger Änderbarkeit“ – und manche „agilen“ Prozesse unterstützen zu unserem Entsetzen dieses ausschließliche Kurzfristdenken auch noch.

Die aus unserer Sicht typische Situation sieht wie folgt aus: Wir müssen eine signifikante Änderung an einem komplexen System vornehmen, das wir nicht in allen Einzelheiten verstehen. Automatische Testfälle sowie sinnvolle Dokumentation fehlen – wir stochern im Nebel, arbeiten „auf Risiko“. Irgendwie schaffen wir immer die geforderte Änderung – mit mehr Aufwand und höherem Risiko als gedacht. Struktur, konzeptionelle Integrität und „Gesamtgesundheit“ unseres Systems werden durch solche Änderungen immer schlechter, die Menge an technischen Schulden steigt deutlich an.

Wegwerfen ist keine Option

Obwohl wir als Techniker das sicherlich manchmal gerne tun würden, ist „wegwerfen und neu bauen“ fast nie ein gangbarer Weg, denn viel zu viel Investition steckt bereits im bestehenden System. Das darin kodierte Know-how über Branche, Schnittstellen und Technologie lässt sich nur schwer extrahieren – und beim Neubau werden wir garantiert eine Menge (anderer) Fehler machen.

Schon vor fast fünfzehn Jahren hat der großartige Joel Spolsky in [2] sehr eindrücklich vor zu viel Optimismus in dieser Hinsicht gewarnt – sehr empfehlenswerte Lektüre!

Ausbildung fokussiert auf Neuentwicklung

Die in IT-Ausbildung gelehrten Entwurfsprinzipien und -muster, Praktiken guten Software-Engineerings, domänen- und testfokussierte Entwicklung sowie konzeptionelle Integrität von Systemen lassen so manchen Entwickler (zumindest zu Beginn seiner Berufslaufbahn) implizit annehmen, dass jegliche Software auf solch’ vorbildliche Weise entwickelt, klar durchdacht und implementiert wurde. Weit gefehlt – denn reale Systeme sind von diesem Idealbild oftmals weit entfernt.

Konsequent stellen die uns bekannten IT-Ausbildungen die Neuentwicklung in den Vordergrund – und lassen uns im Unklaren, wie wir methodisch und technisch unsere „normale“ Aufgabe lösen – die Änderung bestehender Systeme unter Zeit- und Kostendruck. Viel häufiger ändern, erweitern oder reparieren wir bestehende Systeme, als dass wir „auf der grünen Wiese“, frei von störenden Randbedingungen, neue Software konstruieren und implementieren.

Fazit

Die meisten von uns haben zwar gelernt, Systeme neu zu konstruieren und zu bauen – aber unsere Standardaufgabe „Software ändern“ gehen wir oft ziemlich blauäugig an. Vielerlei typische Schwierigkeiten stehen der (kosten-)effektiven Weiterentwicklung im Wege:

  • Bestehende Daten oder Datenstrukturen und deren Semantik
  • Subsysteme oder Komponenten, an deren Änderung oder Anpassung sich aus Kosten-, Risiko- oder politischen Gründen niemand heranwagt
  • Bestehende externe Schnittstellen, deren technische Details nicht in unserer Verantwortung liegen
  • Technologien, Produkte oder Frameworks, die gravierenden Einfluss auf unsere Software besitzen (und die aus so genanntem Investitionsschutz niemals in Frage gestellt werden dürfen – obwohl es aus rein technischer Sicht erheblich geschicktere oder günstigere Lösungen gäbe)

Investieren Sie bei Ihrer persönlichen Aus- und Weiterbildung in Ihre Fähigkeiten, bestehende Software zu verbessern. Ihre persönliche Bilanz an technischen Schulden sollte grundsätzlich positiv ausfallen – d. h. Ihre Systeme sind nach Änderungen besser, aufgeräumter oder risikoärmer als vor Änderungen. In diesem Sinne – Happy Changing.

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.