Diskussion:Technische Schulden

Hint(en)anstellen

Ich habe diesen Artikel gelesen und einen - wie ich dachte - Rechtschreibfehler behoben.

Jetzt habe ich dank der Versionsgeschichte erfahren, dass es dieses Wort tatsächlich gibt.

Aber, obwohl es so stimmt, bin ich nicht die einzige Person, der das aufgefallen ist.

• Das Wort ist nicht wahnsinnig geläufig. (Mein Firefox kennt beide Wörter nicht.)
• Das vermeintlich richtige Wort steht zwei Zeilen darüber. Deshalb will man Konsistenz herstellen.

Also, was könnte man tun, um zu verhindern, dass so etwas noch einmal passiert?

• Müsste ich immer in die Versionsgeschichte schauen, ob dieser Fehler schon einmal gemacht wurde?
• Müsste ich bei jedem Wort im Duden nachschlagen?

Und, selbst wenn ich das machen würde, wäre das sicherlich nicht die Lösung für diese Seite. (Ich weiß ja jetzt, dass das so stimmt.)

• Sollten beide Wörter ("Hintanstellen" und "Hintenanstellen") zu einem Wort zusammengefasst werden?
• Sollte ein Kommentar eingefügt werden? (Zum Beispiel "")
• Sollte ein Informationsblock eingefügt werden? (Wahrscheinlich ein bisschen übertrieben.)

--YtvwlD (Diskussion) 19:24, 20. Jul. 2014 (CEST)

Im Artikel haben wir derzeit 3x "hintanstellen/Hintanstellung" und 1x "hintenanstellen". Lt. Duden gibt es letzteres gar nicht, ich persönlich würde unter hintenanstellen auch was anderes verstehen. Ich habs jetzt durchgängig auf hintanstellen/Hintanstellung geändert. Jetzt passts somit lt. Duden. Ich wüsste kein Wort, das besser passt. --Sebastian.Dietrich ✉ 22:15, 24. Jul. 2014 (CEST)

Dann ist das jetzt ja eindeutig. -- YtvwlD (Diskussion) 08:48, 8. Nov. 2014 (CET)

Hintanstellen

Klingt für mich wie Deutsch anno 1850. Wenn es dann noch in Fraktur gesetzt wäre, wäre ich mir sicher, dass es aus dem Jahr 1850 stammt. Ich würde an dieser Stelle die Worte

• Aufschieben
• Verzögern
• Versäumen
• Unterlassen

verwenden. Die deutsche Sprache hat genügend brauchbare Worte, dass man keine Worte wie Hintanstellen oder Hintanstellung braucht. Unten den ersten hundert Treffern von Google sind so gut wie alle irgendwelche Wörterbücher oder Lexika. Der erste "normale" Artikel enthält das Wort als Beispiel von verkorkstem Managerdeutsch:

• Verzichten Sie auf „fremde Wörter“

mit

Wenn Ihr Kunde beispielsweise folgende Zeilen erhält, wird er diese 
mehrfach lesen müssen, bevor er deren Sinn versteht:

  „Die Geschäftsführung stellt Ihnen anheim, ggf. den Vertrag aufzulösen, 
   und erklärt unter Hintanstellung erheblicher Bedenken im Vorhinein ihr 
   Einverständnis.“

Zweitens:
Den Artikelnamen "Technische Schuld" halte ich für unglücklich gewählt. Gemeint sind "Technische Schulden". "Technische Schuld" klingt nach Strafrecht oder Haftung. Weiterhin heißt "debit" eher Schulden, "Schuld" klingt nach fault oder guilt, was hier eindeutig aber nicht gemeint ist. (nicht signierter Beitrag von 195.33.171.8 (Diskussion) 17:22, 23. Jul 2015 (CEST))

Halte zwar Hintanstellen nicht für ein veraltetes Wort, aber wenns für zwei veraltet klingt, muss es ja nicht sein --> habs geeignet umformuliert

