Von Grund auf neu aufbauen: Unser Weg zur Beseitigung von technischer Schulden mit dem CCS AI Classifier

Als wir mit der Entwicklung unseres neuen, KI-gestützten Klassifizierungsprodukts begannen, war uns klar, dass das Management technischer Schulden von Anfang an entscheidend für unseren langfristigen Erfolg und die Bereitstellung echten Mehrwerts sein würde.

Im Mittelpunkt standen dabei die Nutzerorientierung und die Förderung einer Kultur der Transparenz, häufigen Kommunikation und kalkulierter Risiken. Wir haben uns mit unserem CCS Product Owner, Dejan Manojlovski, zusammengesetzt, um Einblicke in seine Erfahrungen zu gewinnen.

Beginnen wir mit den Grundlagen. Was genau sind technische Schulden, und was verursacht sie in der Regel?

Technische Schulden beziehen sich auf die impliziten Kosten für Nacharbeiten, die entstehen, wenn man jetzt eine einfache oder eingeschränkte Lösung wählt, anstatt eines besseren Ansatzes, der möglicherweise länger dauert. Es ist wie bei finanziellen Schulden – diese Abkürzungen verzinsen sich und müssen später durch Wartung und Refactoring beglichen werden. Oder, wie ich manchmal denke, es ist wie das konsequente Auslassen des Beintrainings im Fitnessstudio – man fühlt sich vielleicht anfangs schneller, aber irgendwann holt es einen ein!

Verschiedene Dinge verursachen sie. Zeitdruck ist ein großer Faktor; eilige Fristen bedeuten oft, dass man Abstriche macht. Sich ändernde Anforderungen sind ein weiterer Faktor – häufige Änderungen können zu schnellen Patches anstelle von durchdachten Integrationen führen. Und besonders beim Aufbau von etwas Neuem mit neuer Technologie kann ein Mangel an tiefgreifendem Fachwissen zu anfänglichen Architektur- oder Codierungsentscheidungen führen, die nicht gut skalieren. Diese anfängliche Lernkurve kann technische Schulden einbrennen, wenn man nicht aufpasst.

Welche Strategien haben wir angesichts dieser Risiken implementiert, um technische Schulden zu vermeiden?

Die größte Herausforderung besteht typischerweise darin, alle davon zu überzeugen, dass ein überlegteres Vorgehen jetzt einen morgen tatsächlich schneller macht. Mit dieser Denkweise haben wir verschiedene Strategien angewendet.

Erstens haben wir, wo immer möglich, einen modularen Ansatz gewählt und Komponenten als unabhängige Module aufgebaut. Dies hat wirklich geholfen, die Dinge übersichtlich zu halten und die separate Entwicklung, das Testen und die Wartung von Teilen zu ermöglichen. Wir haben auch eine bewusste Entscheidung getroffen und ehrlich gesagt hart dafür gekämpft, komplett neu anzufangen und die Zwänge alter Codebasen oder Datenmodelle zu vermeiden. Der Aufbau von Grund auf stellte sicher, dass wir mit einer modernen, wartbaren Grundlage begannen.

Intern haben wir eine starke Qualitätskultur durch rigorose Code Reviews und Pair Programming gefördert. Wir haben sogar ein spezielles Entwickler-"Refactoring Meeting", das sich ausschließlich mit der Bewältigung technischer Schulden befasst. Dabei ging es nicht nur um die Codequalität; es war entscheidend für den Wissensaustausch. Automatisiertes Testen war ebenfalls nicht verhandelbar und bot ein Sicherheitsnetz, um Fehler frühzeitig zu erkennen.

Entscheidend war, dass wir uns frühzeitig und häufig mit unseren Kunden und internen Stakeholdern austauschten. Wir hatten das Glück, während der gesamten Entwicklung eine enge Partnerschaft zu pflegen. Dieser ständige Feedback-Loop stellte sicher, dass wir das Richtige bauten und uns schnell anpassen konnten.

Welche Risiken birgt die Ignorierung technischer Schulden?

