Programmierfehler
Anfang der 2000er Jahre beteiligte ich mich als externer Berater an einem umfangreichen Projekt bei einem großen süddeutschen Autohersteller. Dort war ich verantwortlich für die Integration einer fortschrittlichen Computerlinguistiksoftware in ein bestehendes Dokumentationssystem. Die Sotware bestand bereits aus Hunderttausenden Codezeilen von verschiedenen Autoren. [2]
1997 schlug der IBM-Rechner Deep Blue den amtierenden Schachweltmeister Garri Kasparow. … Im zweiten von sechs Spielen machte Deep Blue einen vollkommen unberechenbaren, für einen Computer untypischen Zug. Er opferte ohne Not eine Figur. Kasparow verwirrte das dermaßen, dass es ihn den Sieg kostete. Er hat den Zug seines Computer-Gegners offenbar überbewertet und glaubte, dass Deep Blue ein kreativ-menschliches Verhalten an den Tag legte. Damit konnte er nicht umgehen.
Die Ironie an der Geschichte: Der Zug des Schachcomputers basierte auf einem Programmierfehler, wie man später herausfand. … Ein Computer-Bug ist für den größten Erfolg der Computergeschichte verantwortlich. Bei Microsoft basiert das gesamte Geschäftsmodell sogar auf Programmierfehlern. [1]
Die Herausforderung begann, als nach einem Update des Linguistiksystems die XML-basierte Schnittstelle plötzlich nicht mehr funktionierte. Die Softwarearchitektur setzte auf eine Mischung aus Java-XML-Parsern, regulären Ausdrücken und direkten Zeichenkettenmanipulationen – ein wahrer Alptraum für jeden Entwickler.
Obwohl das Update technisch immer noch einwandfreies XML lieferte, sorgten die veränderten Attributanordnungen und Namespace-Prefixe dafür, dass die handgestrickten Parser versagten. Die Situation wurde durch enormen Zeitdruck seitens des Kunden verschärft, da das Projekt bereits Verzögerungen erlebt hatte.
Mein ursprünglicher Plan, die betroffenen Module gründlich zu überarbeiten und zu optimieren, hätte ungefähr anderthalb Wochen in Anspruch genommen. Die Deadline setzte uns jedoch eine straffe Frist von nur einer Woche. Vor diese Herausforderung gestellt, entschied ich mich für einen Hack: Ich schrieb einfach noch eine zusätzliche XSL-Transformation, die das neue XML-Format in das ältere, kompatible Format konvertierte. Eine wahnsinnig spannende Aufgabe! Nicht.
Natürlich könnten einige denken, dass wir bereits funktionierende Tests hatten, die die korrekte Verarbeitung bestätigten. Aber das wäre zu schön, um wahr zu sein – wir hatten keine.
Es ist fast überflüssig zu erwähnen, dass der eingeführte Hack nie einer grundlegenden Überarbeitung unterzogen wurde. Technisch gesehen haben wir die Probleme einfach nur elegant unter den Teppich gekehrt.
Aus diesem Debakel habe ich eine wichtige Lektion gelernt: Viele Projekte stehen unter enormem Zeitdruck. Obwohl eine straffe Deadline theoretisch die Produktivität steigern kann, führte sie in unserem Fall lediglich zu einer Verschlechterung der Qualität. Wir waren zwar äußerst aktiv, allerdings arbeiteten wir an den falschen Problemlösungen. Rückblickend wäre es vielleicht klüger gewesen, sich auf die wesentlichen Aufgaben zu konzentrieren, selbst auf die Gefahr hin, den Termin nicht einzuhalten. Letztendlich war die gesetzte Deadline mehr ein Wunsch des Kunden als eine echte Notwendigkeit.
Quellen und Links
[1] Vince Ebert extrapoliert – Spektrum.de
[2] Karsten Kroesch: Von der Pike auf – Mein Leben als Informatiker