Hab auch die Umbenennung des Artikels veranlasst - Grund für mich ist, dass im Deutschen wie Englischen Schuld (en:Guilt) was anderes ist als Schulden (en:Debt) & es im Original technical debt und nicht technical guilt heisst. --Sebastian.Dietrich ✉ 09:14, 24. Jul. 2015 (CEST)

Dieser Abschnitt kann archiviert werden. --Sebastian.Dietrich ✉ 09:08, 24. Jul. 2015 (CEST)

Begriffsdefinition

Die Definition des Begriffes scheint mir nicht korrekt. Der Begriff beschreibt nicht den Mehraufwand der bei der Pflege von schlechtem Code entsteht, sondern vielmehr die Kosten die entstehen um alle im Code befindlichen Qualitätsmängel zu beheben. Zumindest wird so der Technical Debt in Qualitätsmodellen wie SQALE und CISQ ermittelt.

Änderungsvorschlag:

.. Unter der technischen Schuld versteht man den Aufwand, den man einplanen muss, um alle Qualitätsmängel von schlecht geschriebene Software zu beheben. .. -- Ste-cqm (Diskussion) 10:21, 31. Jul. 2015 (CEST)

Ich denke nicht, das es um "schlecht" oder "gut" geht, sondern vielmehr um die Entropie die sich immer in Code einschleicht. Code-Qualität ist nur ein Kriterium mit dem ein Entwickler eine Implementierungsentscheidung abwägen muss. Dauer, Aufwand, Komplexität, Wartbarkeit, Fixed Dates und andere Parameter sind bewusst oder unbewusst mit dabei. Code ist immer "gut genug" zum Zeitpunkt seiner Erzeugung und nie "gut genug" für alles was noch in der Zukunft liegt. (nicht signierter Beitrag von IljaThieme (Diskussion | Beiträge) 13:45, 10. Mär. 2020 (CET))

"Entropie"? Was soll Softwareentwicklung mit Thermodynamik zu tun haben? --87.174.37.241 12:57, 1. Jun. 2023 (CEST)

Nachdem (!?) ich unten schon etwas geschrieben habe fällt mir erst dieser Definitionsvorschlag auf den ich gut finde und noch etwas weiterentwickeln möchte. Wie gesagt geht es mir um das aktivische "schlecht geschrieben". Wie wäre es mit:

.. Unter der technischen Schuld versteht man den Aufwand, den man einplanen muss, um eine (potenziell ältere) Software so zu überarbeiten, dass sie den aktuellen fachlichen, technischen und nicht-funktionalen Anforderungen entspricht. ..

Interessant ist ja, dass sich auch die Anforderungen über die Zeit ändern. Eine super entwickelte Access-DB will ja heute niemand mehr sehen. Da kann aber der Entwickler oder die Software nix für, die Anforderungen an Wartbarkeit und Usability haben sich geändert.

--Dostl ba (Diskussion) 09:46, 2. Sep. 2020 (CEST)

Ich hab den Versuch die Technischen Schulden durch ihren Aufwand zu beschreiben jetzt aus der Einleitung rausgenommen. Dazu gibt es ohnedies den Absatz Technische_Schulden#Messung. Technische Schulden wurden durch die bekannten Informatiker und auch in der Praxis nie als Geldwerte oder Aufwände beschrieben. Technische Schulden sind zunächst mal nur Issues, die zu späteren Aufwänden führen (für deren Bereinigung oder weil sie die Wartung/Weiterentwicklung verzögern). Sie sind eben nicht die Aufwände selbst.

Hab dabei auch entfernt, dass nur bestimmte bekannte Informatiker den Begriff verwenden (den Begriff kennt/verwendet wohl jeder Informatiker, er ist ja schon Jahrzehnte alt und in Literatur und Konferenzen tausendfach behandelt). --Sebastian.Dietrich  ✉  17:53, 6. Jun. 2022 (CEST)

