Sind Bugs Teil der technischen Schulden?

Unser Scrum Master bezeichnet Bugs weiterhin als technische Schulden. Hat er recht, werden Bugs in der Welt von Agile als technische Schulden angesehen?

Ich denke, die Antwort hier ist ziemlich einfach - das Hauptmerkmal der technischen Verschuldung ist, dass sie uns nach Wahl zufällt.

Wir entscheiden uns dafür, Architektur-, Design- oder Implementierungsentscheidungen zu treffen, von denen wir erwarten, dass sie uns später Probleme bereiten, um bestimmte Ziele früher zu erreichen.

Ein Fehler ist nichts, was wir in unserem Code haben wollen - also de facto keine technische Schuld.

Natürlich kann man alle möglichen interessanten (und möglicherweise stichhaltigen) Argumente über die nach der Entdeckung getroffenen Entscheidungen vorbringen, aber im Grunde (und insbesondere im Zusammenhang mit der Frage) sind Fehler keine technischen Schulden - das klingt für mich eher nach einem Missbrauch des Modeworts Bingo.

Als Nachsatz stimme ich der Behauptung nicht zu, dass technische Schulden zu Fehlern an und für sich führen, da dies weit über die Art der getroffenen Entscheidungen hinausgeht. Zum Beispiel können Sie gut geschriebenen, gut strukturierten, testbedeckten Code haben, der immer noch architektonische Kompromisse für eine frühzeitige Bereitstellung eingeht. In ähnlicher Weise könnten Sie sich dafür entscheiden, Ihre Bereitstellungsprozesse nicht zu automatisieren, was nicht zu Fehlern, sondern wahrscheinlich zu viel Stress und Schmerzen führen wird. Natürlich, wenn die Schuld ist, dass Sie Code geschrieben haben, der nicht SOLID (oder was auch immer) ist, dann ja ... aber das ist keineswegs immer der Fall.

Ja.

Technical Debt (auch als Design Debt oder Code Debt bezeichnet) ist eine neologistische Metapher, die sich auf die möglichen Folgen einer schlechten oder sich entwickelnden Softwarearchitektur und Softwareentwicklung innerhalb einer Codebasis bezieht.

Quelle: Wikipedia

Lesen Sie technische Schulden als etwas, das Sie hätten vermeiden können, wenn Sie einen besseren Workflow hätten (z. B. eine ordnungsgemäße Architektur vor dem Umstieg auf das Codieren, das Ausführen von TDD usw.), bessere Codierungsverfahren usw.

Die meisten Fehler hätten durch zusätzliche Überprüfung oder den Einsatz formellerer Methoden vermieden werden können. Indem Sie nicht alles tun, um Fehler zu vermeiden, senken Sie die unmittelbaren / kurzfristigen Kosten des Projekts, erhöhen aber die technischen Schulden.

Nachdem ich die Antwort von BЈовић gelesen habe , sehe ich, dass es möglicherweise nicht so einfach ist, wie ich dachte.

• Sind Bugs zum Beispiel Teil der technischen Verschuldung? Artikel behauptet, dass nur Bugs, von denen Sie wissen, die Sie aber nicht beheben möchten, Teil der technischen Schulden sind.

• Ein weiteres Beispiel: Christopher's Thoughts on Technical Debt qualifiziert Bugs als Ergebnis einer technischen Verschuldung, die nicht Teil davon ist. Davon abgesehen werden viele der aufgelisteten Ergebnisse, wie "Kosten für die Implementierung neuer Funktionen", von der Anzahl der Fehler beeinflusst.

• Schließlich habe ich bei der Erstellung des ABCDE-T-Modells für die technische Verschuldung Fehler als einen der sechs Faktoren berücksichtigt, die jedoch unterschiedlich betrachtet werden. Der Fokus liegt nicht auf den Fehlern selbst, sondern auf der Art und Weise, wie sie gesammelt, priorisiert und behoben werden. Fehler selbst erscheinen als Ergebnis einer technischen Verschuldung (wie im vorherigen Beispiel), jedoch nie als Faktor für eine technische Verschuldung.

