Ich erinnere mich noch, als ob es gestern war: Vor ca. 35 Jahren stand ich mit einem hochrangigen IT-Manager an meiner Lieblingsbar. Wir tranken und würfelten wie immer und er echauffierte sich über seine Software-Entwickler, die ihre Programme nicht im Griff hatten. „Wenn ich einen Original-Lauf mache, ist das ein Original-Lauf und kein Original-„Probe“-Lauf. Wissen die eigentlich nicht, was Rechenzeit kostet?“ Gemessen an den sonst üblichen Gehältern waren IT’ler sicherlich hoch bezahlte Experten, aber Hardware kostete halt noch exorbitant mehr. Und sie war knapp. Zudem war das übliche Programm ein Batch Programm im wahrsten Sinne des Wortes. Die Lochkarte war noch das unangefochtene Standardmedium zum Speichern von Programmen und immer noch oft genutzt zum Speichern von Daten. Was würde man in dieser Situation erwarten? Richtig, Vorgehensmodelle mit exakten Vorgaben und präzise beschriebenen Daten. Absicherung von Anforderungsanalyse und Codierung durch systematische Reviews. Wem kommt das bekannt vor? Genau, das Lochkartenzeitalter war die eigentliche Hochzeit des Wasserfall Modells, das zum ersten Mal 1970 von Dr. Winston W. Royce publiziert und später nochmals von Berry Boehm überarbeitet wurde.
Dann fielen die Hardwarepreise, Softwareprojekte wurden komplexer und diverse Krisen wurden ausgerufen. Jede neue Programmiersprachengeneration wurde frenetisch als Produktivitätsschub gefeiert (vor allem von den Compilerverkäufern), wildes Hacken und stringente Modelle lösten einander ab. Treiber des IT-Managements waren nicht mehr die Hardwarekosten, sondern „Time to Market“, und Onlinesysteme lösten die in die Jahre gekommenen Batch Programme ab. Es wurde immer klarer, dass das Wasserfallmodell ausgedient hatte – es wurde aber auch immer klarer, dass das Wasserfallmodell das einzige Modell war, das für IT-Manager verständlich war.
Die Programmierer kämpften sich derweil eifrig von Assembler über RPG1, COBOL, Pascal, C, C++ zu Java vor. Softwaretester betraten die Bildfläche, dynamische Tests waren inzwischen von den Hardwarekosten her bezahlbar. Hypes und Moden wie SA/SD und CASE kamen und gingen und die inzwischen zu Softwareentwicklern mutierten Programmierer ertrugen immer neue Management-Ansätze mit stoischer Gelassenheit – immer auf das universale Entwicklungstool hoffend. Inzwischen wurde Lean Management eingeführt, die Fachbereiche bis zum geht nicht mehr ausgedünnt. Um das zu kompensieren, wurden Fachbereich und Softwareentwicklung sorgfältig voneinander getrennt, was bedeutete, dass auch die EDV-Koordinatoren alten Schlages von der Bildfläche verschwanden. Da nun niemand mehr in der Lage war, komplexe Entwicklungsprojekte inhaltlich zu steuern, entstand die iterativ inkrementelle Entwicklung. Gleichzeitig startete der Siegeszug von SPICE, CMM und CMMI und man erfand den USE Case, um den an der Kapazitätsgrenze arbeitenden Fachbereichen das Formulieren ihrer Anforderungen zu erleichtern.
Während für die eigentliche Entwicklung immer weniger ausgegeben wurde und diese Ausgaben dank Outsourcing noch weiter sanken, stiegen die Kosten für das Management von Entwicklungs- und Wartungsprojekten. Folgerichtig erschien das agile Manifest auf der Bildfläche. Entwickler begannen in Sprints und Time Boxen zu denken und die Kosten für das allgegenwärtige Trial & Error in Refactoring-Releasen zu verstecken – während sich das Management über die eingesparten Kosten für Analyse und Design freute. Im Rückblick erscheint die Entwicklung folgerichtig. Agile Projekte wären im Hinblick auf die Kostenstrukturen der 70er Jahre nicht machbar gewesen, in den heutigen Markt-, Organisations- und Kostenstrukturen sind sie für viele IT-Produzenten aber das vermutlich einzig sinnvolle Vorgehen. Zudem: Was gibt es aus Lieferantensicht schöneres als dauernd mit dem Kunden über neue Features oder ärgerliche Fehler zu reden? Ich erinnere mich in diesem Zusammenhang an einen SQM-Kongress Mitte der 90er Jahre. Ein Referent beschrieb die Entwicklung eines exzellenten Frameworks, legte die Vorteile des Ansatzes dar und die Konsequenz: Er war seit kurzem arbeitslos, da die Firma, die das Framework vertrieb, pleite gemacht hatte. Da das Framework keine Fehler hatte, gab es keinen Grund, mit dem Kunden zu sprechen, und während die Konkurrenz jeden Fehler als Ansatz für ein Vertriebsgespräch nutzen konnte, fehlten den Frameworkentwicklern mangels solcher Gespräche die Folgeaufträge.
Beim Blick in die Glaskugel (auch Zukunft genannt) bitte ich Sie um Hilfe. Was meinen Sie: Wird Hacking 2.0 die typische Vorgehensweise der Zukunft oder gibt es eine Weiterentwicklung zu formalisierteren Modellen (wenn ja, welchen)? Schreiben Sie mir Ihre Meinung.
Herzlichst Ihr
Tomas Schweigert