Einleitung

Zur Vermeidung eines WP:Editwars: Es geht um folgende Änderung [1] und dann nach meinem Revert nochmals [2] von @Dostl ba:. Angeblich hast du eine Quelle und Argumentation (zuerst Englische Wikepedia und dann Lehman 80 genannt) und meinst "schlecht gemacht" ist "völlig falsch"

• ad Quelle en Wikipedia: Eine anderssprachige Wikipedia ist in der Wikipedia (in allen Sprachen) nicht eine gültige Quelle. Aber auch wenn die Quelle ungültig ist, bitte sag doch wo in en:Technical debt was zu "Kosten für über die Zeit angefallene Nach- bzw. Umarbeiten an einem (Software-) System" drinnen steht. Dort steht (und darauf beziehst du dich vermutlich): "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer." - also im Gegensatz zu deiner Übersetzung 1) "implied", 2) "caused by choosing an easy (limited) solution now instead of using a better approach that would take longer". Also spricht die en Wikipedia _nicht_ von Kosten für Nach- bzw. Umbauarbeiten an einer Software (das ist Wartung), sondern um _zusätzliche_ Kosten auf Grund von einer schlechteren Lösung.
• Lehman 80: Damit meinst vermutlich "„Gesetz II – Steigende Komplexität: Während Software weiterentwickelt wird, steigt ihre Komplexität, es sei denn es werden Anstrengungen unternommen sie beizubehalten oder zu reduzieren.“" - wennst den Artikel liest, wirst erkennen, dass Lehman damit nicht eine Definition von technischer Schuld abgegeben hat, sondern ein davon unabhängiges Gesetz formuliert hat. Wichtig auch das Wort "weiterentwickelt" - d.h. wird eine Software _nicht_ weiterentwickelt, so steigt ihre Komplexität auch nicht.
• Argumentation - dazu finde ich keine Anhaltspunkte
• "schlecht gemacht" - da bin ich bei dir, das könnte man präziser formulieren. 1) ein anderes Wort für schlecht 2) dass das nicht nur ursprünglich schlecht geschriebene Software betrifft, sondern auch Software, die in der Wartung "verschlechtert" wird. Der Definitionsvorschlag von Ste-cqm im Absatz drüber ist da schon korrekter.
• "völlig falsch" - weiß auch nicht auf was sich das bezieht.

--Sebastian.Dietrich ✉ 20:50, 1. Sep. 2020 (CEST)

• Prima, so ist es besser, als gut gemeinte Verbesserungen einfach zu reverten.
• Mein (fachlicher) Punkt ist, dass technische Schulden auch entstehen können (und so lese ich Lehman 80) wenn man eine gut geschriebene Software nicht "weiterentwickelt" aber auch nicht "wartet" oder modernisiert. So gesehen führt nicht geleistete Wartung zu Technischen Schulden. Im echten Häuslebauer-Leben nennt man sowas wohl "Renovierungsstau". Und das hat eben nichts mit initial "schlecht gemacht" zu tun - egal ob bewusst oder unbewusst.
• Wenn Verantwortliche (die eben die Wartung nicht betrieben haben oder konnten) diese "Einleitung" lesen fühlen sie sich angegriffen. Das ist in der englischen WP zumindest sanfter formuliert.
• zu "völlig falsch": das war deine Bewertung zu meinem Vorschlag.
• zu Zitaten: man kann auch direkt auf die in der englischen WP verwendete Quelle gehen: https://www.techopedia.com/definition/27913/technical-debt Daraus: "Under this line of thinking refactoring is not only a result of poorly written code, but is also done based on an evolving understanding of a problem and the best way to solve that problem." Also nicht "nur" schlecht geschriebener Code, sondern auch ausgebliebenes "mit der Zeit gehen" - sei es technisch oder fachlich.

--Dostl ba (Diskussion) 09:34, 2. Sep. 2020 (CEST)

