Limbo mit Softwarequalität

Limbo mit Softwarequalität?

Was tun, wenn die technische Qualität einer Software zu wünschen übrig lässt, aber kein Budget vorhanden ist, die Qualität zu verbessern? Unternimmt man nichts, so wird die Qualität weiter sinken - bis die Kosten für Wartung und Weiterentwicklung so hoch sind, dass die Software aufgegeben werden muss. Oft ist aber kein Budget vorhanden um die Qualität zu verbessern - diese Projekte ähneln Hungerkatastrophen - sie leben von der Hand in den Mund wohlwissend, dass sie bald verhungern werden, wenn nicht ein Wunder passiert. In dieser Situation hilft nur eines: Limbo mit Softwarequalität.

Limbo mit Softwarequalität ist eine von mir geprägte Analogie für eine Technik zur Sicherstellung der Softwarequalität. Sie funktioniert folgendermaßen:

1. Definiere die Limbostange: Definiere Qualitätsmetriken, welche im Zuge des Limbos gesichert werden sollen. Konzentriere dich auf diejenigen Metriken, welche deinem Projekt am meisten Produktivität kosten (Architekturmetriken > Designmetriken > Testmetriken > Codemetriken). Diese Metriken sollten alle automatisch eruierbar und in den Build einbaubar sein. Kommuniziere diese Metriken an das Entwicklerteam und auch wie Verletzungen dieser Metriken ausgebaut werden sollten.
2. Setzen die Limbostange: Baue die definierten Metriken in den Build ein. Stelle die Metriken auf exakt die Werte ein, die derzeit durch die Software erreicht werden (egal wie schlecht diese Werte sind). Stelle sicher, dass der Build fehlschlägt wenn eine der Metriken verletzt wird (d.h. schlechtere Werte als derzeit liefert). Die Limbostange wird somit zu einem Teil der Quality Gates der Software.
3. Fällt die Limbostange - d.h. der Build schlägt fehl weil eine der Metriken schlechtere Werte als definiert liefert - so muss der Code sofort korrigiert werden. Wie bei allen Quality Gates hat die Behebung der Fehler höchste Priorität.
4. Wird die Limbostange unterboten - d.h. eine der Metriken liefert (aus welchem Grund auch immer) bessere Werte als bisher - so wird die Limbostange herabgesetzt. Ab sofort müssen die besseren Werte eingehalten werden.

Limbo ermöglicht es mit einem minimalem Initialaufwand von wenigen Tagen bis Wochen (je nach vorliegendem Buildprozess) sicherzustellen, dass die technische Qualität einer Software nicht schlechter wird. Die Korrektur der dann und wann fehlschlagenden Builds ist auf Grund der zeitnahen Behebung der Fehler die effizienteste Art der Fehlerbehebung. Der Aufwand dafür ist vernachlässigbar, da er sich auf Grund der Produktivitätsgewinne durch die bessere Qualität innerhalb weniger Tage amortisiert.

Darüberhinaus garantiert Limbo, dass etwaige Qualitätsverbesserungen auch für die Zukunft gesichert bleiben. Dafür ist es nur notwendig dann und wann manuell die Qualitätsmetriken zu überprüfen und gegebenenfalls zu verbessern. Wenige Minuten Aufwand die viele Stunden oder Tage Mehraufwand sparen können.

Meinen Erfahrungen nach führt Limbo in der Praxis zu folgenden Verbesserungen: 

• Die Qualität wird tatsächlich garantiert. Neue Programmteile müssen mindestens dieselbe Qualität haben, wie bestehende Programmteile. Die Technische Schuld der Software wächst somit nur mehr linear mit der Größe der Software.
• Die Qualität wird langsam, aber stetig besser - ohne dass in die Qualität merkbarer Aufwand investiert wird. Im Schnitt konnte ich pro Entwickler pro Jahr eine Verbesserung um 50% pro 10 KLOC feststellen (d.h. eine Software mit 10.000 (brutto) Lines of Code wird wenn sie von einem Mitarbeiter fulltime gewartet/weiterentwickelt wird mit Limbo innerhalb eines Jahres um 50% weniger technische Fehler aufweisen)
• Die stetig besser werdenden Qualitätsmetriken eignen sich hervorragend für Projektmarketingzwecke. Sowohl nach aussen ("wir haben unsere Qualität im Griff") als auch nach innen ("wir können auf die Qualität unserer Arbeit stolz sein").