Wie entstehen Fehler in der Terminplanung von Entwicklungsprojekten

Ziemlich viele Wissenschaftler beschäftigen sich zurzeit mit der Frage nach dem Preis-Leistung-Verhältnis von Software. Es ist bekannt, dass die Softwareindustrie noch relativ neu ist und hier selbstverständlich immer wieder Fehler vorkommen. In diesem Post schildere ich euch einige Geschichten aus meinem Leben als Softwareentwickler, die beim Kostenvoranschlag und Terminplanung gar nicht erst berücksichtigt werden konnten und dadurch die Verlängerung von Entwicklungszeiten verursachten.



Die Geschichte über das Löschen von Dateien und Ordnern

Bei der Entwicklung einer Anwendung (Dateikonverter) wurde eine Terminplanung entworfen, die Aufgaben wurden definiert, und die Anwendung wurde ungefähr nach dem Plan realisiert. Das Programm wurde überprüft und eingesetzt (dies war ein internes Werkzeug für eine kleine Arbeitsgruppe, deswegen konnte es reibungslos, ohne großen Aufwand sofort benutzt werden). Es stellte sich aber heraus, dass regelmäßig ein Fehler an einer Stelle auftrat. Das Programm konvertierte das Archiv in den temporären Ordner, woraus die Daten ins Zielverzeichnis geschrieben wurden, danach wurde der Ordner gelöscht. Das Problem lag daran, dass das Programm es nicht immer schaffte, die Dateien zu schließen, und beim Löschen gab es entsprechend einen Fehler, da die Dateien plötzlich „gesperrt“ waren. Die Anwendung wurde mit .NET programmiert, deswegen war der Startzeitpunkt des File Scavengers und anderer Utilities gar nicht offensichtlich – das war eventuell das Problem. Im Nachhinein kostete die Beseitigung des Fehlers ziemlich viel Zeit – vergleichsmäßig mit anderen Aufgaben innerhalb des Projektes. Ich bin mir immer noch nicht sicher, ob das Problem endgültig gelöst wurde.


Die Geschichte über die Implementierung und Antiviren-Programme

Und hier ist ein anderes Beispiel, in dem ihr eventuell auch eure Probleme wieder erkennt. Allgemein bekannt ist, dass die Antiviren-Programme auf einige Utilities nicht immer adäquat reagieren. Nach einer kleinen, aber wichtigen Änderung in einer von unseren Applikationen begann das Antivirus-Programm wegen einer versuchten Implementierung und Verdacht auf eventuelle Viren wiederholt zu warnen. Obwohl der Code nichts Auffälliges beinhaltete, brauchte der „Kampf“ mit dem Antivirus-Programm jedoch viel Kraft und Zeit, die möglicherweise erspart werden konnten.


Die Geschichte über den Dateidialog

In einer einfachen Applikation (genauer in einem Systemsteuerung-Applet) mussten mal einige Dateien mit einem Standard-Dialogfeld geöffnet werden. Erstaunlicherweise treten beim Dateidialog aus der Applikation dieser Art einige Probleme auf, aufgrund deren das Dialogfeld gar nicht zum Vorschein kommt. Schrecklich, wie viel Zeit für die Problemlösung verschwendet wurde (vergleichsmäßig mit anderen Aufgaben innerhalb des Projektes). Noch schrecklicher war die Lösung: speziell zum Aufrufen des Dateidialogs musste eine Sonderapplikation (!) entwickelt werden. Auf diese aufwendige Art und Weise konnte das Problem gelöst werden.


"Ihr könnt ja gar nicht programmieren!"

geht einem dabei durch den Kopf und das stimmt nicht. Das Komponentenzusammenspiel eines Systems ist häufig so komplex und kompliziert, dass Fehler und Probleme plötzlich an den unerwarteten Stellen auftauchen. Glaubt ihr mir immer noch nicht? Dann wird Zeit für meine vierte Geschichte.


Die Geschichte über die fehlerhafte OpenGL-Applikation

In einem Team, das eine komplexe OpenGl- Applikation entwickelte, trat einmal ein Problem auf: in der Applikation wurden keine Bilder mehr dargestellt. Als erstes wurden alle Entwickler „angehört“, ob sie eventuell was „ruiniert“ hätten. Dann wurde auf die vorhergehende Version zurückgegriffen. Dies half auch nicht weiter. Die Hardware wurde (auf den ersten Blick) nicht geändert. Allerdings erinnerte man sich doch später daran, dass der Rechner seit kurzer Zeit mit einer neuen USV betrieben wurde. Kann sie wirklich die Arbeit einer OpenGl-Applikation beeinträchtigen? Ja, sie kann. Der zu dieser USV gehörende Treiber funktionierte auf allen Anschein einwandfrei, jedoch liefen alle OpenGL- Applikationen, darunter auch Games, nicht. Die Entfernung des Treibers löste das Problem.


Wozu diese ganzen Geschichten?

Ich bin mir ziemlich sicher, dass erfahrene Entwickler und Manager in diesen Geschichten nichts Neues finden. Sie wissen das alles aus eigener Erfahrung. Diese Geschichten können den Anfängern Anregungen geben, die vielleicht doch schon mal die Bücher von Brooks und McConnell gelesen haben, aber sich dabei irgendwie aus jugendlicher Sicht gedacht haben: „Die Alten (die Buchautoren) haben doch in den Zeiten des Altertums programmiert und heutzutage gibt es die Probleme gar nicht mehr!“ Leider gibt es die doch. Und es ist nicht abzusehen, dass sie sich verringern würden. Weder Bibliotheken noch weitere Werkzeuge würden euch vor Einschätzungsfehlern bewahren. Und wenn ein erfahrener Kollege oder Vorgesetzter eure Terminplanung verdoppelt oder sogar verdreifacht, unterstellt ihm keine Kurzsichtigkeit. Denkt einfach mit!


Und das wird immer so bleiben?

Eher nicht. Heute ist die Softwareentwicklung eine junge Branche, die erst auf knapp 10-jährige gut geprüfte Standards und Praktiken zurückgreifen könnte. Später werden sich die Praktiken verfeinern und viele heutigen Fehler werden vermeidbar sein.
Teilt ir in den Kommentaren eure Geschichten mit, was euch beim Entwickeln schon alles passiert ist ;)