Nochwas zu Lehman, das erste Gesetz aus dem (40 Jahre alten !!) Artikel ist in diesem Kontext auch interessant: "A program [...] undergoes continual change or becomes progressively less useful". Ist "less useful" technische Schuld ?

--Dostl ba (Diskussion) 09:56, 2. Sep. 2020 (CEST)

@Technische Schulden entstehen auch ohne Änderungen - das ist mMn unmöglich. Eine z.B. damals schuldenfreie Cobol Applikation aus den 50er Jahren, die heutzutage architektonisch/technologisch völlig anders umgesetzt werden würde, hat deshalb keine "Schulden". Derartige Schulden würden nicht zur Metapher von Cunningham passen, der bewusst eine Analogie zu Finanzen gewählt hat, sie würden auch nicht ins Quadrat von Fowler passen und sind auch nicht durch Lehman angesprochen ("As a program is evolved..." also nicht mehr danach).

Bei Häusern gibts Renovierungen (weil sie von alleine kaputt gehen, was bei Software nicht der Fall ist) oder Umbauten (wenn das Haus nicht mehr den geänderten Bedürfnissen entspricht). Umbauten bei Software nennt man adaptive Wartung (Anpassung an äußere Veränderungen), so wie Umbauten bei Häusern sehr wichtig, aber eben nicht durch technische Schulden begründet.

Bei Häusern nimmt man Schulden auf, deren Tilgung meist mehr Geld kostet. Aber wenn das Haus schuldenfrei ist, dann ist es auch noch in 100 Jahren schuldenfrei, auch wenn es dann dringend saniert gehört.

Schau dir mal den Vortrag von Steve McConnel (bei den Weblinks) an - dort ab ca. 0:50 definiert er Technische Schulden als "A design or construction approach that's expedient in the short term but ..." - es geht also immer um Schulden, die von Anfang an Schulden waren.

Der von dir zitierte Satz der techopedia ("based on an evolving understanding of a problem"), sagt nicht aus, dass die Schulden erst später entstehen können, sondern nur, dass sie erst durch das verbesserte Verständnis des Problems erkannt werden (Fowler Quadrant versehentlich/umsichtig)

Also Fazit: Es gibt jede Menge Gründe, warum technischen Schulden nicht alleine durch äußere Einflüsse entstehen können. Wenn du aber wo eine reputable Quelle hast, die explizit schreibt, dass dem doch der Fall ist, dann nehmen wirs natürlich rein (durch Umformulierung der Einleitung und explizite Ausführung wo später im Artikel)

@Verantwortliche fühlen sich angegriffen - Warum sollten sie sich nicht angegriffen fühlen? Bei Programmfehler wird ja auch nicht schöngeredet. Technische Schulden sind Mängel bei einer Software und im Rahmen der Gewährleistung wie alle anderen Mängel auch gratis zu beheben. Hat dein Haus einen technischen Mangel weil z.B. um Zeit zu sparen der Beton nur schlecht angerührt wurde, dann wirst du das ja auch nicht schönreden oder?

@Less useful - nein das ist keine technische Schuld. Das wäre ein fachliches Problem (z.B. Eingabe für Mädchenname nur bei Frauen war mal ok, inzwischen nicht mehr) oder ein technisches Problem (z.B. wenn die Software mitm neuen Betriebssystem nicht mehr läuft). --Sebastian.Dietrich ✉ 11:43, 2. Sep. 2020 (CEST)

@Technische Schulden entstehen auch ohne Änderungen. was ist mit "unterlassener Wartung", führt das zu technischen Schulden? Ich würde sagen ja! zB Last auf einem System steigt durch mehr User / TX-Volumen. Es bräuchte Gegenmaßnahmen (Refactoring) um die Performance beizubehalten, diese werden nicht unternommen. Hier nochmal der Vorschlag von oben, damit wir in einem Thread bleiben: .. Unter der technischen Schuld versteht man den Aufwand, den man einplanen muss, um eine (potenziell ältere) Software so zu überarbeiten, dass sie den aktuellen fachlichen, technischen und nicht-funktionalen Anforderungen entspricht. .. --Dostl ba (Diskussion) 13:12, 2. Sep. 2020 (CEST)