Dies wird gesagt, bin ich immer noch auf Antwort geneigt , dass Bugs -alle bugs- sind Teil der technischen Schulden.

Erstes Argument:

Wenn man Jeff Atwoods Zitat liest, qualifizieren sich die meisten Bugs als:

Der zusätzliche Aufwand, den wir für die zukünftige Entwicklung aufgrund der schnellen und schmutzigen Designauswahl leisten müssen

In Geschäftsanwendungen ist fast jeder Fehler auf eine schnelle und unsaubere Auswahl des Designs oder auf schlechte Praktiken zurückzuführen (wären dies fehlende Tests, der Einsatz von Technologien, die die Entwickler nicht genug kennen, mangelnde Kommunikation, mangelndes Verständnis der Domäne, usw.) Dies bedeutet, dass "durch Umgestaltung des schnellen und schmutzigen Designs in ein besseres Design" und durch Anpassung besserer Praktiken die meisten Fehler behoben werden können.

Zweites Argument:

Wenn wir eine Parallele zwischen der normalen Verschuldung eines Unternehmens, die beim Verkauf eines Unternehmens an ein anderes Unternehmen zu berücksichtigen ist, und der technischen Verschuldung herstellen, die ebenfalls zu berücksichtigen ist, wenn ein Projekt an ein anderes Unternehmen verkauft oder übergeben wird Bei einem anderen Team können wir leicht erkennen, dass Fehler Teil der technischen Verschuldung sind, da das neue Team:

• Entweder müssen Sie sich mit diesen Fehlern auseinandersetzen, bevor Sie neue Funktionen erstellen (Punkt 5 von Joel Test: Beheben Sie Fehler, bevor Sie neuen Code schreiben?)

• Oder behalte die Bugs und bewahre / erhöhe auf diese Weise die technische Verschuldung.

Jeff Atwood gibt in seinem Artikel " Rückzahlung Ihrer technischen Schulden" eine gute Antwort darauf, was technische Schulden sind:

Für die technische Verschuldung fallen Zinszahlungen an, die sich aus dem zusätzlichen Aufwand ergeben, den wir für die künftige Entwicklung aufgrund der schnellen und schmutzigen Auswahl des Designs leisten müssen. Wir können uns dafür entscheiden, die Zinsen weiterhin zu zahlen, oder wir können den Kapitalbetrag abzahlen, indem wir das schnelle und schmutzige Design in das bessere Design umgestalten. Die Tilgung des Kapitals ist zwar kostenintensiv, wir profitieren jedoch von künftig geringeren Zinszahlungen.

Streng genommen gehören Fehler nicht zur technischen Verschuldung, wenn sie die weitere Softwareentwicklung nicht verlangsamen (Änderungen vornehmen, neue Funktionen hinzufügen usw.). Sie sind Software-Defekte.

Wenn es jedoch zu teuer ist, einen Fehler zu beheben, oder Sie gezwungen sind, ihn zu umgehen (und noch mehr technische Schulden einzuführen), wird er Teil einer technischen Schuld.

Ein Bug ist keine technische Schuld. Die technische Verschuldung mindert die Qualität, nicht das Fehlen. Software sollte in erster Linie nicht mit Fehlern ausgeliefert werden. Sie wissen, dass die ganze Arbeitssoftware über umfassende Dokumentation verfügt.

Die größten Straftäter für technische Schulden sind "vorübergehende Fehlerkorrekturen". Sie kennen diejenigen, die Sie eingesetzt haben, um den Test zu bestehen und die Story zu akzeptieren. Diejenigen, die Sie sich selbst versprochen haben, werden Sie später umgestalten, aber niemals tun. Da sich diese temporären Fixes, Patches und andere Dinge ansammeln, wird der Code unnötig unübersichtlich, schwierig zu aktualisieren und zu testen und ist im Allgemeinen ein Albtraum, aber er macht immer noch seinen Job.

Zur Unterstützung dieser Meinung ging ich direkt zur Quelle, Ward Cunningham. Bezüglich dessen hat Ward vor einiger Zeit ein gutes Interview mit Capers Jones geführt, es ist eine Uhr wert.

