Netzwerkprodukte (23) - Planung
In der Softwareentwicklung hat man mit dem Problem zu kämpfen, daß man am Anfang eines Projekts allenfalls in eine (inhaltlich) grobe Richtung sehen kann, ohne jede Chance, die (technischen) Details zu überblicken.
Wenn man z.B. den Auftrag bekäme, eine Software zu schreiben, mit der die Bürger Online-Petitionen beim Bundestag abgeben können, ist allenfalls klar, daß man mindestens zwei Features implementieren muß: neue Petitionen einzureichen, und bereits eingereichte Petitionen zu unterschreiben. Halbwegs erfahrene Softwareentwickler assoziieren sofort eine ganze Reihe anderer Anforderungen - das Resultat muß zuverlässig funktionieren, Datensicherheit ist zu gewährleisten, es muß für sehbehinderte User bedienbar sein, etc. pp. Dennoch wären auch solche Spezialisten völlig überfordert, selbst nach einigem Nachdenken zu sagen, wie viele „Manntage” die Realisierung solch einer Aufgabe erfordern wird.
Das ist schlecht - hat doch der Auftraggeber nur ein gewisses Budget und muß in einem mehr oder weniger striktem Zeitrahmen die Software am Laufen haben.
Man kann sich jetzt hinsetzen, und die Dinge im voraus planen. Dann erstellt man ein Pflichtenheft, in dem zunächst nur drinsteht, was konkret an Funktionalität zu realisieren ist - und das wächst langsam, indem zu jedem Punkt noch ergänzt wird, was technisch zu realisieren ist, um am Ende die geforderten Funktionen in der Hand zu halten. Mit dieser Liste geht man zu einem Anbieter von Softwareerstellung, dessen Management in der Entwicklung nachfragt, wie lange es dauert, die Punkte auf dieser Liste abzuarbeiten, und dann ein Angebot kalkuliert.
Tatsächlich ist man lange Jahre in der Industrie genau so vorgegangen - es gibt sogar irgendeine ISO-Norm, die diesen Prozeß ausgiebig und in jedem Detail definiert. Allein: so hat das noch nie funktioniert. Ich schreibe sehr bewußt „nie”, und nicht z.B. „selten” (wofür das Scheitern der Entwicklung für die Software der Online-Petitionen ein anschauliches Beispiel bietet).
Das grundlegende Problem besteht darin, daß man am Anfang allenfalls ein Grundgerüst vor Augen hat, das aber aus sich selbst heraus immer wieder neue Voraussetzungen neu erzeugt, je weiter man ins Detail geht. Dummerweise sieht man diese Details erst in dem Moment, in denen man vor ihnen steht.
Ein Plan ist die Abstraktion einer zukünftigen Realität.
Eine nicht-triviale Software hat selbst dann einen überaus hohen Grad an Komplexität, wenn sie bereits existiert - selbst Abstraktionen von ihrem konkretem Bestehen sind nicht ganz einfach (z.B. wenn man sie verändern, dokumentieren, oder einfach nur benutzt will). Wenn sie dann noch für die Zukunft erst geplant wird, erweisen sich die anfänglichen Abstraktionen immer als falsch („immer”, und nicht z.B. „meistens”).
Das ist auf einer bestimmten Ebene vergleichbar mit dem Architekten, der ein Gebäude plant: auf dem Papier sieht das alles ganz logisch aus. Es läßt sich im Vorfeld leicht ausrechnen, welche Materialien in welchen Quantitäten benötigt werden, und wieviel das kostet. Auch die Zahl der Stunden, den die einzelnen Schritte bei den konkreten Bauarbeiten in Anspruch nehmen werden, läßt sich zumindest näherungsweise im Vorfeld abschätzen. Spätestens, wenn es um die Kalkulation der Verzahnung der einzelnen Komponenten und Arbeitsschritte geht, wird jede Planung früher oder später von der Realität überholt. Die Verzögerung von nur wenigen Stunden bei der Lieferung einer bestimmten Komponente bewirkt womöglich am Ende, daß die Planung eines Prozesses, in dem ein Arbeitsschritt den nächsten vorbereit, völlig aus dem Ruder läuft.
In der Softwareentwicklung sind es nicht nur die Abläufe, die letztlich unkalkulierbar sind. Hinzu kommt, daß sich in den Abläufen überhaupt erst etwas realisiert, von dessen Existenz man vorher keine Ahnung hatte. Ein Haus ist - mit minimalen Abweichungen - am Ende ein Haus von vielen. Im Bereich von Software sind die Abweichungen hingegen die Regel. Eine Software, die es bereits gibt, muß man kein zweites Mal schreiben, weil man sie kopieren kann. Den Plan eines Hauses muß man immer noch jedesmal neu realisieren - mit den Problemen, die sich auf den Ablauf der Bauarbeiten beschränken. Ein neuer Plan, den man zum ersten Mal realisiert, hat hingegen die Tücke, daß er immer wieder revidiert werden muß, weil er nur begrenzt auf bereits gemachte Erfahrung zurückgreifen kann. Je konkreter solch ein Plan wird, desto komplexer wird die Realität, die er erzeugt, und desto weniger bilden die ihm zugrunde liegenden Abstraktionen ein zutreffendes Bild der Wirklichkeit. (Dies dürfte übrigens auch in der Architektur zutreffen: die Kosten für den Bau eines Reihenhauses sind wahrscheinlich wesentlich besser kalkulierbar als jene z.B. eines Theaters, das es so zuvor noch nicht gegeben hat.)