Technische Schulden (auch bekannt als Designschulden [ 1 ] oder Codeschulden ) beschreiben qualitativ die Kosten für die Systemwartung , die durch die Wahl einer pragmatischen Entwicklungslösung entstehen. [ 2 ] Eine solche Lösung kann zwar kurzfristig die Entwicklung beschleunigen, die daraus resultierende geringe Qualität kann jedoch zukünftige Kosten erhöhen, wenn die Probleme nicht behoben werden. [ 3 ] Der Begriff wird häufig im Kontext der Informationstechnologie und insbesondere der Softwareentwicklung verwendet .

Technische Schulden ähneln zwar monetären Schulden , unterscheiden sich aber wesentlich von ihnen. Beide Arten von Schulden erschweren in der Regel das Erreichen zukünftiger Ziele. Im Gegensatz zu monetären Schulden entstehen technische Schulden jedoch oft unbeabsichtigt. Der Hauptgrund dafür ist die Entscheidung, Entwicklungszeit und -kosten zu minimieren – ein allgegenwärtiger Aspekt im Geschäftsleben . Technische Schulden werden üblicherweise erst im Nachhinein (nach Abschluss eines Entwicklungsprojekts) ermittelt.

Die korrekte Verwaltung technischer Schulden ist unerlässlich für die Aufrechterhaltung der Softwarequalität und die langfristige Nachhaltigkeit. In manchen Fällen ist die Aufnahme technischer Schulden eine strategische Entscheidung, um kurzfristige Ziele zu erreichen, beispielsweise die Bereitstellung eines Proof of Concept oder einer schnellen Veröffentlichung. Werden technische Schulden jedoch nicht priorisiert und angegangen, kann dies zu einer geringeren Wartbarkeit, höheren Entwicklungskosten und Risiken für Produktionssysteme führen. [ 4 ] [ 5 ]

Technische Schulden entstehen durch Design- und Implementierungsentscheidungen, die zwar kurzfristig optimieren, aber auf Kosten der zukünftigen Anpassungsfähigkeit und Wartbarkeit gehen. Systemaspekte, die technische Schulden verursachen, lassen sich als eine Sammlung von Design- oder Implementierungskonstrukten beschreiben, die zukünftige Änderungen verteuern oder unmöglich machen und sich primär auf interne Systemeigenschaften wie Wartbarkeit und Weiterentwicklungsfähigkeit auswirken. [ 6 ]

Herkunft

Ward Cunningham prägte 1992 den Begriff der technischen Schulden . [ 7 ] Nach der Lektüre von Metaphors We Live By entwickelte Cunningham diese Schuldenmetapher, um seinem Chef die Notwendigkeit einer Refaktorisierung des Finanzprodukts, an dem sie arbeiteten, zu erklären: [ 8 ] [ 9 ]

Die Auslieferung von Code beim ersten Mal ist vergleichbar mit einer Verschuldung. Eine kleine „Schuld“ beschleunigt die Entwicklung, solange sie durch eine Überarbeitung umgehend beglichen wird. Die Gefahr entsteht jedoch, wenn die „Schuld“ nicht beglichen wird. Jede Minute, die mit nicht ganz korrektem Code verbracht wird, zählt als Zinsen für diese „Schuld“. Ganze Entwicklungsorganisationen können unter der Last einer unkonsolidierten Implementierung, ob objektorientiert oder nicht , zum Stillstand kommen . [ 10 ]

Ähnliche Konzepte gab es bereits zuvor. 1980 veröffentlichte Meir „Manny“ Lehman ein ähnliches Gesetz, das die sich verschlechternde Natur von Software anhand einer „Architekturmetapher “ veranschaulichte. Mannys Gesetz besagt: „Da ein sich entwickelndes Programm ständig verändert wird, nimmt seine Komplexität, die eine sich verschlechternde Struktur widerspiegelt, zu, sofern keine Maßnahmen zu seiner Wartung oder Reduzierung ergriffen werden.“ [ 11 ]

Ursachen

Häufige Ursachen für technische Schulden sind:

