Wenn technische Schulden zur Ausrede verkommen, ist ein Richtungswechsel dringend angebracht.elmar gubisch | shutterstock.com Agile-Pionier Ward Cunningham hat den Begriff Technical Debt maßgeblich geprägt und definiert (PDF). Dabei ging der Informatiker davon aus, dass technische Schulden auf einer bewussten Entscheidung basieren: Zwar ist den Devs klar, dass es einen besseren, “korrekteren” Weg zum Ziel gäbe – aber sie wählen einen anderen, der im Nachgang Kosten verursacht. Solche Entscheidungen werden für gewöhnlich getroffen, um Projekte zu beschleunigen – allerdings sollten die Entwickler die entstandene Schuld auch zu einem späteren Zeitpunkt “begleichen”. Anders ausgedrückt: Existiert kein Jira-Ticket im Backlog, um den ungünstigen Code zu bereinigen, handelt es sich auch nicht um Technical Debt. Technische Umschuldung? In der Realität haben wir die Definition von technischen Schulden so weit ausgedehnt, dass der Begriff fast bedeutungslos geworden ist. Inzwischen wird einfach jeder schlechte Haufen Code mit diesem Etikett versehen. Egal, ob er das Ergebnis einer bewussten Entscheidung war oder es einen Plan gibt, diesen zukünftig zu bereinigen (was in den meisten Fällen nicht zutrifft). So wird auch Code, der unter die Definition von “Accidental Complexity” (PDF) fällt, regelmäßig das Technical-Debt-Label aufgedrückt. Ebenso wie hastig zusammengeschusterten “Notfalllösungen”. In der Konsequenz schafft das willkommene Gelegenheiten, die eigentlichen Ursachen für schlecht umgesetzte Lösungen zu verschleiern – etwa fehlendes Knowhow, Nachlässigkeiten oder massiver Zeitdruck. So werden vermeidbare Fehler zu “technischen Schulden”. Das klingt nicht nur besser, sondern erweckt auch den Eindruck, die Unwägbarkeiten würden später behoben – obwohl allen Beteiligten klar ist, dass es niemals dazu kommen wird. Etabliert sich ein Mindset dieser Art in Entwicklungsteams, ist der Niedergang nur eine Frage der Zeit. Schließlich ist so immer eine billige Ausrede für schlechte Entscheidungen und Praktiken verfügbar. Echte technische Schulden sollten mit einem klaren Arbeitsauftrag, beziehungsweise einem Korrekturplan inklusive Deadline verknüpft sein. Alles andere muss als das benannt werden, was es ist: minderwertiger Code. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Technische Schulden als billige Ausrede
Wenn technische Schulden zur Ausrede verkommen, ist ein Richtungswechsel dringend angebracht.elmar gubisch | shutterstock.com Agile-Pionier Ward Cunningham hat den Begriff Technical Debt maßgeblich geprägt und definiert (PDF). Dabei ging der Informatiker davon aus, dass technische Schulden auf einer bewussten Entscheidung basieren: Zwar ist den Devs klar, dass es einen besseren, “korrekteren” Weg zum Ziel gäbe – aber sie wählen einen anderen, der im Nachgang Kosten verursacht. Solche Entscheidungen werden für gewöhnlich getroffen, um Projekte zu beschleunigen – allerdings sollten die Entwickler die entstandene Schuld auch zu einem späteren Zeitpunkt “begleichen”. Anders ausgedrückt: Existiert kein Jira-Ticket im Backlog, um den ungünstigen Code zu bereinigen, handelt es sich auch nicht um Technical Debt. Technische Umschuldung? In der Realität haben wir die Definition von technischen Schulden so weit ausgedehnt, dass der Begriff fast bedeutungslos geworden ist. Inzwischen wird einfach jeder schlechte Haufen Code mit diesem Etikett versehen. Egal, ob er das Ergebnis einer bewussten Entscheidung war oder es einen Plan gibt, diesen zukünftig zu bereinigen (was in den meisten Fällen nicht zutrifft). So wird auch Code, der unter die Definition von “Accidental Complexity” (PDF) fällt, regelmäßig das Technical-Debt-Label aufgedrückt. Ebenso wie hastig zusammengeschusterten “Notfalllösungen”. In der Konsequenz schafft das willkommene Gelegenheiten, die eigentlichen Ursachen für schlecht umgesetzte Lösungen zu verschleiern – etwa fehlendes Knowhow, Nachlässigkeiten oder massiver Zeitdruck. So werden vermeidbare Fehler zu “technischen Schulden”. Das klingt nicht nur besser, sondern erweckt auch den Eindruck, die Unwägbarkeiten würden später behoben – obwohl allen Beteiligten klar ist, dass es niemals dazu kommen wird. Etabliert sich ein Mindset dieser Art in Entwicklungsteams, ist der Niedergang nur eine Frage der Zeit. Schließlich ist so immer eine billige Ausrede für schlechte Entscheidungen und Praktiken verfügbar. Echte technische Schulden sollten mit einem klaren Arbeitsauftrag, beziehungsweise einem Korrekturplan inklusive Deadline verknüpft sein. Alles andere muss als das benannt werden, was es ist: minderwertiger Code. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Technische Schulden als billige Ausrede Wenn technische Schulden zur Ausrede verkommen, ist ein Richtungswechsel dringend angebracht.elmar gubisch | shutterstock.com Agile-Pionier Ward Cunningham hat den Begriff Technical Debt maßgeblich geprägt und definiert (PDF). Dabei ging der Informatiker davon aus, dass technische Schulden auf einer bewussten Entscheidung basieren: Zwar ist den Devs klar, dass es einen besseren, “korrekteren” Weg zum Ziel gäbe – aber sie wählen einen anderen, der im Nachgang Kosten verursacht. Solche Entscheidungen werden für gewöhnlich getroffen, um Projekte zu beschleunigen – allerdings sollten die Entwickler die entstandene Schuld auch zu einem späteren Zeitpunkt “begleichen”. Anders ausgedrückt: Existiert kein Jira-Ticket im Backlog, um den ungünstigen Code zu bereinigen, handelt es sich auch nicht um Technical Debt. Technische Umschuldung? In der Realität haben wir die Definition von technischen Schulden so weit ausgedehnt, dass der Begriff fast bedeutungslos geworden ist. Inzwischen wird einfach jeder schlechte Haufen Code mit diesem Etikett versehen. Egal, ob er das Ergebnis einer bewussten Entscheidung war oder es einen Plan gibt, diesen zukünftig zu bereinigen (was in den meisten Fällen nicht zutrifft). So wird auch Code, der unter die Definition von “Accidental Complexity” (PDF) fällt, regelmäßig das Technical-Debt-Label aufgedrückt. Ebenso wie hastig zusammengeschusterten “Notfalllösungen”. In der Konsequenz schafft das willkommene Gelegenheiten, die eigentlichen Ursachen für schlecht umgesetzte Lösungen zu verschleiern – etwa fehlendes Knowhow, Nachlässigkeiten oder massiver Zeitdruck. So werden vermeidbare Fehler zu “technischen Schulden”. Das klingt nicht nur besser, sondern erweckt auch den Eindruck, die Unwägbarkeiten würden später behoben – obwohl allen Beteiligten klar ist, dass es niemals dazu kommen wird. Etabliert sich ein Mindset dieser Art in Entwicklungsteams, ist der Niedergang nur eine Frage der Zeit. Schließlich ist so immer eine billige Ausrede für schlechte Entscheidungen und Praktiken verfügbar. Echte technische Schulden sollten mit einem klaren Arbeitsauftrag, beziehungsweise einem Korrekturplan inklusive Deadline verknüpft sein. Alles andere muss als das benannt werden, was es ist: minderwertiger Code. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!