Kolumne

Knigge für Softwarearchitekten: Spuren verfolgen

Gernot Starke, Peter Hruschka

©Shutterstock/ Dima Sobko

In der letzten Folge haben Sie den Fahnder kennengelernt, der nach Architektur- oder Codesünden, technischen Schulden, Risiken und ähnlichen Missetaten in bestehenden Systemen sucht. Im zweiten Teil diskutieren wir, wie Fahnder mit den Ergebnissen dieser Suche weiterverfahren sollten.

Kennen Sie die Situation: Eine Ihnen bekannte Familie hat gemeinsam einen Urlaub in der Ferne verbracht. Nach deren Rückkehr fragen Sie Frau, Mann und Kinder getrennt nach ihren jeweiligen Eindrücken. Die jeweiligen Beschreibungen fallen total unterschiedlich aus, sodass Sie fast glauben können, die Befragten wären in Wirklichkeit an völlig verschiedenen Orten gewesen.

Subjektive Wahrnehmung lässt die aus Sicht einer einzelnen Person relevanten Eindrücke in den Vordergrund treten: Was einem Menschen als positive Eigenschaft besonders auffällt, bemerkt ein anderer erst gar nicht. Die Windsurferin wird den starken Wind ausführlich loben, ihr sonnenanbetender Partner sich über die ständige Brise beschweren (Ähnlichkeit zu mit den Autoren verwandten Personen ist beabsichtigt).

Lassen Sie uns zunächst mal zusammenfassen, was wir als Ergebnisse einer Fahndung nach Softwaresünden erwarten.

Fahndungsziel: Maßnahmenkatalog

Entgegen der kriminalistischen Fahndung geht es uns bei den Softwaresünden primär um Möglichkeiten, die gefundenen Probleme und Risiken möglichst einfach, kostengünstig und nachhaltig zu beseitigen: Wir möchten priorisierte und in Geld/Aufwandseinheiten bewertete Maßnahmen erarbeiten, mit denen sich die betreffende Software systematisch verbessern lässt.

Die in der letzten Folge beschriebenen Sünden (Architektur-, Code-, Prozess-, Management- und andere Sünden) dienen lediglich als Ausgangspunkt, solche konstruktiven Maßnahmen zu definieren. Nur in Ausnahmefällen möchten wir „Schuldige“ oder „Täter“ als solche identifizieren (um ihnen hoffentlich helfen zu können, aus ihren Fehlern zu lernen).

Bevor wir uns um Abhilfemaßnahmen kümmern können, müssen wir allerdings unsere gefundenen Spuren und Hinweise gründlich überprüfen, an ihnen rütteln und die Spreu vom Weizen trennen.

Sachdienliche Hinweise und Ablenkungsmanöver

Sie haben als Softwarefahnder unterschiedliche Aussagen und Spuren erhalten. Einige davon werden identische Sachverhalte betreffen („alle Befragten beschwerten sich über den zu langsamen CI-Server“), andere werden sich widersprechen (Zeuge A antwortet auf eine Frage mit Ja, Zeuge B auf dieselbe Frage mit Nein).

Manche Ihrer Zeugen lenken, bewusst oder unbewusst, die Aufmerksamkeit von eigenen Schwachstellen oder Fehlern ab: Kritische Probleme oder Risiken bezeichnen sie als Lappalien, bauschen aber Mücken zu Elefanten auf.

Eine Ihrer Aufgaben als gründlicher Fahnder besteht darin, solche reality distortions zu entlarven: Prüfen Sie Alibis, verifizieren Sie Zeugenaussagen durch gezielte Prüfungen des betroffenen Quellcodes oder anderer objektiver Informationsquellen.

[ header = Seite 2: System und Organisation ]

System und Organisation

Softwaresysteme werden von Organisationen (Teams, Gruppen, Abteilungen) entwickelt und betreut. Während der Fahndung nach Softwaresünden vermischen Zeugen oftmals diese beiden Aspekte – und werden Ihnen sowohl organisatorische wie auch systemspezifische Probleme nennen.

Sie sollten das in Interviews durchaus zulassen, in Ihrer Nachbereitung allerdings säuberlich differenzieren. Organisatorische Probleme sollten Sie durch gezielte Fragen bei anderen Beteiligten verifizieren.

Manchmal bilden organisatorische Probleme die Ursache für vielfältige technische Schwierigkeiten: Wir haben beispielsweise erlebt, dass sich Organisationen nicht auf einheitliche Anforderungen und Randbedingungen für Systeme einigen konnten. Daher haben Teams dort an ein- und demselben System mit unterschiedlichen Vorgaben entwickelt – was langfristig natürlich zu gravierenden technischen Problemen führte.

Symptome auf Ursachen zurückführen