Druck, die Entwicklungszeit zu minimieren
Ein allgegenwärtiger Aspekt des Geschäftslebens.
Unerwartete und unklare Merkmale und Änderungen
Die Umsetzung von Spezifikationsänderungen in letzter Minute oder von Änderungen, die unzureichend dokumentiert oder getestet sind, [ 12 ] : 4 [ 13 ] : 22 [ 14 ]
Wissens- oder Kompetenzlücken
Dies kann sich in mangelndem Prozessverständnis , unzureichendem Wissen, schwacher technologischer Führung oder ungenügenden Mentoring- oder Wissensaustauschpraktiken äußern . [ 13 ] [ 13 ] : 17
Probleme im Entwicklungsprozess
Beispiele hierfür sind suboptimale Lösungen, unzureichende Anforderungen (aufgrund von Prozessineffizienzen), widersprüchliche Anforderungen an parallele Zweige, aufgeschobenes Refactoring oder verzögerte Beiträge aus dem Upstream-Bereich. [ 14 ] [ 13 ] : 29
Nichteinhaltung bewährter Verfahren
Beispiele hierfür sind unzureichende Softwaredokumentation , mangelhafte Zusammenarbeit, fehlende Verantwortlichkeiten, Überarbeitungen für ausgelagerte Software, unzureichende Beachtung der Codequalität, eng gekoppelte Komponenten , fehlende Testsuite oder die Nichteinhaltung von Standards (einschließlich der Missachtung branchenüblicher Frameworks ). [ 12 ] [ 12 ] : 7 [ 13 ]

Konsequenzen

Durch steigende Wartungskosten erschwert die technische Verschuldung die Prognose von Release-Terminen. „Zinszahlungen“ entstehen durch unvollständige Arbeiten und steigende Integrationskosten aufgrund von Änderungen im vorgelagerten Projekt. Zunehmende Komplexität und der Umfang unvollständiger Arbeiten erschweren die genaue Aufwandsschätzung , was zu Verzögerungen, verpassten Deadlines und einer Belastung der Entwicklerteams führt. Dies kann wiederum die Personalfluktuation erhöhen und das Problem verschärfen. [ 15 ] Technische Schulden im Produktivbetrieb erhöhen das Risiko von Ausfällen, finanziellen Verlusten und potenziellen Rechtsstreitigkeiten aufgrund von Verstößen gegen Service-Level-Agreements . Zukünftige Refactorings werden riskanter und kostspieliger, da Änderungen am Produktionscode die Wahrscheinlichkeit von Störungen erhöhen.

Wird die technische Schuld nicht angegangen, kann dies zu sinkender Produktivität und verzögerter Feature-Entwicklung führen. Die kumulativen Auswirkungen der technischen Schuld führen zu zunehmend instabilen Systemen, die grundlegende Verbesserungen erschweren. Die Dominanz inkrementeller Änderungen, gepaart mit Verzögerungen bei kritischen Refactoring-Maßnahmen, kann zu überlasteten Systemen mit inkonsistentem Design führen. Dies beeinträchtigt die Benutzerleistung und den Funktionsumfang, während die Entwickler mit der Qualitätssicherung zu kämpfen haben. [ 1 ] [ 16 ]

Planung

Kenny Rubin verwendet die folgenden Kategorien, um die technischen Schulden zu verwalten: [ 17 ]

Zufällig angetroffen
Dem Entwicklerteam war die Existenz dieser Schwachstelle nicht bekannt, bis sie im Rahmen der normalen Produktentwicklung aufgedeckt wurde. Beispielsweise fügte das Team dem Produkt eine neue Funktion hinzu und stellte dabei fest, dass vor Jahren von einem längst ausgeschiedenen Kollegen eine Umgehungslösung in den Code eingebaut worden war.
Bekannt
Dem Entwicklerteam bekannt und wurde mithilfe verschiedener Methoden sichtbar gemacht.
Gezielt
Bekannt und vom Entwicklungsteam für Wartungsarbeiten vorgesehen.

Einschränkungen

Das Konzept der technischen Schulden geht davon aus, dass eine übermäßig schnelle Entwicklung zu zusätzlichen zukünftigen Kosten führt und dass diese Kosten vermieden werden könnten, wenn während der Entwicklung andere Entscheidungen getroffen worden wären. Das trifft zwar zu, jedoch beeinflussen weitere Faktoren die potenziellen Kosten schneller Entwicklungsentscheidungen. Wenn das System beispielsweise nicht lange genug überlebt, um für eine spätere Version angepasst zu werden, sind die Einsparungen durch die schnelle Entwicklungsentscheidungen tatsächlich Einsparungen, da keine weiteren Entwicklungskosten anfallen. [ 18 ] Zukünftige Ereignisse können schnelle, „langfristige“ Designs überflüssig machen. [ 19 ] Neue Werkzeuge und Techniken könnten die Kosten zukünftiger Nacharbeiten reduzieren und damit die aktuellen Annahmen zu technischen Schulden in Frage stellen. [ 19 ]

