1999 war bekanntlich das Jahr des Y2K-Bugs, als man befürchtete, dass der Jahreswechsel computergestützte Systeme reihenweise zum Absturz bringen würde, mit teils fatalen Folgen. Es kam zum Glück nicht so schlimm – auch, weil rechtzeitig Maßnahmen ergriffen worden waren.

Heute spielt Software eine noch viel größere Rolle, auch in kritischen Bereichen wie dem Flug- und Autoverkehr, Krankenhäusern und Kraftwerken. Sie sind durch Software leistungsfähiger, schneller und sicherer geworden. Gleichzeitig sind aber neue Risiken entstanden, gegen die die Y2K-Ängste lächerlich aussehen. Das liegt auch daran, dass selbst einzelne Fahrassistenten in Autos von Millionen Zeilen Code gesteuert werden, die keiner mehr überblickt und in denen sich die Suche nach Wechselwirkungen mit anderen Systemen extrem schwierig gestaltet. Der faszinierende wie beunruhigende Atlantic-Longread erinnert daran, wie leicht wir unterschätzen, was Softwareprobleme auslösen können – selbst ohne dass Hacker ihre Finger im Spiel haben:

„More and more, critical systems that were once controlled mechanically, or by people, are coming to depend on code. This was perhaps never clearer than in the summer of 2015, when on a single day, United Airlines grounded its fleet because of a problem with its departure-management system; trading was suspended on the New York Stock Exchange after an upgrade; the front page of The Wall Street Journal’s website crashed; and Seattle’s 911 system went down again, this time because a different router failed. The simultaneous failure of so many software systems smelled at first of a coordinated cyberattack. Almost more frightening was the realization, late in the day, that it was just a coincidence.“

Der Artikel beschreibt aber auch, was nötig ist, um die „Software-Apokalypse“ zu verhindern. Er lässt dabei eine Menge kluger Köpfe zu Wort kommen, die mit ihrer Arbeit unser Verständnis vom Programmieren und die Art und Weise, wie Software entsteht, radikal in Frage stellen.