Aus Softwarefehlern lernen – Teil 1: Einheiten. Wenn Zahlen irreführend werden

Wenn Softwarefehler auftreten, passiert das meistens unbemerkt und unauffällig, gelegentlich aber auch höchst spektakulär und kostspielig. Von fehlgeschlagenen Raumfahrtmissionen über Börsencrashs bis hin zu fehlerhaften medizinischen Geräten gibt es eine lange Liste berühmter Softwarepannen. Wer sie studiert, stellt schnell fest: Die meisten dieser Fehler wirken auf den ersten Blick wie einmalige Katastrophen, sind in Wahrheit aber Wiederholungen bekannter Muster.

Diese Artikelserie stellt neun dieser typischen Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Der Bug in der Rechenanlage

Eine der beliebtesten Anekdoten der Softwaregeschichte ist die von Grace Hopper und der berühmten Motte. 1947 arbeitete Grace Hopper an der Harvard-Mark-II-Rechenanlage, in der sich eine echte Motte in einem Relais verfangen hatte. Nachdem ein Teammitglied sie gefunden und entfernt hatte, klebte dieser sie mit dem Kommentar „first actual case of bug being found“ ins Protokollbuch. Dieses Protokollbuch wird heute in einem Smithsonian Museum in Washington ausgestellt.

Diese Episode ist zu einer Legende der IT-Kultur geworden – das Wort „Bug“ wurde damals aber nicht erfunden. Schon Thomas Edison sprach 1878 in Briefen über „Bugs“ in Maschinen, also kleine, schwer zu findende Fehler. Trotzdem prägte Grace Hopper die Vorstellung, dass Softwarefehler etwas sind, das man wie ein Insekt finden und entfernen kann.

Doch die Realität ist oft subtiler: Bugs sind meist Symptome systematischer Schwächen. Hinter fast jeder spektakulären Panne steckt ein Muster, das sich in abgewandelter Form immer und immer wieder findet. Deshalb lohnt sich ein Blick nicht nur auf die einzelnen Vorfälle, sondern vor allem auf die Fehlerkategorien, die sie repräsentieren.

Teil 1: Einheiten und Maße: Wenn Zahlen irreführend werden

Am Beginn dieser Serie steht ein Thema, mit dem Entwicklerinnen und Entwickler jeden Tag wie selbstverständlich hantieren – und das vielleicht gerade deshalb so gefährlich ist. Es wird allzu leicht unterschätzt: Die Rede ist vom Umgang mit Zahlen.

Kaum ein Beispiel für Softwarefehler wird so häufig genannt wie der Verlust der NASA-Sonde Mars Climate Orbiter im Jahr 1999. Ziel der Mission war es, die Marsatmosphäre zu untersuchen. Nach einer monatelangen Reise näherte sich die Sonde dem Planeten – und verglühte. Die Ursache war fast grotesk simpel: Die Entwickler hatten in der Software metrische und imperiale Maßeinheiten verwechselt. Das Ergebnis war ein systematischer Navigationsfehler, der die Sonde auf eine zu niedrige Umlaufbahn führte.

Dieser Vorfall zeigt, dass Zahlen ohne Kontext gefährlich sind. Eine Zahl wie 350 kann das Maß einer Geschwindigkeit, einer Kraft oder einer Energie bedeuten – oder eben etwas ganz anderes. Solange eine Software Daten als rohe Zahlen behandelt, besteht die Gefahr, dass jemand sie falsch missinterpretiert. In großen Projekten mit mehreren Teams potenziert sich dieses Risiko, wenn jede Seite implizite Annahmen trifft, die niemand irgendwo explizit dokumentiert oder technisch abgesichert hat.

Aus Sicht der Qualitätssicherung sind solche Fehler besonders tückisch, denn Unit Tests können ebenso wie Integrationstests durchaus korrekt durchlaufen – solange die falschen Einheiten konsistent falsch sind. Das Problem zeigt sich oft erst in der Realität, wenn Sensoren, Aktoren oder externe Systeme ins Spiel kommen, deren Daten den zuvor getroffenen Annahmen nicht entsprechen. Die Lehre aus diesem Vorfall ist klar: Zahlen brauchen Bedeutung. Moderne Programmiersprachen und Frameworks bieten verschiedene Möglichkeiten, diese Bedeutung explizit zu machen:

• Value Objects oder Wrapper-Typen: Statt double oder float kommt ein eigener Typ wie ForceInNewton oder VelocityInMetersPerSecond zum Einsatz. Damit wird die Einheit Teil der Typinformation. Manche Programmiersprachen, beispielsweise F#, bieten Unterstützung für Einheiten sogar bereits als Teil der Sprache an.
• Bibliotheken für physikalische Einheiten: Sie ermöglichen automatische Umrechnungen und erzwingen korrekte Kombinationen.
• Schnittstellenverträge und End-to-End-Tests: API-Definitionen sollten Einheiten benennen. Tests mit echten Daten decken Diskrepanzen auf, bevor sie zu Katastrophen führen.

Neben diesen technischen Maßnahmen spielt außerdem auch die Teamkultur eine große Rolle. Projekte, die früh auf eine gemeinsame Sprache für ihre Daten achten – sei es durch Domain-Driven Design (DDD) oder einfach durch konsequente Dokumentation –, vermeiden solche Fehler deutlich häufiger.

Der Verlust des Mars Climate Orbiter hat die NASA hart getroffen. Doch er hat auch dazu geführt, dass Entwicklerinnen und Entwickler zumindest in manchen Projekten stärker auf Einheitenfehler achten und diese Fehlerklasse seither (hoffentlich) ernster nehmen. Für Softwareteams im Alltag gilt dasselbe: Wer Zahlen ohne Kontext weitergibt, lädt zum nächsten Bug geradezu ein.

Im nächsten Teil lesen Sie: Überlauf, Arithmetik und Präzision: Wenn Zahlen kippen

(who)