
Für die meisten Entwickler ist eine UUID einfach eine zufällige Zeichenkette, die als eindeutiger Schlüssel verwendet wird. Doch hinter einer UUID kann mehr stecken, als
nur ein paar zufällige Zeichen. Lasst uns das "Rabbit-Hole" der UUIDs erkunden und uns die verschiedenen Versionen ansehen.

# Welche UUID Versionen gibt es?

Es gibt insgesamt 8 verschiedene Versionen von UUIDs, die in der Spezifikation [RFC 9562](https://tools.ietf.org/html/rfc9562) definiert sind.
Höhere Versionen sind nicht unbedingt besser als niedrigere Versionen, sondern dienen dazu, verschiedene Anwendungsfälle zu unterstützen.

### Version 1

[UUID Version 1 (v1)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-1) wird aus der MAC-Adresse des Computers und der aktuellen Zeit generiert.
Somit kann aus diesem UUID-Typ abgeleitet werden, wann und wo die UUID generiert wurde. Dies kann für einige Anwendungsfälle nützlich sein, aber auch ein Sicherheitsrisiko darstellen.

### Version 2

[UUID Version 2 (v2)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-2) ist reserviert für [DCE](https://de.wikipedia.org/wiki/Distributed_Computing_Environment)-Sicherheits-UUIDs.

### Version 3

[UUID Version 3 (v3)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-3) werden aus MD5-Hashes generiert. Als Basis können beliebige Werte verwendet werden.
Häufig werden damit URLs oder andere eindeutige Schlüssel in UUIDs umgewandelt.

Achtung! Verwende diese Version nicht, wenn du sensible Informationen (z.B.: Passwörter) in der UUID speichern möchtest, da MD5 als unsicher gilt.

### Version 4

[UUID Version 4 (v4)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-4) sind rein zufällige UUIDs. Diese Version ist die am häufigsten verwendete Version von UUIDs.
Sie enthalten keinerlei Informationen über den Ersteller oder den Zeitpunkt der Erstellung.

Diese Version ist am besten geeignet, wenn eine zufällige ID benötigt wird. Somit sollte sie als **Standard** verwendet werden, wenn keine speziellen Anforderungen bestehen.

<div className="text-center w-full mb-6">
  <img
    className="max-h-64 m-auto"
    alt="UUIDv4 - Zufällige IDs sind am besten geeignet, wenn keine speziellen Anforderungen bestehen."
    src="/images/blog/8-verschiedene-uuids/uuids.png"
  />
</div>

### Version 5

[UUID Version 5 (v5)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-5) werden aus SHA-1-Hashes generiert. Ähnlich wie bei Version 3 können beliebige Werte als Basis verwendet werden.

Achtung! Verwende diese Version nicht, wenn du sensible Informationen (z.B.: Passwörter) in der UUID speichern möchtest, da SHA-1 als unsicher gilt.

### Version 6

[UUID Version 6 (v6)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-6) fast identisch mit Version 1, jedoch ist die Reihenfolge vertauscht damit die IDs leichter
nach Datum sortiert werden können.

### Version 7

[UUID Version 7 (v7)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-7) kombiniert zufällige Daten (wie in Version 4) mit einem Zeitstempel. Somit wird ein
sortierbarer UUID generiert ohne sensible Informationen wie die MAC-Adresse zu enthalten.

Diese Version ist nützlich, wenn eine UUID benötigt wird, die sortierbar sein soll, z.B. für Datenbanken. Da die MAC-Adresse nicht enthalten ist, ist sie "sicherer" als Version 1.

### Version 8

[UUID Version 8 (v8)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-8) eine Anwendungsspezifische UUID. In dieser Version hat der Ersteller
die Freiheit wie er die UUID generieren möchte.

# Wann sollte ich nun welche Version verwenden?

Mit 8 verschiedenen Versionen von UUIDs kann es schwer sein, die richtige Version für den jeweiligen Anwendungsfall zu finden. Es gibt jedoch einige Faustregeln, die dir helfen können.

- Meistens wird Version 4 als Standard verwendet, wenn eine zufällige UUID benötigt wird. Falls du einfach eine ID benötigst, verwende Version 4.
- Falls die ID sortierbar sein soll, verwende Version 7. Diese Version enthält einen Zeitstempel, der es ermöglicht, die UUIDs nach Datum zu sortieren.
- v5 oder v8 können verwendet werden, um eigene Daten darin zu verpacken. Diese Versionen sind jedoch weniger verbreitet und sollten nur verwendet werden, wenn du genau weißt, was du tust.

Wenn dieser Post dir geholfen hat, teile ihn mit deinen Kollegen. Falls du Fragen hast, schreibe mir gerne eine <a href="mailto:adrian.natter@fortix.io">E-Mail</a>.


UUID Versionen: Welche gibt es und wann sollte ich welche verwenden?


Softwareprojekte können schnell komplex und unüberschaubar werden. Der Druck, Features schnell zu liefern und Deadlines einzuhalten, führt oft dazu, dass die Qualität vernachlässigt wird. Die Konsequenzen sind gravierend: Bugs häufen sich, Nutzer werden unzufrieden, und technische Schulden wachsen. Was kurzfristig Zeit spart, wird langfristig teuer.

**Die Lösung? Effektives Qualitätsmanagement.** Es gewährleistet nicht nur stabile Software, sondern macht sie auch wartbar, skalierbar und nachhaltig erfolgreich. Dabei geht es weit über starre Regeln oder reines Testen hinaus – im Kern stehen durchdachte Prozesse, klare Rollenverteilungen und das richtige Mindset im gesamten Entwicklungszyklus.

#### Warum Qualitätsmanagement der entscheidende Faktor ist

Fehlerhafte Software kostet. Nicht nur in Form von Zeit und Geld, sondern auch in verlorenem Vertrauen. Kunden erwarten Anwendungen, die reibungslos funktionieren, benutzerfreundlich sind und mit wachsenden Anforderungen Schritt halten. Ohne gezieltes Qualitätsmanagement entwickelt sich Software schnell zu einer problematischen Baustelle.

Qualitätsmanagement hat einen klaren Mehrwert:

- **Frühzeitige Fehlererkennung**: Probleme früh im Entwicklungsprozess zu beheben ist effizienter und kostengünstiger. Dies verhindert aufwändige Nachbesserungen und hält den Projektplan auf Kurs.
- **Langfristige Wartbarkeit**: Sauberer, hochwertiger Code lässt sich einfacher erweitern und verbessern. Das spart Zeit bei künftigen Entwicklungen und senkt die Wartungskosten.
- **Stabile Releases**: Gründlich getestete Software schafft Zuverlässigkeit und Vertrauen bei den Anwendern. Ein stabiler Release-Zyklus stärkt die Kundenbindung und entlastet das Entwicklerteam.

Doch was macht Qualitätsmanagement wirklich **effektiv?**

#### Die Bausteine eines effektiven Qualitätsmanagements

Effektives Qualitätsmanagement besteht aus mehreren ineinandergreifenden Elementen. Wir setzen auf drei zentrale Bausteine: **Prozesse**, **Automatisierung** und **Verantwortung**. Nur wenn diese drei Bereiche harmonisch zusammenspielen, entsteht ein nachhaltiges System.

**1. Prozesse: Fehlervermeidung beginnt im Workflow**

Qualitätsmanagement startet nicht erst beim Testen – es beginnt bei der ersten Codezeile. Unsere Prozesse machen Qualität zum integralen Bestandteil der Entwicklung:

- **Strikte Pull-Request-Reviews**: Jede Code-Änderung durchläuft einen gründlichen Review. Dabei prüfen wir Funktionalität, Code-Qualität und Architektur. Diese Reviews verbessern nicht nur den Code, sondern dienen auch als Lernplattform für alle Entwickler. Das Vier-Augen-Prinzip ist hierfür integral.
- **Code kritisch hinterfragen**: Ist der Code zukunftsfähig? Erleichtert er spätere Erweiterungen? Ein guter Review geht über die reine Funktionalität hinaus und stellt sicher, dass der Code auch nach Monaten noch verständlich und wartbar ist.
- **Klare Teststrategie**: Eine durchdachte Teststrategie definiert, welche Features wie und von wem getestet werden. Das spart langfristig Ressourcen und minimiert das Risiko übersehener Fehler. Ausschlaggebend ist hierbei eine gesamtheitliche Teststrategie, bei der alle an Board sind: Produktmanagement, Product Owner und Entwickler.

**2. Automatisierung, die Qualität sichert**

Tools helfen uns, Qualität systematisch sicherzustellen und Fehler zu minimieren:

- **Unit- und Integrationstests**: Damit testen wir die Business-Logik unserer Anwendungen. Diese Tests gewährleisten, dass einzelne Module korrekt funktionieren und nahtlos zusammenarbeiten.
- **End-to-End-Tests mit Cypress**: Wichtige Anwendungsfälle werden automatisiert getestet – besonders die kritischen Features, die manuell nicht immer leicht oder nur zeitaufwändig abzusichern sind. Das steigert die Zuverlässigkeit und reduziert das Risiko von Regressionsfehlern. Gezielte End-To-End-Tests entlasten das Testing Team und garantieren die Funktionalität der Core Features.
- **SonarCloud-Scans**: Unsere CI/CD-Pipeline analysiert den Code und setzt ein **Quality Gate** für Clean Code, Test Coverage und Best Practices. Automatisierte Scans erkennen potenzielle Probleme früh und verbessern die Code-Qualität kontinuierlich.
- **Performance-Tests mit k6**: Bei Bedarf führen wir Lasttests durch, um Skalierbarkeit und Stabilität zu prüfen. So stellen wir sicher, dass die Software auch bei wachsender Nutzerzahl zuverlässig bleibt.

**3. Verantwortung: Qualität ist Teamsache**

Qualitative Software lebt von der gemeinsamen Verantwortung im Team. Klare Rollenverteilung schafft Orientierung:

- **Entwickler**: Sie verantworten das Testing ihrer User Stories und vermeiden Regressionen. Ihr Code muss den Anforderungen entsprechen und darf keine unerwarteten Seiteneffekte verursachen.
- **Product Owner**: Sie gewährleisten, dass die Anwendung die Qualitätsstandards und Anforderungen erfüllt. Sie behalten den Überblick über das Gesamtsystem und priorisieren Tests und Features.
- **Automatisierte Tests**: Sie sichern kritische Features ab, die manuell schwer zu testen sind. Als Sicherheitsnetz reduzieren sie den Aufwand für wiederkehrende Prüfungen.

Nur wenn jeder seine Rolle kennt und wahrnimmt, funktioniert das Qualitätsmanagement.

#### Herausforderungen: Warum gute Qualität kein Selbstläufer ist

Effektives Qualitätsmanagement erfordert Zeit, Disziplin und klare Strukturen. Die größten Herausforderungen:

- **Unklare Verantwortlichkeiten**: Ohne eindeutige Zuständigkeiten entstehen Lücken, und wichtige Tests bleiben aus. Klar definierte Verantwortlichkeiten stellen sicher, dass alle wichtigen Aspekte geprüft werden.
- **Fokus auf kurzfristige Ergebnisse**: Tests und Reviews brauchen Zeit – sparen langfristig aber noch mehr. Teams, die nur schnelle Erfolge suchen, riskieren technische Schulden, die später teuer werden können.
- **Fehlende Teststrategie**: Die Entscheidung zwischen automatisierten und manuellen Tests braucht Struktur. Ein durchdachter Plan hilft, Ressourcen effizient einzusetzen und die Team-Effizienz zu steigern.

Unsere Erfahrung zeigt: Mit klaren Prozessen und einer gemeinsamen Qualitätsvision lässt sich jede dieser Herausforderungen meistern.

#### Warum effektives Qualitätsmanagement den Projekterfolg sichert

Qualitätsmanagement bedeutet nicht nur Fehlerbehebung – es verhindert ihr Entstehen. Dies garantiert, dass:

- **Software stabil und zuverlässig ist.** Durchdachte Tests und regelmäßige Code-Reviews stellen sicher, dass Änderungen die bestehende Funktionalität nicht beeinträchtigen.
- **Technische Schulden minimiert werden.** Die konsequente Einhaltung von Best Practices und automatisierte Qualitätskontrollen sichern langfristige Wartbarkeit.
- **Kunden und Nutzer Vertrauen aufbauen.** Zuverlässige, fehlerfreie Software steigert die Nutzerzufriedenheit und stärkt das Vertrauen ins Produkt.
- **Teams effizienter arbeiten können.** Strukturiertes Qualitätsmanagement reduziert Nacharbeit und schafft Raum für Innovation und Wachstum.

Erfolg in der Softwareentwicklung entsteht nicht von selbst. Projekte gelingen, wenn Qualität zur Entwicklungskultur wird. Mit durchdachten Prozessen, der richtigen Toolchain und klaren Verantwortlichkeiten schaffen wir stabile und zukunftssichere Software.


Effektives Qualitätsmanagement: Der Schlüssel zu nachhaltigem Projekterfolg


Am 09. Oktober 2024 wurde im Rahmen einer feierlichen Veranstaltung im Messequartier Dornbirn der KMU-Preis des Landes Vorarlberg 2024 verliehen. FORTIX wurde als Gewinner in der Kategorie Dienstleistung/Tourismus ausgezeichnet!
Eine 7-köpfige Jury hat die Gewinner in den Kategorien Handel, Dienstleistung/Tourismus und Gewerbe/Handwerk ausgewählt. Die Fortix GmbH konnte sich gegen starke Mitbewerber durchsetzen und den begehrten Preis entgegennehmen.

## Ein großes Dankeschön

Wir freuen uns sehr über diese Auszeichnung und bedanken uns bei allen, die uns auf unserem Weg begleitet haben.
Ein besonderer Dank gilt unseren Kunden, die uns ihr Vertrauen schenken und uns immer wieder herausfordern, innovative Lösungen zu entwickeln.

![Alle KMU-Preis 2024 Preisträger](/images/blog/kmu-preis-2024/kmu2024_preistraeger.webp)

### Der KMU-Preis Vorarlberg

Der KMU-Preis Vorarlberg wird jährlich durch eine Initiative der Vorarlberger Nachrichten und der Wirtschaftskammer Vorarlberg verliehen.
Der 16. KMU-Preis wurde in den Kategorien Handel, Dienstleistung/Tourismus und Gewerbe/Handwerk vergeben. Die diesjährigen Partner des KMU-Preises
waren Land Vorarlberg, Hypo Vorarlberg, Vorarlberger Landes-Versicherung und Autohaus Lins.

#### Weitere Links:

- [KMU-Magazin 2024](https://issuu.com/medienhaus.com/docs/kmu2024_journal/16)
- [Video KMU-Preis 2024](https://www.youtube.com/watch?v=GjK8EA-7qlM)

<small>Bilder © Vorarlberger Nachrichten</small>


Sieger KMU-Preis Vorarlberg 2024


In der Welt der Softwareentwicklung wird oft über technische Schulden gesprochen, häufig in einem negativen Kontext. Doch wie bei vielen Dingen im Leben gilt: Technische Schulden sind nicht per se schlecht. Tatsächlich können sie strategisch genutzt werden, um bestimmte Ziele zu erreichen. In diesem Blog möchte ich die Balance zwischen den Vorteilen und den Risiken technischer Schulden beleuchten und zeigen, wie ein bewusster Umgang mit ihnen die Produktentwicklung unterstützen kann.

#### Was sind Technische Schulden?

Der Begriff "Technical Debt" (Technische Schulden) wurde 1992 vom Softwareentwickler Ward Cunningham geprägt. Er verwendete diese Metapher, um zu beschreiben, wie kurzfristige Entscheidungen bei der Softwareentwicklung, die aus Zeitdruck oder Kompromissen resultieren, langfristige Nachbesserungen erforderlich machen können.

Technische Schulden entstehen, wenn bei der Entwicklung von Software bewusste Kompromisse eingegangen werden, um kurzfristig bestimmte Ziele zu erreichen. Diese Entscheidungen führen oft zu **zusätzlichen Nachbesserungen**, die nötig sind, weil die Entwicklung entweder schneller oder nachlässiger durchgeführt wurde. Dabei kann es sich um suboptimale Lösungen handeln, die es ermöglichen, eine Deadline zu erreichen oder eine schnelle Markteinführung zu realisieren.

#### Die Unterscheidung von Technischer Schuld nach Martin Fowler

Der bekannte Softwarearchitekt **Martin Fowler** hat das Konzept der technischen Schulden weiter differenziert, indem er sie in vier Kategorien unterteilt: **leichtsinnig** und **umsichtig** sowie **absichtlich** und **versehentlich**. Diese Unterscheidung hilft dabei, besser zu verstehen, wie technische Schulden entstehen und welche Herangehensweise dahinter steckt. Fowler teilt die technische Schuld in vier Quadranten auf, die je nach Bewusstsein und Absicht variieren.

**1. Leichtsinnig und versehentlich**

Diese Art von technischer Schuld entsteht, wenn Entscheidungen getroffen werden, ohne das notwendige Wissen oder Verständnis zu haben. Ein Beispiel hierfür wäre: "Was ist Layering?" – ein Zeichen dafür, dass die Entwickler grundlegende Prinzipien oder Best Practices nicht kennen. Hier resultieren die Schulden aus Unwissenheit und unüberlegtem Handeln.

**2. Leichtsinnig und absichtlich**

In diesem Fall weiß das Team, dass es eine schlechte Entscheidung trifft, wählt diesen Weg aber bewusst aus, oft aufgrund von Zeitdruck oder mangelnden Ressourcen. Ein klassisches Beispiel ist: "Wir haben keine Zeit für Design." Hier wird absichtlich auf Qualitätsstandards verzichtet, um schnell zu liefern, obwohl den Entwicklern die Konsequenzen klar sind.

**3. Umsichtig und absichtlich**

Diese Form der technischen Schuld entsteht, wenn man sich der Risiken und Konsequenzen bewusst ist, aber trotzdem eine informierte Entscheidung trifft, weil es unter den gegebenen Umständen notwendig ist. Ein typisches Szenario wäre: "Wir müssen jetzt das Produkt liefern und müssen mit den Problemen fürs Erste leben." Hier wird eine bewusste Risikoabwägung vorgenommen, um ein vorrangiges Ziel, wie eine rechtzeitige Markteinführung, zu erreichen.

**4. Umsichtig und versehentlich**

In dieser Kategorie entstehen technische Schulden aus Fehlern, die erst im Nachhinein als solche erkannt werden. Das Team hatte ursprünglich die besten Absichten und glaubte, eine gute Entscheidung getroffen zu haben, stellt aber später fest, dass es besser hätte gehen können. Ein Beispiel hierfür wäre: "Jetzt wissen wir, wie wir es hätten machen sollen." In diesem Fall wird aus den Fehlern gelernt, und künftige Projekte können davon profitieren.

![](/images/blog/technical-debt/technical-debt-dra-of-martin-fowler.png 'Darstellung der technischen Schulden nach Martin Fowler')

Diese Unterscheidung von Martin Fowler zeigt, dass nicht alle technischen Schulden gleich sind. Der Kontext und die Intention hinter den Entscheidungen spielen eine große Rolle, wenn es darum geht, wie kritisch diese Schulden bewertet werden sollten und wie man sie zukünftig vermeiden kann.

#### Technische Schulden sind nützlich, wenn...

- **Wichtige Deadlines erreicht werden müssen:** Es kann sinnvoll sein, bestimmte Qualitätsstandards zu senken, um ein Projekt termingerecht abzuschließen.

- **Die schnelle Markteinführung entscheidend ist:** In stark umkämpften Märkten zählt oft die Zeit. Ein Produkt kann schneller auf den Markt gebracht werden, auch wenn der Code nicht perfekt ist.

- **Ein MVP (Minimum Viable Product) gebaut wird:** Beim Start eines neuen Projekts ist es oft wichtiger, schnell Feedback vom Markt zu erhalten, als perfekten Code zu schreiben.

Doch auch wenn technische Schulden in diesen Fällen nützlich sein können, sollten sie so schnell wie möglich wieder abgebaut werden. Das bedeutet, dass nach der Erreichung kurzfristiger Ziele Zeit für Refactoring eingeplant werden sollte, um die entstandenen Schulden zu beseitigen.

#### Warum Technische Schulden nicht ignoriert werden sollten

Technische Schulden werden häufig als Synonym für schlechten Code verwendet. Es gibt jedoch einen wesentlichen Unterschied: Technische Schulden sind das bewusste Akzeptieren von Kompromissen in der Qualität zugunsten von kurzfristigen Zielen, während schlechter Code oft aus Nachlässigkeit oder fehlendem Know-how entsteht.

Technische Schulden können auf unterschiedliche Weise entstehen. Es ist wichtig, nicht nur die unmittelbaren Ursachen während der Entwicklungsphase zu betrachten, sondern auch die langfristigen Effekte, die durch das Nicht-Weiterentwickeln der Software auftreten können.

#### Technische Schulden während der Entwicklung

Technische Schulden entstehen oft direkt im Entwicklungsprozess, insbesondere wenn Teams unter starkem Zeitdruck stehen oder Anforderungen unklar formuliert sind. In solchen Situationen werden häufig Kompromisse bei der Codequalität eingegangen. Einige der häufigsten Ursachen sind:

- **Zeitdruck:** Wenn ein Projekt schnell fertiggestellt werden muss, wird häufig der saubere, durchdachte Code zugunsten von schneller umsetzbaren, aber weniger wartungsfreundlichen Lösungen vernachlässigt. Dies kann kurzfristig zu einem fertigen Produkt führen, erfordert aber in der Zukunft aufwendige Nachbesserungen.

- **Unklare Anforderungen:** Wenn die Anforderungen an ein Softwareprojekt nicht präzise definiert sind, besteht die Gefahr, dass Entwickler Lösungen umsetzen, die später überarbeitet werden müssen. Änderungen in den Anforderungen führen oft zu schnellen Anpassungen, die nicht optimal integriert sind und somit technische Schulden erzeugen.

- **Unzureichende Tests:** Wenn Tests nicht ausreichend oder gar nicht durchgeführt werden, steigt das Risiko von Bugs und Fehlfunktionen, die später behoben werden müssen. Dieser Mangel an Qualitätssicherung führt zu einem langfristigen Wartungsaufwand.

- **Schlechte Dokumentation:** Eine unvollständige oder unklare Dokumentation erschwert es den Entwicklern, den Code zu verstehen und zu pflegen. Dies führt zu Mehraufwand, wenn der Code später angepasst oder erweitert werden soll.

- **Unsauberer Code:** Suboptimale Code-Strukturen oder übermäßig komplexer Code, der schlecht lesbar oder wartbar ist, sind ein weiteres klassisches Beispiel für technische Schulden. Solche Codefragmente müssen in der Regel bei späteren Updates refactort oder gar neu geschrieben werden, um die Wartbarkeit und Erweiterbarkeit der Software zu gewährleisten.

#### Technische Schulden durch Nicht-Entwicklung

Technische Schulden entstehen nicht nur aktiv während der Entwicklung, sondern können sich auch durch das **Nicht-Weiterentwickeln** der Software anhäufen. Software, die nicht regelmäßig gepflegt wird, gerät oft technisch ins Hintertreffen. Diese „unsichtbaren“ technischen Schulden können genauso schwerwiegende Auswirkungen haben wie die Schulden, die durch aktive Entwicklung entstehen:

- **Technologischer Wandel:** Technologien und Best Practices in der Softwareentwicklung ändern sich stetig. Neue Programmiersprachen, Tools oder Frameworks bieten oft effizientere oder sicherere Möglichkeiten, Software zu entwickeln. Wird eine bestehende Software nicht regelmäßig modernisiert oder angepasst, entsteht eine Diskrepanz zwischen dem aktuellen Stand der Technik und der eingesetzten Technologie, was die zukünftige Wartung und Erweiterung erheblich erschweren kann.

- **Veraltete Bibliotheken und Frameworks:** Bibliotheken und Frameworks werden regelmäßig aktualisiert, um neue Funktionen zu integrieren, Sicherheitslücken zu schließen oder die Performance zu verbessern. Wenn eine Software auf veralteten Abhängigkeiten aufbaut und diese nicht regelmäßig aktualisiert werden, kann das zu Inkompatibilitäten, Sicherheitsrisiken oder eingeschränkter Funktionalität führen. Das Nachziehen dieser Updates kann dann aufwendiger und risikoreicher werden, je länger es hinausgezögert wird.

- **Neue Architekturkonzepte:** In der Softwarearchitektur entstehen immer wieder neue Paradigmen und Designmuster, die es erlauben, Systeme skalierbarer, robuster oder leichter wartbar zu gestalten. Unternehmen, die ihre Architektur nicht an diese neuen Konzepte anpassen, könnten langfristig darunter leiden, dass ihre Software schwerer erweiterbar oder weniger effizient ist. Auch das Ignorieren dieser Fortschritte kann technische Schulden akkumulieren, die später aufwändig beseitigt werden müssen.

Diese Art von technischen Schulden, die sich durch Nicht-Weiterentwicklung ansammeln, sind oft schwer zu erkennen, da sie nicht sofort sichtbar sind. Dennoch sind sie genauso kritisch, da sie die Flexibilität und Zukunftsfähigkeit der Software beeinträchtigen.

#### Wie technische Schulden abgebaut werden können

Technische Schulden müssen ernst genommen und strategisch angegangen werden, um langfristig eine stabile Codebasis zu gewährleisten. Hier sind einige Wege, um technische Schulden zu verringern:

- **Bewusster Umgang mit technischen Schulden** Technische Schulden sollten dokumentiert und überwacht werden. Es ist wichtig, stets im Auge zu behalten, wo und warum sie entstehen.

- **Feedback von Entwicklern einholen** Die Entwickler wissen am besten, wo sich technische Schulden verbergen. Regelmäßige Team-Meetings können helfen, diese Schulden zu identifizieren.

- **Automatisierte Tests und Tools verwenden** Tools wie [SonarQube](https://www.sonarsource.com/products/sonarqube/) können dabei helfen, technische Schulden zu visualisieren und die Codequalität zu verbessern.

- **Refactoring-Zeit einplanen** Es sollte in jedem Sprint Zeit für Aufräumarbeiten (Refactoring) eingeplant werden, um technische Schulden kontinuierlich abzubauen.

#### Das Projektmanagement von der Wichtigkeit überzeugen

Eine der größten Herausforderungen beim Umgang mit technischen Schulden ist, das Projektmanagement davon zu überzeugen, dass ihre Beseitigung wichtig ist. Hier ist es entscheidend, die **Ziele des Unternehmens** mit der Notwendigkeit des Abbaus technischer Schulden in Einklang zu bringen.

Drei Argumente können helfen, das Projektmanagement zu überzeugen:

- **Zahlen sprechen lassen:** Konkrete Metriken, die die negativen Auswirkungen technischer Schulden auf die Produktivität zeigen, sind oft das beste Argument.

- **Langfristige Probleme aufzeigen:** Technische Schulden, die nicht behoben werden, verschlimmern sich über die Zeit und können zukünftige Projekte erheblich verlangsamen.

- **Risikomanagement:** Der Aufbau technischer Schulden ist vergleichbar mit einem wachsenden Risiko. Je länger sie ignoriert werden, desto schwieriger und teurer wird ihre Beseitigung.

#### Fazit

Technische Schulden sind ein unvermeidlicher Teil der Softwareentwicklung. Sie können, wenn sie bewusst eingesetzt werden, sogar ein wertvolles Werkzeug sein, um schnelle Ergebnisse zu erzielen. Wichtig ist jedoch, dass sie stets im Auge behalten und so schnell wie möglich abgebaut werden, um langfristige Stabilität zu gewährleisten. Ein transparenter und geplanter Umgang mit technischen Schulden hilft dabei, die Balance zwischen Entwicklungsgeschwindigkeit und Codequalität zu wahren.

#### Links

- [Martin Fowler Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html)
- [Martin Fowler Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)
- [LeadDev Technical Debt](https://leaddev.com/tech/tech-debt-engineering-leaders-how-shortcut-today-impacts-tomorrow?utm_source=tldrwebdev)
- [Engineering Leadership Technical Debt](https://newsletter.eng-leadership.com/p/engineers-guide-to-convincing-your?utm_source=tldrwebdev)
- [DevBoost Der richtige Umgang mit technischen Schulden](https://devboost.com/blog/tipps-fuer-den-richtigen-umgang-mit-technischen-schulden?utm_source=9-3)


UUID Versionen: Welche gibt es und wann sollte ich welche verwenden?

Effektives Qualitätsmanagement: Der Schlüssel zu nachhaltigem Projekterfolg

Sieger KMU-Preis Vorarlberg 2024

Technische Schulden: Fluch oder Segen für die Softwareentwicklung?