Softwareentwicklung ist nicht schnelllebig

Ohne Zweifel ist Softwareentwicklung anspruchsvoll. Viele Projekte laufen nicht reibungslos oder erreichen nicht die eigentlich erwarteten Ergebnisse. Als Grund wird oft die Schnelllebigkeit und das geringe Alter der Branche angeführt. Es gibt einfach zu wenig Erfahrungen. Wenn es Erfahrungen gibt, sind sie oft auch schon überholt. Stimmt das wirklich?

In Pocket speichern vorlesen Druckansicht 23 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Eberhard Wolff

Ohne Zweifel ist Softwareentwicklung anspruchsvoll. Viele Projekte laufen nicht reibungslos oder erreichen nicht die eigentlich erwarteten Ergebnisse. Als Grund wird oft die Schnelllebigkeit und das geringe Alter der Branche angeführt. Es gibt einfach zu wenig Erfahrungen. Wenn es Erfahrungen gibt, sind sie oft auch schon überholt. Stimmt das wirklich?

Nehmen wir ein konkretes Beispiel: Ein Projekt ist im Zeitverzug und muss bald ein Ergebnis liefern. Was tun? Die Arbeit kann auf mehr Schultern verteilt werden. Man kann einfach mehr Entwickler in das Projekt stecken. Mehr Entwickler werden das Projekt schneller machen. Schließlich können sie mehr Code schreiben. Intuitiv ist das die richtige Entscheidung. Wenn ein Maler eine Wand streichen soll und ihm ein anderer Maler hilft, werden sie viel schneller fertig werden. Wieso sollte das bei Software anders sein?

In der Softwareentwicklung gilt leider nicht, dass mehr Entwickler ein Projekt beschleunigen. Schon 1975 argumentierte Fred Brooks in seinem Buch "The Mythical Man Month", dass Projekte mit eine zeitlichen Rückstand sich durch neue Entwickler noch mehr verzögern. Die neuen Team-Mitglieder müssen eingearbeitet werden. Das bindet die Entwickler, die schon länger im Projekt sind. Sie können dann zunächst nicht mehr zum Erfolg des Projekts beitragen. Die neuen Entwickler können ebenfalls noch nicht helfen. Also sinkt die Produktivität, und die Probleme werden gravierender.

Dieses Wissen haben wir seit 1975, also seit 40 Jahren. Es kommt aus dem Projekt zur Entwicklung der Software für die damals neuen IBM-Mainframes. Dieses Projekt ist von der Größe nur mit der Mondlandung vergleichbar und bietet IBM bis heute einen Wettbewerbsvorteil. Trotz dieser Erfahrung werden aber immer noch Projekte mit mehr Entwicklern versehen, um einen Zeitverzug aufzuholen, weil dieses Vorgehen logisch erscheint.

Ein anderes Beispiel: Das Wasserfall-Modell wird immer noch für die Softwareentwicklung genutzt. Eine Aufteilung in verschiedene Phasen und eine ausführliche Planung scheint ein sinnvoller Ansatz, um Software effektiv zu entwickeln. Seit 1970 gibt es aber das Paper von Royce. Es kritisiert den Wasserfall-Prozess und stellt verschiedene Verbesserungen vor. Das ist aus mehreren Gründen bemerkenswert: Die Komplexität der Systeme war damals viel niedriger als heute. Also sollten die Projekte auch besser beherrschbar und planbar sein.

Der Schwerpunkt von Royce' Arbeit lag auf Systemen für die Raumfahrt. Gerade in diesem Bereich sollte eine ausgiebige Planung nach dem Wasserfall-Modell sinnvoll sein, weil die Anforderung klar sein und die Sicherheitsanforderungen ausführliche Planung und Reviews erforderlich machen sollten. Zu allem Überfluss wurde das Paper lange als Ursprung des Wasserfall-Modell angesehen – obwohl es in Wirklichkeit eine Kritik ist. Wie solche Mythen entstehen, kann man in dem unfertigen Buch "The Leprechauns of Software Development" nachlesen.

Um Fortschritt zu erreichen, müssen lange bekannte Erkenntnisse aus dem "Mythical Man Month" oder dem Royce-Paper beachtet werden, auch wenn sie nicht intuitiv sind. Sich konsequent an dem zu orientieren, was funktioniert, ist ein Zeichen von professionellem Vorgehen. Das Problem ist dabei nicht die Schnelllebigkeit unserer Branche, denn beide Quellen sind über 40 Jahre alt.

Das Problem der Softwareentwicklung ist nicht die Schnelllebigkeit, sondern dass einige Zusammenhänge einfach nicht intuitiv sind und wesentliche Erkenntnisse auch nach langer Zeit nicht beachtet werden. ()