Im Folgenden finden Sie unsere persönliche Hitliste "klassischer" Fehler. Diese Fehler werden in Softwareprojekten seltsamerweise immer wieder begangen, obwohl ihre fatalen Folgen bereits seit Jahren bekannt sind. Eine umfangreiche Sammlung klassischer Fehler findet sich in [McConnell1996].

• Silberkugel-Syndrom

In ihrer Verzweiflung, Software termingerecht auszuliefern zu müssen, suchen Softwareprojekt-Manager häufig nach silberner Munition, die auf magische Weise den bösen Software-Werwolf zur Strecke bringen kann. Die ganze Hoffnung wird -- teilweise parallel -- auf die neuesten CASE-Tools, Programmiersprachen oder Methodiken gesetzt. Fakt ist jedoch, dass diese Methoden in den meisten Fällen nur unwesentlich helfen, und oft mehr schaden als nützen, da zusätzlicher Einarbeitungsaufwand notwendig ist. Laut Fred Brooks [Brooks1975] ist Software immanent komplex und es wird niemals ein Werkzeug oder eine Methodik geben, die eine Produktivitätssteigerung von einer Größenordnung oder mehr mit sich bringt. Die letzte wirklich große Produktivitätssteigerung kam durch den Übergang von der Assembler-Programmierung zur strukturierten Programmierung. Auch der objektorientierte Ansatz hat bisher nicht den angekündigten Effekt der dramatischen Produktivitätssteigerung durch Wiederverwendung gebracht. Softwareentwicklung war, ist und bleibt ein schwieriges Unterfangen und es gibt keine Silberkugeln, so schön es auch wäre.

• Hinzufügen zusätzlicher Entwickler zu bereits verspäteten Projekten

Fred Brooks [Brooks1975] erkannte bereits in den 60er Jahren, dass die Integration zusätzlicher Teammitglieder in den Spätphasen von Softwareprojekten alles nur noch schlimmer macht. Der zusätzliche Einarbeitungs- und Kommunikationsaufwand nimmt die Teammitglieder stark in Anspruch und verringert deren Produktivität. Auch bringen die neuen Mitarbeiter oft neue Ideen, Methoden und Sichtweisen, die in den Spätphasen eines Projekts eher hinderlich sind. Dennoch kommt es immer wieder vor, dass versucht wird, verlorene Zeit durch zusätzliche Mitarbeiter wett zu machen.

• Das Baumwollpflücker-Syndrom

In der Schule lernten wir den simplen Dreisatz. Der Dreisatz sagt uns, dass wenn ein Baumwollpflücker 10 Körbe Baumwolle in einer Stunde pflücken kann, 10 Baumwollpflücker für diese 10 Körbe nur sechs Minuten brauchen würden. Können dann aber auch neun Frauen das Austragen eines Kindes von neun auf einen Monat reduzieren? Natürlich nicht. Warum nicht? Weil die "Arbeit" im ersten Beispiel vollständig, dagegen im zweiten Beispiel überhaupt nicht teilbar ist. Bei Softwareprojekten ist die Arbeit nur selten vollständig teilbar, und häufig trifft man auf Aktivitäten, die paralleles Arbeiten völlig ausschließen.

• Vernachlässigung wichtiger Aktivitäten unter Zeitdruck

Die meisten Softwareprojekte stehen unter erheblichen Zeitdruck. Obwohl es gerade bei Zeitdruck notwendig ist, mit kühlem Kopf vorzugehen, begehen viele Firmen schwerste Fehler, indem sie sich direkt auf die Kodierung stürzen. Wichtige Aktivitäten wie Anforderungsanalyse, Spezifikation und Design werden nicht oder nur halbherzig durchgeführt. Die Projekte fallen einem "Code-and-Fix" Teufelskreis zum Opfer, der dafür verantwortlich ist, dass ein typisches Softwareprojekt heute den vorgegebenen Zeitrahmen um mehr als 100% überschreitet. Das unvermeidliche Korrigieren von Fehlern, die bereits in früheren Phasen hätten vermieden werden können, macht heutzutage 40-80% der Gesamtkosten eines Softwareprojekt aus [McConnell1996]. Der Aufwand für das Beheben von Fehlern in Spätphasen kann leicht 10 bis 100 mal so hoch wie in den Frühphasen des Projekts sein.

• Vernachlässigte Mitarbeitermotivation

Laut Barry Boehm [Boehm 1981] hat die Motivation der Mitarbeiter eine größere Auswirkung auf die Produktivität einer Firma, als alle anderen Faktoren. Dennoch sparen viele Firmen "am falschen Fleck" und vergeben somit viele Chancen zur Produktivitätssteigerung. Relativ geringe zusätzliche Ausgaben und Zuwendungen (oft nichtmonetärer Art) werden oft tausendfach von den Mitarbeitern an die Firma in Form von geringeren Fehlzeiten und niedrigerer Fluktuation zurückbezahlt.

• Überfüllte, laute Büros

Eine weiterer, häufig anzutreffender Fehler sind Einsparungen bei den Büros. Tom DeMarco und Timothy Lister [DeMarco1987] haben in umfangreichen Untersuchungen festgestellt, dass die produktivsten Teams in deutlich größeren und leiseren Büros arbeiteten als die unproduktiveren. Dennoch wird gerade bei vielen Firmen an der Bürofläche gespart und Softwareentwickler in laute, enge Büros gezwängt, die ein ungestörtes, kreatives Arbeiten ausschließen.

• Verschwendung wertvoller Zeit vor Projektbeginn

Oftmals verstreicht viel wertvolle Zeit, bevor ein Projekt beginnt. Diese Zeit wird häufig mit Aktivitäten wie Budgetierung und der Genehmigung durch das Top-Management verbracht. Es kommt nicht selten vor, dass es drei Monate dauert, bis ein Projekt genehmigt ist, und man dann feststellt, dass das Projekt, dessen Umfang ursprünglich auf zehn Monate geschätzt wurde, dann "unbedingt" in fünf Monaten fertig werden muss. Gerade in solchen "Krisen" wird dann häufig instinktiv das Falsche gemacht: Man fängt sofort mit der Implementierung an (siehe oben).

[Brooks1975] Fred Brooks, "The Mythical Man-Month", Addison Wesley, 1975
[Boehm1981] Barry Boehm, "Software Engineering Economics", Prentice-Hall, 1981
[DeMarco1987] Tom DeMarco, Timothy Lister, "Peopleware", Dorset House, 1987
[McConnell1996] Steve McConnell, "Rapid Development", Microsoft Press, 1996