Damit nicht nur der individuelle Entwickler, das beteiligte Entwicklungsteam oder das betroffene Unternehmen aus der Projekterfahrung lernen kann, sondern auch unsere Industrie als Ganzes, bedarf es einer öffentlichen Diskussion von IT-Projekten. Dies ist jedoch die Ausnahme und passiert viel zu selten. Beispielsweise dann, wenn eine 655 Millionen US-Dollar teure Raumsonde verloren geht. Oder wenn eine Fortune 500 Company (Hertz) eine andere Fortune 500 Company (Accenture) wegen eines gescheiterten IT-Projektes verklagt.
Die Mars Climate Orbiter (MCO) Mission der NASA ist ein Beispiel für ein IT-Projekt, dessen Scheitern gut dokumentiert ist. Hierbei ging eine Sonde, die das Klima des Planeten Mars erforschen sollte, am 23. September 1999 aufgrund eines Einheitenfehlers im Navigationssystem verloren. Nur eine Woche später, am 30. September 1999, machte die NASA die Fehlerursache öffentlich: Ein Teil des Teams hatte mit Inches, Feet und Pounds gerechnet während der Rest des Teams mit metrischen Einheiten gerechnet hatte. Bemerkenswert ist diese Aussage:
The problem here was not the error, it was the failure of NASA's systems engineering, and the checks and balances in our processes to detect the error.
Der technische Fehler, der zum Verlust der Sonde führte, wird also nicht als zugrunde liegende Ursache angesehen, sondern als Folgefehler von Unzulänglichkeiten im Entwicklungsprozess: zu wenig Kommunikation zwischen den Teams und fehlende Integrationstests.
Im Oktober 2018 verunglückte ein Flugzeug des Typs Boeing 737 MAX 8 kurz nach dem Start in Indonesien (Lion Air Flug 610). Im März 2019 stürzte ein Flugzeug desselben Typs ebenfalls nur Minuten nach dem Start in Äthiopien ab (Ethiopian Airlines Flug 302). In beiden Fällen kamen alle Menschen an Bord ums Leben. In beiden Fällen war Software, das Maneuvering Characteristics Augmentation System (MCAS), die Ursache für den Absturz.
Robert C. Martin, Softwareentwicklern als „Uncle Bob“ und Autor von „Clean Code“ bekannt, hat in einem Artikel analysiert, was über die Softwareprobleme des MCAS der Boeing 737 MAX 8 bekannt ist. Seine Perspektive ist hierbei nicht auf die eines Experten für Softwareentwicklung beschränkt. Als Pilot kennt er auch den Kontext, in dem die fragliche Software operiert. So weit bekannt ist, wurden der MCAS-Software in beiden Fällen fehlerhafte Daten von einem Anstellwinkel-Sensor geliefert. Auf Basis dieser Daten entriss das MCAS daraufhin den Piloten die Kontrolle über das Flugzeug. Die Software verließ sich auf die Daten dieses Sensors, ohne sie mit anderen Daten wie Fluggeschwindigkeit, Vertikalgeschwindigkeit, Flughöhe, abzugleichen. Oder mit den Daten eines weiteren Anstellwinkel-Sensors. Ein solcher Cross-Check der Daten geht einem Piloten bei der Ausbildung für den Instrumentenflug in Fleisch und Blut über. Schließlich kann ein Instrument so ausfallen, dass der Ausfall nicht direkt zu bemerken ist. In seinem Artikel stellt Robert C. Martin die Frage, warum die Softwareentwickler diese grundlegenden Prinzipien der Luftfahrt nicht berücksichtigten.
Im April 2019 sorgte die Klage der US-amerikanischen Autovermietung Hertz gegen ihren IT-Dienstleister Accenture für Aufsehen. Die öffentlich gewordene Klageschrift enthält viele Details, die tiefe Einblicke in ein gescheitertes IT-Projekt gewähren.
Im August 2016 erteilte Hertz Accenture den Auftrag, eine neue Online-Präsenz zu entwickeln. Diese sollte im Dezember 2017 in Produktion gehen. Diese erste Deadline wurde ebenso verfehlt wie eine zweite (Januar 2018) sowie eine dritte (April 2018). Hertz verklagt Accenture nun auf 32 Millionen US-Dollar an bereits gezahltem Honorar sowie weitere Millionen, die benötigt werden, um das von Accenture hinterlassene Chaos aufzuräumen. Laut Hertz hat Accenture weder eine funktionierende App noch eine funktionierende Webseite geliefert. Obwohl von Hertz eine Lösung gefordert war, die zum einen auch für die Marken Dollar und Thrifty sowie zum anderen auch in Märkten außerhalb Nordamerikas eingesetzten werden kann, entwickelte Accenture eine Software, die nur für die Marke Hertz und nur in Nordamerika verwendet werden konnte. Also hätte verwendet werden können, so sie denn fertiggestellt worden wäre.
Es mag verlockend sein, Schadenfreude darüber zu empfinden, dass auch große Firmen wie Hertz und Accenture ein Projekt in den Sand setzen können. Aber das einzige, was das Scheitern dieses Projektes besonders macht, ist die Tatsache, dass zum einen sehr viel falsch gelaufen ist und zum anderen all das durch eine Klage ans Licht der Öffentlichkeit gelangt.
Accenture hat die entwickelte Software nicht getestet, zumindest weder gründlich noch rechtzeitig. Die Klageschrift kann so gelesen werden, dass weder automatisierte Tests im Allgemeinen noch Test-Driven Development im Besonderen zum Einsatz kamen. Die fehlenden automatisierten Tests wird man nachträglich nicht implementieren können, weil nicht klar genug ist, wozu der Code eigentlich existiert. Warum nicht klar sein sollte, warum der zu testende Code eigentlich existiert? Das lässt sich zwischen den Zeilen der Beschreibung von anderen Projektproblemen herauslesen. Beispielsweise waren die Accenture-Entwickler nicht in der Lage, den Backend-Code (Java) fehlerfrei, performant und sicher mit dem Frontend-Code (Angular) zu integrieren.
Es wäre wohlfeil und würde zu kurz greifen, würde man die Ursache für das Scheitern des Projektes nur bei Accenture suchen. Hertz hatte kein eigenes Entwicklungsteam, welches das Projekt im eigenen Haus hätte umsetzen können, weil man alle Entwickler Anfang 2016 entlassen hat . Für ein erfolgreiches Gelingen des Projekts hätte zumindest die Rolle des „Product Owner“, um einen Begriff aus der Scrum-Welt zu bemühen, inhouse besetzt werden müssen. Da dies nicht passierte, lag die Verantwortung dafür, welche Anforderungen im Product-Backlog stehen in welcher Reihenfolge diese abgearbeitet werden, nicht in der Hand des Auftraggebers, sondern beim Dienstleister. Die hieraus resultierende schlechte Kommunikation zwischen Hertz und Accenture dürfte eine der Hauptursachen für das Scheitern des Projektes gewesen sein. Und egal, ob Hertz das gefordert hat oder nicht, Accenture hat sich auf ein Go-Live-Datum committed. Anstelle des geplanten Big Bang!-Deployment, das nie passiert ist, wäre es sinnvoll gewesen, in kurzen Iterationen, Use Case für Use Case nicht nur zu implementieren, sondern auch kontinuierlich auszurollen.
Moderne Entwicklungsprozesse sehen Retrospektiven und Post-Mortems vor, um aus den eigenen Fehlern zu lernen. Diese helfen den individuellen Entwicklern, den einzelnen Teams sowie dem gesamten Unternehmen dabei, besser zu werden. Ich finde es lobenswert, wenn Unternehmen ihre „post-incident analysis“, beispielsweise im Firmenblog, öffentlich machen, wenn etwas bei ihnen passiert ist. Als Beispiele seien hier GitHub und Travis genannt. Das gibt anderen die Möglichkeit, aus den Fehlern anderer zu lernen.
Natürlich kann man auch aus Dingen lernen, die gut in einem Projekt gelaufen sind. Ich schaue mir beispielsweise gerne Videos der „Classic Game Post-Mortem“ Vorträge von der Game Developers Conference an. Da lerne ich nicht nur etwas über Spiele wie Maniac Mansion oder Civilization, die ich als Kind auf dem Amiga gespielt habe. Oder darüber, wie die Entwickler mit trickreicher Programmierung die Hardware-Limitierungen der damaligen Computer ausgereizt haben. Sondern auch wie zu der Zeit Software entwickelt wurde, wie Projekte verwaltet wurden (oder auch nicht), et cetera. Da bin ich hinterher immer froh, dass Software heute anders entwickelt wird.
Das Chrysler Comprehensive Compensation System (C3-Projekt) ist ein Beispiel für ein IT-Projekt, aus dem viel Gutes entstanden ist. Zu Beginn der 1990er Jahre beschloss der US-amerikanische Automobilhersteller Chrysler, eine neue Software für die Lohn- und Gehaltsabrechnung von 87.000 Angestellten zu entwickeln. Die Entwicklung (in SmallTalk) begann im Jahr 1994. Zwei Jahre später, die Software hatte noch keine einzige Lohn- oder Gehaltsabrechnung durchgeführt, engagierte man Kent Beck, um das Projekt zu retten. Dieser wiederum holte Ron Jeffries an Bord. Im März 1996 schätzte das Team, dass die Software gut ein Jahr später einsatzbereit sein würde. Das C3-Projekt ging in die Geschichte der Softwareentwicklung ein, weil sich das Team 1997 entschloss, die Art, wie es arbeitet, zu ändern. Diese neue Art, zu arbeiten, wurde später unter dem Namen „Extreme Programming“ bekannt. Die Schätzung, dass die Software binnen eines Jahres einsatzbereit sein würde, erwies sich als fast zutreffend. Mit nur wenigen Monaten Verspätung (aufgrund von einigen wenigen unklaren Anforderungen) ging eine erste Version, mit der monatliche Lohn- und Gehaltsabrechnungen für 10.000 Mitarbeiter abgewickelt wurden, in Betrieb. Die von Kent Beck, Ron Jeffries und ihrem Team angewandten Praktiken wie Test First-Programmierung, Pair Programmierung oder engere Einbeziehung des Kunden, insbesondere in Verbindung mit kurzen Feedbackzyklen, die im C3-Projekt erfolgreich ausprobiert und in dessen Nachgang formalisiert und popularisiert wurden, haben die Art, wie wir alle Software entwickeln, nachhaltig verändert.
Erfolgreich Software zu entwickeln bedeutet, zielgerichtet vorzugehen. Diese Ziele sollten sich aus mit dem Business abgestimmten Akzeptanzkriterien ergeben. Ohne eine klare Vorgabe von Zielen (im Sinne von Tasks) läuft der Entwickler Gefahr, sich bei der Arbeit zu verlieren. Er weiß insbesondere nicht, wann er mit einem Task fertig ist. Es bietet sich an, Akzeptanzkriterien durch automatisierte Tests zu dokumentieren und zu überprüfen. So oder so müssen die Ziele definiert werden, bevor Produktionscode geschrieben wird. Das ist testgetriebene Entwicklung, egal ob man es so nennen will oder nicht.
Die Hauptaufgabe eines Entwicklers ist nicht das Schreiben von Code, sondern das Verstehen eines Problems. In seinem Artikel über die MCAS-Software der Boeing 737 MAX 8 formuliert Robert C. Martin das so:
Programmers must not be treated as requirement robots. Rather, programmers must have intimate knowledge of the domain they are programming in.
Ein Entwickler kann nur dann sinnvoll arbeiten, wenn er die Domäne versteht, in der das Unternehmen, für das er Software entwickelt, agiert. Meiner Erfahrung nach funktionieren IT-Projekte dann schlecht, wenn „das Business“ mit der „Kostenstelle IT“ nur über Tickets kommuniziert, und zwar ohne Kontext, warum etwas geändert oder umgesetzt werden soll. Und IT-Projekte funktionieren meiner Erfahrung nach dann gut, wenn die Softwareentwickler verstehen, wie das Unternehmen funktioniert und wie eine Änderung zum Unternehmenserfolg beitragen kann. Das gelingt, wenn allen Beteiligten klar ist, dass Softwareentwicklung mehr Mensch-Mensch-Kommunikation als Mensch-Maschine-Kommunikation ist.