„Software zu schreiben ist wie Schulden aufnehmen. Geringe Schulden aufzunehmen beschleunigt die Softwareentwicklung, solange die Schulden rasch durch eine Neuimplementierung getilgt werden... Problematisch wird es, wenn die Schulden nicht zurückgezahlt werden. Jede Minute, die man mit nicht so gutem Code verbringt, zahlt man Zinsen für diese Schulden. Ganze Entwicklungsabteilungen können durch die Schulden unbereinigter Implementierung (egal ob objektorientiert oder nicht) zum Stillstand gezwungen werden.“
Viele kleine technische Schulden
Public domain images
- Ward Cunningham zu Technischer Schuld, OOPSLA 1992
"Technische Schuld" ist die Maßzahl schlechthin um technische Qualität einer Software zu bewerten. Sie beziffert die Kosten, die man aufbringen muss um technische Fehler auszubessern. Man kann natürlich versuchen mit Technischen Schulden zu leben - wie bei finanziellen Schulden muss einem aber bewusst sein, dass das Zinsen kostet. Zinsen in Form von teureren Features, mehr Bugs, mehr Produktionsausfälle etc. Üblicherweise sinkt dadurch die Produktivität auf 1/10tel bis 1/66tel (vgl. dazu Warum ist Softwareentwicklung so teuer?).
Wie hoch ist der Zinsaufwand in meinem Projekt? Wieviel Zeit & Geld kostet uns die schlechte technische Qualität? Jeder Entwickler kann von Projekten berichten, wo die Zinsen für die Technische Schuld so hoch waren, dass Wartung und Weiterentwicklung de-facto zum Erliegen kamen. Derartige Software gilt als unwartbar und muss entweder mit enormen Kosten refactorisiert oder (mit meist noch enormeren Kosten) von Grund auf neu geschrieben werden. Der Zinsaufwand für Technische Schuld kann also jedes Projektbudget sprengen.
Auftraggeber und Projektleiter sind oft fassungslos, wenn sie hohe Schätzungen für offensichtlich kleine Features präsentiert bekommen ("ein neues Feld in die Maske einbauen kann doch nicht 6 Stunden dauern"). Noch fassungsloser sind sie, wenn die Umsetzung dann noch deutlich höher ist als die ohnedies hohen und mit satten Puffern versehenen Schätzungen ("es kann doch nicht sein, dass aus einer Schätzung von 6 Stunden plötzlich 3 Tage geworden sind"). Meist sind das jedoch dieselben Auftraggeber und Projektleiter, die im Projekt die meisten Qualitätsverbesserungsmaßnahmen mit ("dafür haben wir keine Zeit / kein Budget") abgetan haben. Der Zusammenhang zwischen schlechter Qualität und extremen Aufwänden erschliesst sich ihnen leider nicht.
Die Software, an der ich aktuellen arbeite, hat eine Technische Schuld von ca. 80 konkret definierten technischen Maßnahmen, die im Laufe der Entwicklung erkannt wurden aber noch nicht umsetzen werden konnten. Darüber hinaus gibt es noch diverse verfehlte Qualitätsmetriken wie doppelter Code, Methoden mit zu hoher Komplexität, Architekturverletzungen, zyklische Abhängigkeiten, ungenügende Testabdeckung etc. In Summe schätze ich beläuft sich die Technische Schuld dieser Software auf 5-6 Personenjahre.
Wie konnte es dazu kommen? An dieser Software waren und sind einige der besten Java Entwickler & Architekten Österreichs beteiligt, es wurde von Anbeginn an ein Focus auf hohe technische Qualität gelegt, es gab und gibt Projektmanager, die so gut es ihnen möglich war technische Verbesserungsmaßnahmen zuließen - an sich ideale Bedingungen für qualitativ hochwertige Software.
Leider muss man sagen, dass 5-6 Personenjahre Technische Schuld im Vergleich zu anderer Software dieser Größenordnung ein geradezu herausragend guter Wert ist - schlecht, aber immer noch besser als viele andere Projekte. Dennoch: 5-6 Personenjahre Technische Schuld ist nicht wenig und reduziert die Produktivität teils deutlich.
Projektfokussierung ist einer der Hauptgründe, warum die Technische Schuld steigt: Wenn sich alles und jeder neuer Fachlichkeit und dem Fixen fachlicher Fehler unterordnen muss, dann bleibt die technische Qualität naturgemäß auf der Strecke. Outsourcing/Offshoring, Technikverliebtheit und fehlende bzw. falsch eingesetzte Puffer für QS-Maßnahmen sind weitere Bedingungen, die konkret in unserem Fall, aber auch in vielen anderen Projekten die Technische Schuld teils deutlich steigen lassen.
Wie aber kann man mit Technischer Schuld am besten umgehen? Idealerweise lässt man Technische Schuld von vornherein gar nicht aufkommen. Dazu benötigt man von Beginn des Projektes an strenge Quality Gates, umsichtige und nicht technikverliebte Lead-Developer und Softwarearchitekten, sowie ein starkes Management, welches keine qualitativen Kompromisse zu Erreichung von (oft ohnedies willkürlichen) Meilensteinen eingeht.
Was aber wenn man mitten in einem Projekt steckt welches bereits Technische Schuld angehäuft hat? Dazu gibt es ein paar interessante Tipps & Tricks sowie einige kontroverse Vorschläge - siehe Schuldentilgung.
Wie hoch ist der Zinsaufwand in meinem Projekt? Wieviel Zeit & Geld kostet uns die schlechte technische Qualität? Jeder Entwickler kann von Projekten berichten, wo die Zinsen für die Technische Schuld so hoch waren, dass Wartung und Weiterentwicklung de-facto zum Erliegen kamen. Derartige Software gilt als unwartbar und muss entweder mit enormen Kosten refactorisiert oder (mit meist noch enormeren Kosten) von Grund auf neu geschrieben werden. Der Zinsaufwand für Technische Schuld kann also jedes Projektbudget sprengen.
Auftraggeber und Projektleiter sind oft fassungslos, wenn sie hohe Schätzungen für offensichtlich kleine Features präsentiert bekommen ("ein neues Feld in die Maske einbauen kann doch nicht 6 Stunden dauern"). Noch fassungsloser sind sie, wenn die Umsetzung dann noch deutlich höher ist als die ohnedies hohen und mit satten Puffern versehenen Schätzungen ("es kann doch nicht sein, dass aus einer Schätzung von 6 Stunden plötzlich 3 Tage geworden sind"). Meist sind das jedoch dieselben Auftraggeber und Projektleiter, die im Projekt die meisten Qualitätsverbesserungsmaßnahmen mit ("dafür haben wir keine Zeit / kein Budget") abgetan haben. Der Zusammenhang zwischen schlechter Qualität und extremen Aufwänden erschliesst sich ihnen leider nicht.
Die Software, an der ich aktuellen arbeite, hat eine Technische Schuld von ca. 80 konkret definierten technischen Maßnahmen, die im Laufe der Entwicklung erkannt wurden aber noch nicht umsetzen werden konnten. Darüber hinaus gibt es noch diverse verfehlte Qualitätsmetriken wie doppelter Code, Methoden mit zu hoher Komplexität, Architekturverletzungen, zyklische Abhängigkeiten, ungenügende Testabdeckung etc. In Summe schätze ich beläuft sich die Technische Schuld dieser Software auf 5-6 Personenjahre.
Wie konnte es dazu kommen? An dieser Software waren und sind einige der besten Java Entwickler & Architekten Österreichs beteiligt, es wurde von Anbeginn an ein Focus auf hohe technische Qualität gelegt, es gab und gibt Projektmanager, die so gut es ihnen möglich war technische Verbesserungsmaßnahmen zuließen - an sich ideale Bedingungen für qualitativ hochwertige Software.
Leider muss man sagen, dass 5-6 Personenjahre Technische Schuld im Vergleich zu anderer Software dieser Größenordnung ein geradezu herausragend guter Wert ist - schlecht, aber immer noch besser als viele andere Projekte. Dennoch: 5-6 Personenjahre Technische Schuld ist nicht wenig und reduziert die Produktivität teils deutlich.
Projektfokussierung ist einer der Hauptgründe, warum die Technische Schuld steigt: Wenn sich alles und jeder neuer Fachlichkeit und dem Fixen fachlicher Fehler unterordnen muss, dann bleibt die technische Qualität naturgemäß auf der Strecke. Outsourcing/Offshoring, Technikverliebtheit und fehlende bzw. falsch eingesetzte Puffer für QS-Maßnahmen sind weitere Bedingungen, die konkret in unserem Fall, aber auch in vielen anderen Projekten die Technische Schuld teils deutlich steigen lassen.
Wie aber kann man mit Technischer Schuld am besten umgehen? Idealerweise lässt man Technische Schuld von vornherein gar nicht aufkommen. Dazu benötigt man von Beginn des Projektes an strenge Quality Gates, umsichtige und nicht technikverliebte Lead-Developer und Softwarearchitekten, sowie ein starkes Management, welches keine qualitativen Kompromisse zu Erreichung von (oft ohnedies willkürlichen) Meilensteinen eingeht.
Was aber wenn man mitten in einem Projekt steckt welches bereits Technische Schuld angehäuft hat? Dazu gibt es ein paar interessante Tipps & Tricks sowie einige kontroverse Vorschläge - siehe Schuldentilgung.
Keine Kommentare:
Kommentar veröffentlichen