Versuchen Sie grundsätzlich, Symptome und Ursachen zu differenzieren. Anstatt dem Patienten immer weiter Schmerzmittel zu geben, sollten Sie besser die Dornen aus der Haut entfernen oder die schmerzhafte Entzündung kurieren.

Wir haben häufig eine fast manische Konzentration auf Symptome erlebt: Da werden Build- und CI-Server mit abstrusen Mengen an RAM versorgt, um den Build um einige Millisekunden zu beschleunigen … statt Hunderte unnötiger Abhängigkeiten und überflüssiger Altlasten durch gezieltes Refactoring zu beseitigen (was den Build von Minuten auf Sekunden beschleunigt hätte).

Leider ist diese Ursachenforschung oft aufwändig und die Konzentration auf Symptome erfüllt das managementinhärente Bedürfnis nach „Wir wollen Taten sehen“ (aka Aktionismus) … aber das ist eine andere Geschichte.

Probleme verursachen Kosten

Wir haben es in der letzten Folge „Follow the Money“ genannt – und möchten den finanziellen Aspekt von Softwaresünden erneut aufgreifen: Wenn ein Problem (eine technische Schuld, eine Softwaresünde) keine benennbaren Kosten verursacht, ist es kein Problem – zumindest aus Sicht von Budgetverantwortlichen.

Wir möchten verhindern, dass Sie aus rein akademischen Gründen, zum Selbstzweck oder der reinen Schönheit des Quellcodes zuliebe Änderungsmaßnahmen ergreifen. Jegliche Verbesserungs- oder Veränderungsmaßnahme kostet Geld/Aufwand und birgt gewisse Risiken – und diese Investition muss sich aus unserer Sicht auch finanziell lohnen. Klären Sie daher, welche Kosten durch die von Ihnen erkannten Probleme entstehen!

Negative Erfahrung hat uns gelehrt, dass manche „Zeugen“ oder betroffene Stakeholder sehr intensiv Probleme schildern, die nur sehr geringe Kosten nach sich ziehen (d. h. aus Gesamt- oder Managementsicht überhaupt keine relevanten Probleme darstellen).

[ header = Seite 3: Abhilfemaßnahmen definieren ]

Abhilfemaßnahmen definieren

Als Krönung Ihrer Fahndung schlagen Sie Maßnahmen vor, mit denen die erkannten Probleme, Sünden und Schulden behoben oder zumindest verbessert werden können. Dabei ist sowohl Ihr technischer Sachverstand wie auch Ihre Kreativität gefragt: Das bestehende Team besteht ja in der Regel aus klugen Menschen, die das Problem alleine nicht haben lösen können. Darum müssen Sie jetzt über den Tellerrand des „Normalen“ hinaus denken können.

Zusätzlich empfehlen wir Ihnen, Ihre Maßnahmen grundsätzlich durch folgende Zusatzinformationen zu fundieren:

  • Welche Kosten/Aufwände verursacht das Problem, das die jeweilige Maßnahme adressiert?
  • Welche Kosten/Aufwände verursacht die Maßnahme, also die Behebung?
  • Aus welchen Detailaufgaben besteht die Maßnahme? Wer oder welche Systemteile sind betroffen?
  • Welche Risiken birgt diese Maßnahme? Welche möglichen Konsequenzen drohen? (Beispiel: Sie steigern durch eine Maßnahme die Sicherheit des Systems auf Kosten der Benutzerfreundlichkeit.)
  • Welche Stakeholder und Ressourcen benötigen Sie zur Umsetzung der Maßnahme?

Oops – das ist eine schwierige Aufgabe: Die Maßnahmenvorschläge an sich werden Sie nach unserer Erfahrung recht schnell identifizieren können – aber deren Bewertung in Geld/Zeiteinheiten ist meist schwieriger. Ohne Letzteres wird Ihnen jedoch kaum ein Manager die Umsetzung von Maßnahmen erlauben.

Fazit

Hinterfragen und priorisieren Sie gefundene Probleme. Trennen Sie rein subjektive von objektiven („nachprüfbaren“) Problemen und fokussieren Sie (sich) auf diejenigen, die relevante Systemziele („Qualitätsanforderungen“) verletzen oder gefährden.

Organisatorische Probleme müssen Sie mit anderen Maßnahmen adressieren als rein technische Systemprobleme – aber: Auch Entwicklungs- oder Managementprozesse können Sie durch gezieltes Refactoring verbessern.

Wenn Sie Maßnahmen zur Verbesserung gefunden haben, dann bewerten Sie diese hinsichtlich ihres jeweiligen Nutzens und ihrer Kosten in Geld/Aufwandseinheiten – nur damit können Sie gegenüber Management und Budgetverantwortlichen nachhaltig argumentieren.

Aufmacherbild: Magnifying glass on a background von Shutterstock / Urheberrecht: Dima Sobko

Geschrieben von
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.  
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.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: