Tom DeMarco, das Ende des Software-Engineerings und dann?

Der Heise Developer berichtete vor ein paar Tagen über Tom DeMarcos Rückblick auf 40 Jahre Software-Engineering. Das Gleiche stand schon vor einem halben Jahr in der November/Dezember-2008-Ausgabe des Objektspektrums. Hier allerdings auf Deutsch. Der Anlass für ein erneutes Auftauchen der Meldung scheint die Veröffentlichung im IEEE Software Magazin zu sein.

Eigentlich hätte ein Ruck durchs die IT-Branche gehen müssen angesichts der Einsichten von Tom DeMarco.

Der Titel bei Heise ist ein bisschen reisserisch - Ende des Software-Engineerings. Der Begriff war ja nie als Beschreibung der Tätigkeit von Entwicklern gedacht, sondern als Motto für die Zukunft von 1967 aus gesehen. Auch ein bisschen Neid im Blick auf andere Ingenieursdisziplinen war mit dabei. Ist Software-Engineering jetzt zu Ende? Es war vermutlich noch nie ganz da, wenn man sich anschaut, wie heute Software entwickelt wird. Egal, wir wissen ja was wir tun und ob das Wort Engineering dafür verwendet wird oder nicht spielt keine große Rolle.

Viel interessasnter an DeMarcos Artikel sind zwei andere Punkte.

Er relativiert ziemlich die Überbewertung von Metriken. Viele wissen, dass das Einzige was zählt, das Ausliefern von funktionierender Software ist, nicht ein Haufen von Zahlensalat, der ein trügerisches Gefühl von Kontrolle vermittelt.

Der Aufwand, der heute in das Erfassen von Kennzahlen investiert wird, ist für Tom DeMarco Verschwendung. Den meistzitierten Satz aus seinem Buch, was mann nicht messen kann, das kann man auch nicht kontrollieren, relativiert er heute. Statt dessen schreibt er, soll sich ein Manager lieber um die Leute kümmern, um Termine und Budgets.

"Well, you manage the people and control the time and money."

Ich bin gespannt, ob das jemand kapiert. Es sind viele Berater, Trainer und Tool-Hersteller auf dem Gebiet des Aufbereitens von Zahlensalat über Software-Projekte unterwegs, so dass ich keine schnelle Kehrtwende erwarte. Allerdings dürfen diejenigen, die bei der Kennzahlenerfassung eher einen (zu) schlanken Ansatz praktiziert haben, jetzt beruhgt ihr schlechtes Gewissen ablegen.

Der zweite interessante Punkt ist geradezu revolutionär, hyper-agil. Es geht darum wie Projekte geplant werden sollen. Die meisten Firmen arbeiten heute leider immer noch nach dem Wasserfall-Modell, aber iterative und inkrementelle Modelle sind schon in vielen Projekten angekommen.

Bei Scrum oder eXtreme Programming wird Time-Boxing im 2-4 Wochen-Takt empfohlen. DeMarco sieht das noch viel krasser:

“I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”

Das widerspricht zunächst dem Wunsch nach Kontrolle, tapetenfüllenden Gantt-Diagrammen, MS-Project Orgien. Aber die Empfehlung von DeMarco entspricht viel mehr der Realität. Der Kunde hat jederzeit die Möglichkeit die Reissleine zu ziehen. Der Markt kann von außen jederzeit eine Situation schaffen, in der die Software as-soon-as-possible ausgeliefert werden muss, z.B. weil der größte Konkurrent gerade mit einem ähnlichen Produkt rauskommt.

Hier spielen viele Ideen aus der Welt der Agilen Methoden und dem Web 2.0 rein, wie das Continuous Beta, Continous Integration, Test-Driven Development. Es ist schön zu sehen, dass diese Ideen auch bei Tom DeMarco drin stecken.

Ich freue mich immer, wenn Menschen mit Erfahrung über ihre Erkenntnisse berichten und einräumen, wenn sie sich geirrt haben. Solche Beispiele gibt es leider viel zu wenige. Mit fällt noch Stefan Tilkov ein, der heute REST propagiert und dem der ganze Wind um Webservices im Stil von WS-* Leid tut. Wenn doch nur ein paar mehr solche Stimmen wahrnehmbar wären im Rauschen der Marketing-Evangelisten der Blogosphäre!

Und weiter? Bei Metriken werde ich weiterhin einen ähnlich schlanken Ansatz wie bisher fahren und hauptsächlich auf ausgelieferte Sotware und Burn-Down-Charts achten. Was die Verkürzung der Auslieferungszeit angegeht bin ich gearde dabei mit meinem Team die notwendigen Techniken und Tools aufzusetzen, um täglich ausliefern zu können. Aber nicht, weil ich befürchte der Kunde könnte nächste Woche die Reissleine ziehen, sondern um die Feedback-Zyklen zwischen Anforderungserhebung, Test und Anwendern drastisch zu verkürzen.