Siehe auch

Referenzen

  1. ^ a b Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells (1. Aufl.). Morgan Kaufmann. S. 258. ISBN 978-0128013977Die
  2. ^ „Definition des Begriffs „Technische Schulden“ (sowie einige Hintergrundinformationen und eine „Erläuterung“)“ . Techopedia . Abgerufen am 11. August 2016 .
  3. ^ Allman, Eric (Mai 2012). „Managing Technical Debt“. Communications of the ACM . 55 (5): 50–55 . doi : 10.1145/2160718.2160733 . S2CID 53246391 . 
  4. ^ Jeffries, Ron. „Technische Schulden – Schlechte Metapher oder noch schlimmere Metapher?“ . Archiviert vom Original am 11. November 2015. Abgerufen am 10. November 2015 .
  5. ^ Knesek, Doug. „Eine Krise der technischen Schulden abwenden“ . Abgerufen am 7. April 2016 .
  6. ^ Avgeriou, Paris; Kruchten, Philippe; Ozkaya, Ipek; Seemann, Carolyn (2016). „Management technischer Schulden in der Softwareentwicklung (Dagstuhl-Seminar 16162)“ (PDF) . Dagstuhl-Berichte . 6 (4).
  7. ^ „Technische Schulden“ . Techopedia . 13.06.2024 . Abgerufen am 06.02.2025 .
  8. ^ Ward Cunningham (14.02.2009). Schuldenmetapher . Abgerufen am 06.02.2025 – via YouTube.
  9. ^ „Ward erklärt die Schuldenmetapher“ . wiki.c2.com . Abgerufen am 06.02.2025 . Die Erklärung, die ich meinem Chef gab – es ging um Finanzsoftware –, war eine Finanzanalogie, die ich „die Schuldenmetapher“ nannte. Damit meinte ich, dass wir, wenn wir unser Programm nicht an das anpassten, was wir damals als die richtige Denkweise für unsere Finanzobjekte verstanden, immer wieder über diese Diskrepanz stolpern und dadurch ausgebremst würden, was vergleichbar wäre mit dem Zahlen von Zinsen für einen Kredit.
  10. ^ Cunningham, Ward (26.03.1992). „Das WyCash Portfolio-Management-System“ . Abgerufen am 26.09.2008 .
  11. ^ Lehman, M. M. (1996). „Gesetze der Softwareentwicklung neu betrachtet“ . EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology : 108–24 . ISBN 9783540617716Abgerufen am 19. November 2014 .
  12. ^ a b c Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11. November 2014). Refactoring for Software Design Smells: Managing Technical Debt . Elsevier Science. S. 3. ISBN 978-0-12-801646-6Die
  13. ^ a b c d e Chris Sterling (10. Dezember 2010). Managing Software Debt: Building for Inevitable Change (Adobe Reader) . Addison-Wesley Professional. S. 17. ISBN 978-0-321-70055-1Die
  14. Rios , Nicolli; Spínola, Rodrigo Oliveira; Mendonça, Manoel; Seaman, Carolyn (11.10.2018). „Die häufigsten Ursachen und Auswirkungen technischer Schulden: Erste Ergebnisse einer globalen Reihe von Industrieumfragen“ . Proceedings of the 12th ACM/ IEEE International Symposium on Empirical Software Engineering and Measurement . ESEM '18. New York, NY, USA: Association for Computing Machinery. S.  1–10 . doi : 10.1145/3239235.3268917 . ISBN 978-1-4503-5823-1Die
  15. ^ Ali, Junade (September 2016). Mastering PHP Design Patterns | PACKT Books (1. Aufl.). Birmingham, England, UK: Packt Publishing Limited. S. 11. ISBN 978-1-78588-713-0Archiviert vom Original am 1. Juni 2020. Abgerufen am 11. Dezember 2017 .
  16. ^ Kerievsky, Joshua (2004). Refactoring to Patterns . Addison-Wesley. ISBN 978-0-321-21335-8Die
  17. ^ Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process , Addison-Wesley, S. 155, ISBN 978-0-13-704329-3
  18. ^ Fowler, Martin. „Technische Schulden“ . martinfowler.com .
  19. ^ a b Fowler, Martin. "Technical Debt Quadrant" . martinfowler.com .