Debatte über technische Schulden mit Ward Cunningham & Capers Jones

Ein weiterer lesenswerter Artikel ist von Martin Fowler

Martin Fowler über technische Schulden

In Martins Artikel finden Sie den Link zur ursprünglichen Erwähnung der technischen Schulden durch Ward Cunningham von OOPSLA92:

Das WyCash Portfolio Management System

Ein Zitat aus dem obigen Artikel:

Obwohl unausgereifter Code gut funktioniert und für den Kunden völlig akzeptabel ist , führen überschüssige Mengen dazu, dass ein Programm nicht mehr beherrschbar ist, was zu einer extremen Spezialisierung der Programmierer und schließlich zu einem unflexiblen Produkt führt. Der Versand von First-Time-Codes ist wie das Eingehen von Schulden.

Am Ende könnte Technical Debt für einige Leute Fehler enthalten haben, und ich denke, das ist in Ordnung. Ich glaube einfach nicht, dass dies die ursprüngliche Absicht war.

Genau genommen lautet die Antwort auf Ihre Frage Nein.

Technische Schulden können (und werden wahrscheinlich) zu Fehlern führen. Die Schlussfolgerung, dass ein Fehler das Ergebnis einer technischen Verschuldung ist, legt jedoch eine Interpretation zwischen zwei Tatsachen nahe: Es gibt einen Fehler und eine technische Verschuldung (vorausgesetzt, dies kann als Tatsache angenommen werden).

Wenn Ihr Scrum-Meister "als Theorie" angibt, dass Fehler das Ergebnis von technischen Schulden sind, schneidet er Abstriche. Wenn er dies über bestimmte Bugs sagt, die immer wieder auftauchen, hat er möglicherweise recht - wir können die Codequalität von hier aus nicht sehen ;-)

Er hat möglicherweise auch eine anhaltende Beschwerde darüber, dass die Leute ihn nicht über die technische Verschuldung belauschen und daher jeden Fehler als technische Verschuldung bezeichnen, aber jetzt spekuliere ich.

Meiner Meinung nach spielt es keine Rolle, ob Sie sagen, dass Fehler Teil der technischen Verschuldung sind ... oder nicht.

Tatsache ist, dass vorhandene Fehler zusätzliche Arbeit darstellen, die möglicherweise in Zukunft ausgeführt werden muss, um sie zu beheben oder um sie zu umgehen.

Technische Schulden (wie das Etikett normalerweise verwendet wird) bedeuten auch zusätzliche Arbeiten, die möglicherweise in Zukunft ausgeführt werden müssen ... auf die eine oder andere Weise.

Ob Sie also sagen, dass bekannte (oder unbekannte) Fehler technische Schulden sind oder nicht, ist eigentlich nur eine Frage der Definition. Und da es keine maßgebliche Definition ¹ von "technischer Verschuldung" gibt, ist die ganze Diskussion irgendwie sinnlos.

Wie Lewis Carroll schrieb:

"Wenn ich ein Wort verwende", sagte Humpty Dumpty verächtlich, "bedeutet es genau das, was ich damit meine - weder mehr noch weniger." .

So funktioniert natürliche Sprache. Wörter bedeuten, was Leute denken, dass sie bedeuten. Wörterbuchdefinitionen usw. dokumentieren lediglich die Art und Weise, wie Wörter verwendet werden, und sie sind nicht unbedingt eine genaue Dokumentation. Wenn Ihr Scrum Master bekannte Fehler als technische Schulden bezeichnen möchte, wer sagt dann, dass er "falsch" liegt?

^{1 - Leute wie Ward Cummingham und Caper Jones zu zitieren, hilft auch nicht. Bestenfalls sagt es uns, was sie meinen (oder meinten), wenn sie die Phrase benutzen (benutzten). Sie "besitzen" die Phrase nicht. Während sie zweifellos Autoritäten in diesen Fragen sind, ist dies immer noch nur ihre Meinung.}