© Ekaphon maneechot/Shutterstock.com
Über den bewussten Umgang mit technischer Qualität

„Funktioniert“ ist nicht genug


Budgetzwänge, fachliche wie technische Komplexität und volatile Anforderungen gehören zum Projektalltag der IT-Branche. Gleichzeitig predigen moderne Vorgehensmodelle Geschäftswert und Anwenderfokus. In dieser Gemengelage vergessen wir allzu leicht die Hauptzutat erfolgreicher Projekte: Programmcode. Über den bewussten Umgang mit dieser Zutat jenseits des Entwicklerteams möchte ich hier sprechen.

Wenn Sie die aktuellen IT-Trends verfolgen, hören und lesen Sie viel über Architekturen, Methoden und Techniken: Cloud Computing, Scrum und Kanban, dieses Framework und jene Programmiersprache. Das sind alles wichtige und faszinierende Themen, aber je mehr Teams und Projekte ich in meiner Rolle als Coach begleite, desto stärker empfinde ich das Bedürfnis, für eine bewusstere und breitere Auseinandersetzung mit der ebenso selbstverständlichen wie, in der allgemeinen Wahrnehmung, zunehmend als „gelöst“ und „unspektakulär“ betrachteten Tätigkeit des Programmierens zu werben. Im Folgenden möchte ich daher eine Brücke zu den Ideen eines modernen Programmierhandwerks insbesondere für diejenigen unter den Lesern schlagen, die aufgrund ihrer Rolle sonst wenig Einblick in die „Implementierungsdetails“ ihrer Projekte haben.

Was geht mich das an?

Meiner Erfahrung nach finden die handwerklichen Aspekte der Softwareentwicklung unter Nichtprogrammierern aus zwei Gründen häufig keine Betrachtung: Zum einen lässt sich argumentieren, dass hochqualifizierte Entwickler und Softwarearchitekten durchaus ohne äußeres Zutun in der Lage sind, angemessene technische Qualität sicherzustellen. Und tatsächlich gibt es Initiativen, die sich ausgiebig mit der Weiterentwicklung und Verfeinerung von Programmierpraktiken auseinandersetzen. In der Realität jedoch arbeiten Entwicklungsteams nicht im kontextfreien Raum, und während des gesamten Projektlebenszyklus werden von allen Beteiligten immer wieder weitreichende Entscheidungen gefällt. Viele der Tätigkeiten, die sich unter Programmierern als richtig und notwendig durchgesetzt haben, sind aber nur schwer durchzusetzen, wenn aus politischen und organisatorischen Gründen inkompatible Rahmenbedingungen etabliert wurden. Zum anderen gibt es schlichtweg häufig keine Lobby für technische Qualität. Wörter, wie „Over-Engineering“, „goldene Wasserhähne“ und „Technikverliebtheit“ machen die Runde. Was zählt, sind sichtbare Ergebnisse. Wir zitieren den Benutzer, der mit Konzepten wie sauberem Programmcode wenig anzufangen weiß und führen Herstellungskosten und Budgetzwänge als Argument an. Interessanterweise sind diese Ansichten für sich genommen auf den ersten Blick stichhaltig und im Sinne der häufig anzutreffenden Rollenverteilung in Softwareprojekten auch richtig. Trotzdem wird in der Praxis aus mit besten Vorsätzen und großem Enthusiasmus begonnenen Projekten viel zu häufig eine Wartungshölle, an der sich alle Beteiligten aufreiben.

Hauptsache, es funktioniert!

Wieso gehen Softwareprojekte aber immer wieder in diese Falle? Software hat eine perfide Eigenschaft: Nichtentwickler können von „außen“ praktisch nicht erkennen, in welchem Zustand sie sich befindet. Software rostet und klappert nicht, wenn die Verarbeitung schlecht ist. Weder fängt sie an zu stinken, wenn ihr Haltbarkeitsdatum abgelaufen ist, noch funktioniert sie zwangsläufig schlechter, solange auf Funktionalität fokussierte Qualitätssicherung betrieben wurde. Verwundert es da, wenn sich die Frage aufdrängt, ob diese, scheinbar nur für einen kleinen Kreis sichtbare, technische Qualität überhaupt eine Rolle spielen sollte? Hauptsache, es funktioniert! Gleichzeitig fällt es leichter, die diffusen, durch sinkende Entwicklerproduktivität und mangelnde Softwarewartbarkeit verursachten Kosten zu akzeptieren, als den abgrenzbaren Aufwand, den qualitätssichernde und -steigernde Maßnahmen verursachen. Dadurch wird fast zwangsläufig jede Aktivität im Umfeld dieser ominösen internen Qualität zu einem Einsparungspotenzial. Auf der anderen Seite scheinen Projekte früher oder später zwangsläufig in eine Situation zu geraten, in der jedes Einsparungspotenzial realisiert werden muss: „Sportliche“ Aufwandsschätzungen haben einen unerfüllbaren Erwartungsdruck aufgebaut, „Scope Creep“ frisst Budgetreserven auf, übereifrige, agile Missionare predigen Hyperproduktivität. Und tatsächlich ist im Fall der Softwareentwicklung schneller ja auch immer besser.

Technische Schulden

Leider gibt es ein Problem, das sich wohl am besten mit der von Ward Cunningham geprägten Metapher der „technischen Schulden“ („technical debt“ [1]) beschreiben lässt: Wenn wir anfangen, mehr Produktivität auszugeben, als uns aufgrund unserer Fähigkeiten und der Komplexität des zu lösenden Problems zur Verfügung steht, häufen wir technische Schulden an. Technische Schulden haben viele Gesichter: Fehlendes Softwaredesign, unzureichende Test- oder Projektautomatisierung, unsauberer Code oder unbeabsichtigte Komplexität sind häufig anzutreffende Facetten. Gemein ist allen Formen technischer Schulden, dass sie zu einem Verschleiß der Software führen. Dieser Verschleiß wiederum erschwert die Weiterentwicklung und erhöht das Risiko von Regressionsfehlern. Dadurch werden Zinsen fällig (Kasten: „Zinsen auf technische Schulden“), die Nettoproduktivität sinkt. Tilgen wir nicht durch geeignete Maßnahmen, kommt es im schlimmsten Fall zur Überschuldung. Erweiterungen an der Software werden unbezahlbar, Projekte müssen abgebrochen, bestehende Softwaresysteme ohne funktionalen Mehrwert abgelöst werden. Hier schließt sich der Kreis: Der auf den ersten Blick rationale Versuch, durch unbedingte Beschleunigung schneller ans Ziel zu kommen, führt auf der...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang