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 zumindest 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 haben zu Beginn keinen 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, da sie wahrscheinlich sowieso keinen Prozess definiert haben, in dem sie mit den Fehlern umgehen können.
Nur zu überprüfen, wie schnell Sie vorankommen, indem Sie beispielsweise die Geschwindigkeit Ihres Teams mit Burndown-Charts messen, reicht nicht aus, wenn Sie sicherstellen wollen, dass Sie Ihr Ziel erreichen. 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 Sie Ihre Software nicht im Blindflug entwickeln wollen, müssen Sie ständig sicherstellen, dass Sie noch auf Kurs sind. Akzeptanztests sagen Ihnen, dass Sie das richtige Produkt bauen, indem sie sicherstellen, dass die Software das tut, was sie tun soll. Unit Tests sagen Ihnen, dass Sie das richtige Produkt bauen, indem sie sicherstellen, dass der Code korrekt funktioniert. Softwaremetriken liefern Ihnen die nötige Telemetrie, um bei der erstbesten Gelegenheit zu erkennen, wann Sie in technische Schulden geraten.
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 die 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 dies, 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 die Entwickler nicht vom Design abweichen, 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.