Das Navigationssystem schickte sie über Zagreb in Kroatien, und anscheinend war sie so beschäftigt, dass selbst mehrere Tankstopps sie nicht darauf aufmerksam machten, dass etwas nicht in Ordnung sein könnte. Sie überquerte fünf Grenzen und sah Verkehrsschilder in verschiedenen Sprachen. Die Leute an den Tankstellen, an denen sie anhielt, sprachen nicht ihre Sprache. Die Namen der Städte und Orte waren ihr nicht vertraut. Dennoch zweifelte sie nicht an ihrem Navigationssystem, bis sie zwei Tage später feststellte, dass sie vielleicht gar nicht mehr in Belgien war.
Es ist verlockend, sich über das blinde Vertrauen dieser Frau in ihr Navigationssystem lustig zu machen. Aber immerhin hatte sie ein Hilfsmittel, das ihr half, auf Kurs zu bleiben. Ihr einziger Fehler war, dass sie nicht überprüft hat, ob dieser Kurs tatsächlich der richtige ist. Viele Softwareentwicklungsprojekte starten ohne definierten Kurs oder gar ein definiertes Ziel. Manche Teams entwickeln Software und setzen sie ohne Tests und ohne Überwachung auf Anwendungs- oder Systemebene in die Produktion ein. Wenn Fehler auftreten, haben sie keinen Anhaltspunkt, was die Ursache ist. Nicht, dass das eine Rolle spielen würde, weil sie wahrscheinlich sowieso keinen Prozess definiert haben, in dem sie mit den Fehlern umgehen können.
Nur zu überprüfen, wie schnell du vorankommst, indem du zum Beispiel die Geschwindigkeit deines Teams mit Burndown-Charts misst, reicht nicht aus, wenn du sicherstellen willst, dass du dein Ziel erreichst. Mit einer höheren Geschwindigkeit in die falsche Richtung zu gehen, ist schlimmer als mit einer niedrigeren Geschwindigkeit in die richtige Richtung zu gehen. Wenn du deine Software nicht im Blindflug entwickeln willst, musst du ständig sicherstellen, dass du noch auf Kurs bist. Akzeptanztests sagen dir, dass du das richtige Produkt baust, indem sie sicherstellen, dass die Software das tut, was sie tun soll. Unit Tests sagen dir, dass du das richtige Produkt baust, indem sie sicherstellen, dass der Code korrekt funktioniert. Softwaremetriken liefern dir die nötige Telemetrie, um bei der erstbesten Gelegenheit zu erkennen, wann du in technische Schulden gerätst.
Die Architektur einer Software wird durch ihre Qualitätsziele definiert. Diese Ziele werden gemeinhin als die nicht-funktionalen Anforderungen der Software bezeichnet. Sie beinhalten, sind aber nicht beschränkt auf Funktionalität, Benutzerfreundlichkeit, Zuverlässigkeit, Leistung und Supportfähigkeit. Diese Aspekte der Softwarequalität sind für den Endanwender greifbar und machen die externe Qualität eines Softwareprodukts aus. Die interne Qualität von Software hingegen ist für den Endbenutzer praktisch nicht wahrnehmbar. Aber Aspekte der internen Softwarequalität wie lesbarer Code, der einfach zu verstehen, anzupassen und zu erweitern ist, sind für dich als Entwickler von entscheidender Bedeutung. Ist die interne Qualität der Software gering, wird die Umsetzung zukünftiger Änderungswünsche mit der Zeit immer schwieriger und damit teurer. Die Gefahr wird mit der Zeit immer größer, dass selbst kleine Änderungen an der Software unerwartete Nebeneffekte haben. Es ist für jedes Softwareprojekt entscheidend, nicht nur Qualitätskriterien zu definieren, einschließlich der externen Qualität, sondern auch ein vernünftiges Maß an interner Qualität zu fordern.
Ward Cunninghams Metapher der technischen Schulden ist von unschätzbarem Wert, um allen Beteiligten eines Softwareprojekts die Kosten einer niedrigen internen Qualität transparent zu machen. Sie vergleicht schlechten Code mit einem Kredit, für den Zinsen fällig werden. Ein Kredit kann eine gute Idee sein, wenn er dem Projekt hilft, ein Produkt schnell auszuliefern. Wenn der Kredit aber nicht durch Refactoring der Code-Basis und damit Verbesserung der internen Qualität zurückgezahlt wird, türmen sich mit der Zeit erhebliche Mehrkosten in Form von Zinsen auf. Irgendwann reduzieren die Zinszahlungen den finanziellen Spielraum, bis man schließlich Konkurs anmelden muss. Bezogen auf die Softwareentwicklung bedeutet das, dass die Wartung der Software wirtschaftlich nicht mehr sinnvoll ist.
Die Hauptziele der Qualitätssicherung sind, dass die Qualitätsziele der Software erreicht werden, dass die Kosten und der Nutzen der internen Qualität für alle Beteiligten transparent gemacht werden und dass du als Entwickler nicht vom Design abweichst, das durch die Architektur vorgegeben ist. Die Sicherung der Qualität darf kein nachträglicher Gedanke sein. Es ist ein Prozess, der am Anfang der Softwareentwicklung beginnt und nicht mit dem Einsatz der (ersten Version der) Software in der Produktion enden darf.