Enterprise Software
Was haben wir falsch gemacht?
Enterprise Software
Während ich diesen Artikel schreibe, bereite ich mich darauf vor, zu einer Konferenz über Software-Tests in Melbourne zu düsen. Bedenkt man die prekäre Lage moderner Software, wäre es schön, wenn mehr Leute solche Konferenzen besuchten, aber man muss mit kleinen Schritten beginnen.
Dieses Thema wurde unlängst in der Presse ausgiebig diskutiert, weil überall neue Initiativen auftauchen: Das Jericho Forum in Großbritannien, der Global Council of CSOs in den USA, das US-Energieministerium, das seine Macht als Einkäufer nutzt, um Oracle zu überzeugen, 9i zu verstärken, Warnungen vor dem Internet Explorer, und so weiter.
Es mag zwar ganz nett sein mitzubekommen, dass die Leute anfangen, sich wegen so etwas Sorgen zu machen, aber weshalb haben sie so lange gebraucht? Die Qualität der meisten Software war so erbärmlich, dass sie keine wirkliche Vorstellung davon haben, wie es ist, wenn ein Produkt pünktlich ausgeliefert wird, leicht zu bedienen ist, einfache Umgangssprache unterstützt und beim ersten Mal funktioniert, und das alles jedes Mal.
Der Punkt ist, dass sich viele und vielleicht sogar die meisten der Fehler, die wir mit Software-Systemen erleben, mit Hilfe von Techniken hätten vermeiden lassen, mit denen wir bereits vertraut sind.
Sie sollten Ausreden nicht akzeptieren wie “wir benötigen ein Upgrade” oder “die User haben das Handbuch nicht gelesen” (das sowieso in Klingonesisch verfasst zu sein scheint) oder “wir benutzen alte Technologie” oder was auch immer in dieser Woche aktuell ist. Die brutale Wahrheit ist, dass wie Software-Entwickler nicht darauf trainieren, Ingenieure zu sein – also sollten wir sie auch nicht so nennen.
Software-Tester haben in ihren Unternehmen oft den selben Status wie die Bürokatze; Anforderungen sind nicht definiert oder optional oder gelten als völlig überflüssig, Deadlines werden von Nadeln im Kalender bestimmt, und Projektplanung und verfolgung ist etwas, was andere Leute tun. Ich nehme an, dass einige Leser hiervon geschockt sind, aber das ist eine faire Zusammenfassung der Resultate der Studien, die in letzter Zeit weltweit erschienen sind.
Selbst wenn wir Geld wie Heu haben, wird es offenbar nicht einfacher. Nehmen wir zum Beispiel den F/22 Raptor, das neueste und größte Kampfflugzeug der USA. Laut Washington Post haben die Testpiloten im Jahr 2003 auf jedem Flug 14 Minuten mit dem Rebooten kritischer Systeme zugebracht – inzwischen sind es “nur noch” 36 Sekunden pro Flug. Na, das ist ja eine Erleichterung. Wir reden übrigens über die Steuersysteme von Geschossen.
Werden wir angesichts dessen, dass wir darüber reden, auch handeln? Nun, jede Kleinigkeit ist hilfreich. Ich werde gemeinsam mit der University of Kingston ab diesem Monat mit der Einrichtung eines neuen Zentrums für forensisches Software-Engineering beginnen. Es wird mit bereits arbeitenden Gruppen in Middlesex (spezialisiert auf Projektausfälle) und Glasgow zusammenarbeiten. Das Thema ist simpel: Findet heraus, was versagt hat und wie man vermeiden kann, dass das noch einmal passiert.
Wenn eine Brücke einstürzt, geben wir uns große Mühe herauszufinden, weshalb, und verbreiten diese Information. Wenn Software versagt, fluchen wir und machen einen Neustart, mit dem wir alle Beweise löschen. Laut Royal Academy of Engineering werden allein in Großbritannien mehrere Milliarden Euro pro Jahr durch Software-Fehler verschwendet.
In Verschwendung waren wir Europäer schon immer gut, und die Amerikaner haben es uns nachgemacht. Hoffentlich ändert sich das.