Das Problem ignorieren ist etwas, das man wirklich nicht tun möchte, da die Risiken beträchtlich und gravierend sind. Zum einen können die Wartungskosten in die Höhe schnellen, da schlecht geschriebener Code im Laufe der Zeit exponentiell schwerer und teurer zu beheben wird. Die Agilität sinkt: Angesammelte Schulden machen die Implementierung neuer Funktionen oder Änderungen unglaublich schwierig, manchmal unmöglich. An diesem Punkt ist die Innovation praktisch tot.

Man ist auch mit Systeminstabilität konfrontiert. Mit Schulden behafteter Code ist oft anfällig für Bugs und Abstürze, was zu unzuverlässigen Systemen führt. Dies ist nicht nur ein technisches Problem; es trifft die Moral der Entwickler hart. Ständiges Arbeiten mit unübersichtlichem, schwierigem Code ist unglaublich frustrierend. Und letztendlich wirkt sich all dies auf die Kundenerfahrung aus. Instabilität und mangelnde Verbesserungen führen zu Unzufriedenheit und potenziellen Geschäftsverlusten. Das ist ein schwerer Schlag.

Wie sollten Teams also am besten proaktiv vorgehen, um diese abzubauen?

Es erfordert eine strukturierte, fortlaufende Anstrengung. In jedem Sprint stellen wir sicher, dass wir spezifische Zeit für das Refactoring einplanen – das Aufräumen und Verbessern von bestehendem Code ist Teil des regulären Arbeitsablaufs und nicht eine nachträgliche Überlegung. Auch wenn es vielleicht nicht die glamouröseste Aufgabe ist, ist die Pflege einer gründlichen und klaren Dokumentation von entscheidender Bedeutung, damit jeder das System versteht. Und schließlich benötigt man eine effiziente Möglichkeit, technische Schulden zu verfolgen, sie sichtbar zu machen und es zu ermöglichen, die Tilgung als integralen Bestandteil des Entwicklungszyklus zu priorisieren.

Etwas völlig Neues aufzubauen, ist das nicht einschüchternd?

Definitiv nicht, es ist eigentlich aufregend! Ich persönlich finde es nicht einschüchternd, etwas völlig Neues aufzubauen. Mit der richtigen Einstellung, guter organisatorischer Unterstützung und einer gesunden Portion Neugier ist es wirklich aufregend. Ich sehe es oft wie das Aufziehen eines Kindes oder den Beginn einer neuen Beziehung – man weiß nicht genau, was dabei herauskommen wird, aber man freut sich auf den nächsten Tag voller Vorfreude.

Sicher, manche mögen die Unsicherheit entmutigend finden, aber ich sehe sie als eine erstklassige Gelegenheit zur Innovation. Eine klar definierte Vision hilft immens. Die Zusammenarbeit mit einem kompetenten und kollaborativen Team lindert den Druck – man lernt, dem Team zu vertrauen, wenn es schwierig wird. Wie das Sprichwort sagt: "Wenn es hart auf hart kommt, werden die Harten hart."

Das Aufteilen des Projekts in kleinere, überschaubare Teile macht die Gesamtaufgabe weniger überwältigend. Und wie ich bereits erwähnt habe, helfen der Aufbau starker Partnerschaften mit Kunden und Stakeholdern zusammen mit einer Kultur der Transparenz und des schnellen Feedbacks, Probleme frühzeitig zu erkennen und zu beheben, um die Dinge auf Kurs zu halten.

Schließlich trägt die Schaffung einer Kultur der Transparenz und die Förderung schneller Feedback-Schleifen dazu bei, Probleme frühzeitig zu erkennen und anzugehen, was einen effizienteren und effektiveren Entwicklungsprozess gewährleistet.

Fazit:

Nach dem Gespräch mit Dejan ist uns eines deutlich geworden. Die proaktive Bekämpfung technischer Schulden ist nicht nur ein "Nice-to-have", sondern unerlässlich für den Aufbau nachhaltiger, qualitativ hochwertiger Produkte. Unsere Reise bei der Entwicklung der neuen Klassifizierungsplattform hat bestätigt, dass die Investition von Zeit im Vorfeld in eine solide Architektur, sauberen Code und kontinuierliche Verbesserung sich später auszahlt und es uns ermöglicht, schneller Innovationen zu entwickeln und unsere Kunden langfristig besser zu bedienen.