Stephan Roth - Softwareentwicklung

Hallo werte Leser,

eigentlich habe ich momentan ja Urlaub, aber nicht nur die Meldung, das es dieses Jahr wohl nichts mehr mit dem neuen C++0x-Standard werden wird hält mich bei Laune, nein, auch Tom deMarco, Autor zahlreicher Bücher und gern gesehener Sprecher auf Konferenzen, sorgt mit einigen gewagten Äußerungen für viel Zündstoff im Sommerloch.

Der Stein des Anstoßes: in einem jetzt erschienenen IEEE-Artikel mit dem Titel Software Engineering: An Idea Whose Time Has Come and Gone? (PDF-Datei) kommt deMarco zu dem Schluss, dass die Zeit des Software-Engineerings vorbei sei:

„I'm gradually coming to the conclusion that software engineering is an idea whose time has come and gone.“ (Tom deMarco)

Auch seine vielzitierte Aussage „You can't control what you can't measure“ relativiert deMarco und sagt, das Metriken, Steuerung und Kontrolle nicht unbedingt erforderlich sind um Software-Entwicklungsprojekte erfolgreich abzuschließen:

„My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no. (…) Many projects have proceeded without much control but managed to produce wonderful products such as GoogleEarth or Wikipedia.“ (Tom deMarco)

Sogleich reagierte die Szene auf diesen Artikel und hat einige Diskussionen ausgelöst. Der bekannte Software-Entwickler, Buchautor und Blogger Jeff Atwood spricht in seinem Blog Coding Horror förmlich von einem Befreiungsschlag:

„And yet, it's also a release. It's as if a crushing weight has been lifted from my chest. I can publicly acknowledge what I've slowly, gradually realized over the last 5 to 10 years of my career as a software developer: what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.“ (Jeff Atwood)

Dieser Aussage, nämlich, das es sich bei Software-Entwicklung nicht um eine Ingenieursdisziplin sondern um Handwerk handelt, wiederspricht der Hamburger Software-Entwickler, Buchautor und .NET-Experte Ralf Westphal in seinem Blog One Man Think Tank Gedanken energisch und sieht darin einen Rückfall in veraltete, romantische Denkweisen:

„Software Engineering ist tot, es lebe die Handwerkskunst! Das ist der Schlachtruf eines Bloggers, der von Zehntausenden gelesen wird. Mit Verlaub, ich kann es nicht fassen. Schon lang hat er das Handwerkerherz in seiner Brust schlagen hören, aber mochte sich nicht so platt outen. Nun jedoch, anlässlich eines IEEE-Beitrags von Tom deMarco, da fühlt er sich erleichtert und bestätigt in seinem Fühlen und lässt es raus. (…) Nein, nein, so einfach sollte es sich Software Craftsmanship oder zumindest Jeff Atwood nicht machen. Die Softwarewelt wird nicht durch mehr Romantik genesen. (…) Zu schade also, dass ansonsten sehr helle Köpfe wie Jeff Atwood und Tom deMarco (der allerdings eher unfreiwillig) solchem Rückfall in ‘voraufklärerische Zeiten’ der Softwareentwicklung Vorschub leisten.“ (Ralf Westphal)

Aber was ist Software-Entwicklung nun wirklich? Ist es eine Ingenieursdisziplin? Ist es Handwerkskunst? Ist es irgendetwas dazwischen? Und was hat Tom deMarco in seinem Artikel eigentlich wirklich gesagt?

Schaut man mal zurück auf das, was in den letzten 40 Jahren Software-Entwicklung erreicht wurde, so ergibt sich eigentlich nach dieser verhältnismäßig langen Zeit ein trauriges Bild. Nach wie vor scheitern sehr viele Software-Entwicklungsprojekte. Das hat häufig keine rein technischen Ursachen, sondern liegt vielmehr an einer komplizierten Verstrickung von verschiedensten Faktoren. Sehr häufig wird die enorm hohe Komplexität von Software-Systemen stark unterschätzt. Gut, auch ein Automobil ist ein sehr komplexes System, aber in der Automobilindustrie hat man geeignete Methoden, Vorgehensmodelle und Prozesse (Systems Engineering) gefunden, um ein funktionierendes und sicheres Fahrzeug herstellen zu können. Diese Methoden sind ausgesprochen aufwändig, kosten enorm viel Ressourcen, Zeit und Geld, aber sie sind zwingend notwendig, weil das Fahrzeug sonst keine Betriebserlaubnis erhält und niemals für die Straße zugelassen werden würde. Und: wenn das Auto dann in hohen Stückzahlen vom Fließband läuft, dann sind die Entwickler und Ingenieure eigentlich fertig – es wird dann produziert!

Software-Entwicklungsprojekte sind häufig individuelle Einzelprojekte, also: eine Maßanfertigung für einen speziellen Kunden. Zu einer Massenfertigung/Produktion im industriellen Maßstab kommt es nur sehr selten, allenfalls in der Produktentwicklung. Selbige wäre bei Software auch ausgesprochen trivial: kompilieren, Setup bauen, eventuell die CD’s brennen und zusammen mit einer Dokumentation in einen Produktkarton verpacken ‑ fertig!

Meiner Meinung nach ist Software-Entwicklung sowohl Engineering als auch Craftmanship. Allerdings ist der Vergleich mit anderen, klassischen Ingenieursdisziplinen meiner Ansicht nach falsch, und führt in der Praxis dadurch auch zu falschen Erwartungshaltungen und Mißverständnissen. Insbesondere im Management versteht man häufig nicht das es etwas grundlegend anderes ist ein Software-System herzustellen statt beispielsweise eine Brücke zu planen und zu bauen. Hat irgendein “Software-Ingenieur” eigentlich schon mal ein Konstruktionsbüro für Hoch-, Tief-, Industrie- und Brückenbau besucht und geschaut, wie dort gearbeitet wird? Kann man eine Brücke agil entwickeln, sprich: hat der Brückenkonstrukteur die Möglichkeit auf Veränderungen zu reagieren, wie es der Software-Entwickler in einem agilen Prozess kann? Nein, ganz sicher nicht. Der Brückenkonstrukteur hat genau einen Versuch. Aber er kann aus vielen Jahrhunderten Ingenieurserfahrung schöpfen. Die grundlegende Physik bei Brücken ist, trotz unzähliger Varianten und Formen, prinzipiell immer die Gleiche. Darüber hinaus kommt dabei auch nur sehr selten der “Kunde” mit neuen Anforderungen um die Ecke…

Tom deMarco ist meines Erachtens gründlich mißverstanden worden. Er macht in seinem Artikel nur auf etwas aufmerksam, was viele Entwickler und Projektleiter tagtäglich zu spüren bekommen, und was viele Manager nicht wahrhaben wollen: alle Kontrollwerkzeuge und noch so ausgefeilten Prozesse und Methoden schaffen es nicht, die Komplexität von Software-Systemen 100%tig beherrschbar zu machen und somit die Software-Entwicklung zu einer Ingenieursdisziplin zu machen, die sich ähnlich berechenbar verhält wie die meisten klassischen Ingenieursdisziplinen. Und so heißt es auch am Ende seines Artikels:

„Software development is and always will be somewhat experimental.“ (Tom deMarco)

DeMarcos Standpunkte sind übrgens gar nicht so neu, sie wurden im deutschsprachigen Raum schon Ende 2008 in einem Artikel des Magazins ObjektSPEKTRUM (Ausgabe 06/2008, PDF-Datei) veröffentlicht.