Wie entscheidest du, wie viel Zeit in technische Schulden statt in neue Features geht?

Behandle Schulden als Geschäftskosten statt als moralische Frage. Beziffere sie: Wie viel langsamer machen sie Delivery, wie viele Incidents verursachen sie, was passiert bei einem Ausfall. Dann finanziere sie im selben Gespräch wie Features, entweder als stehende Zuteilung (oft fünfzehn bis zwanzig Prozent) oder gekoppelt an Roadmap-Arbeit, die den Bereich berührt. Tilg die Schulden, die tatsächlich Zinsen kosten, nicht den Code, den du nicht magst.

Ich weigere mich, das als separates moralisches Argument zu führen, denn Engineering verliert das immer. Ich mache ein Kostengespräch daraus. Wir führen ein Schuldenregister mit einer Schätzung, was uns jeder Posten kostet: Dieser Service verlängert jedes Feature, das ihn berührt, um zwei Tage, jener hat vier der letzten zehn Incidents verursacht, diese Dependency verliert in neun Monaten den Support und blockiert eine Compliance-Verlängerung. Dann priorisiere ich nach Zinssatz statt danach, wie hässlich der Code ist, denn eine Menge grässlicher Code ist stabil und unangetastet und kann das für immer bleiben. Bei der Finanzierung ist mein Default zwanzig Prozent stehend plus Aufräumen gekoppelt an Roadmap-Arbeit, wenn wir also ohnehin in dem Bereich sind, fixen wir es gleich mit. Das Argument, das bei Produkt ankommt, ist immer das Delivery-Argument. In meinem letzten Team konnte ich zeigen, dass zwei Drittel unserer Incident-Zeit aus einem Legacy-Pfad kamen, und sobald es als wir verlieren dadurch eine Woche pro Monat gerahmt war, war der sechswöchige Fix ein leichter Verkauf statt eines Kampfes.