@Zitierfähige Definitionen: wie wäre es mit https://www.construx.com/resources/whitepaper-managing-technical-debt/ (Steve McConnell) "T.D. refers to delayed technical work" Das finde ich ganz gut, da "unterlassene Wartung" auch ein "shortcut" bzw. "delayed technical work" sein kann !? --Dostl ba (Diskussion) 15:01, 2. Sep. 2020 (CEST)

@unterlassener Wartung - nein, das führt nicht zu technischen Schulden. Wenn mehr User, dann hat sich ein non-funktionales Requirement geändert. Das wäre dann adaptive Wartung und genauso vom Auftraggeber zu zahlen, wie wenn ein weiteres Feature dazukommen soll.

@Vorschlag - das wäre die Definition für Weiterentwicklung. Bedenke bitte, dass Technische Schulden ein Gewährleistungsthema und somit vollständig in der Verantwortung des Autragnehmers sind. Was kann der dafür, dass sich die fachlichen, technischen und nicht-funktionalen Anforderungen ändern. Wartung ist aber etwas, wofür der Auftraggeber zahlt - wenn der das nicht zahlt, dann veraltet die Software halt und ist irgendwann nicht mehr einsetzbar.

@delayed technical work - ja das trifft es sehr gut. Hintangestellte technische Arbeit. Unterlassene Wartung ist aber nicht hintangestellte technische Arbeit sondern gänzlich unterlassene Arbeit. So wie wenn man trotz Wartungsvertrags keine Bugfixes macht oder sich nicht drum kümmert, dass die Software auch mit einer aktuellen DB-Version zusammenläuft... --Sebastian.Dietrich ✉ 15:42, 2. Sep. 2020 (CEST)

Technische Schuld vs. Technische Schulden

@Trustable: hat den Artikel nach Technische Schuld mit der Begründung "Singularregel" verschoben. Das ist nicht korrekt. Einerseits ist Schuld nicht der Singular von Schulden (siehe dazu auch Schulden), andererseits ist hier nicht "technical guilt" sonder "technical debt" gemeint. Klar - oft wird technical debt (fälschlicherweise) mit Technische Schuld übersetzt (aber lt. Google Suche immerhin 5x seltener als "Technische Schulden").

Siehe dazu auch oben der Beitrag von 195.33.171.8 vom 23. Jul 2015 (CEST) - der Artikel hieß auch ursprünglich Technische Schuld.--Sebastian.Dietrich  ✉  18:16, 23. Okt. 2021 (CEST)

Nachdem ich von Benutzer:Trustable für die Änderung ein H:THX bekommen habe, hab ich die Rückverschiebung veranlasst. --Sebastian.Dietrich  ✉  08:57, 24. Okt. 2021 (CEST)

Reduktion unmöglich?

Unter „Messung“ steht: „Jede Änderung an der Software erhöht unweigerlich die technischen Schulden um einen unbestimmten Anteil.“

Diese Aussage scheint mir in dieser Form absurd. Denn es würde auch bedeuten, dass z. B. ein Refactoring (letztlich auch nur eine Änderung der Software) total unsinnig ist, weil es auch nur die Technischen Schulden erhöht.

MfG — ThomasO. 21:51, 14. Dez. 2021 (CET)

Der Satz macht so keinen Sinn - habe ihn entfernt. --18:23, 15. Dez. 2021 (CET) (unvollständig signierter Beitrag von Sebastian.Dietrich (Diskussion | Beiträge) )

Wunderbar, danke. — ThomasO. 20:29, 15. Dez. 2021 (CET)