Jetzt stehen mir meine wenigen Haare doch zu Berge. Jeff Atwood hat das geschafft. Aus dem witzigen Titel “Coding Horror” seines Blog – das ich eigentlich sehr schätze – ist für mich bitterer Ernst geworden. Sein Beitrag “Software Engineering: Dead?” lässt mir kalte Horror-Schauer den Rücken herunterkriechen. Wie das sein kann? Er meint das Fragezeichen in seinem Beitragstitel ernst:
“what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.” (Atwood)
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 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. Und nicht nur er mag sich erleichtert fühlen, sondern eine ganze Bewegung, die des Softwareware Craftsmanship. Tom DeMarco erteilt den Software Craftsmen, den Handwerkern für die Softwareentwicklung, seine Absolution für ihre Bewegung gegen das Software Engineering:
“I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone.” (DeMarco)
Aus, Ende, tot, bye bye, Software Engineering. Sagt Tom DeMarco. Anscheinend.
Dass Jeff davon jetzt erst so freudig erregt wird, liegt am IEEE-Artikel, der der Selbstverortung von Tom DeMarco kaum ein Jahr hinterherhinkt. Denn spräche Jeff Deutsch, dann hätte er schon im Objektspektrum 6/2008 viele für ihn neue Aussagen DeMarcos schon lesen können.
Nur weil DeMarco dem Software Engineering neuerdings skeptisch gegenübersteht, sehe ich jedoch nicht, dass er das Software Craftsmanship Manifest mit Freuden unterschreibt. Er schreibt ja auch deutlich:
“I still believe it makes excellent sense to engineer software.” (DeMarco)
Seine Kritik gilt also nicht ingenieursmäßigem Denken im Allgemeinen, sondern einer konkreten Ausprägung.
“But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.” (DeMarco)
DeMacro stört sich vor allem an der Kontrollillusion des Software Engineering, die sich in einem Berg an Messinstrumenten und Planungsvorgaben ausdrückt. Der begräbt die simple Wahrheit, die er nun erkannt hat:
“Software development is and always will be somewhat experimental.” (DeMarco)
Bravo, würd ich sagen. Hört, hört! Das (!) scheint mir – auch weil es am Ende des Beitrags steht – die wesentliche Einsicht, aus der es Konsequenzen zu ziehen gälte. Bedeutet das jedoch den Tod des Software Engineering?
Auch ich bin kein großer Freund “mächtiger Methoden” und “allumfassender Ansätze” oder “zwangsweiser Normierung”. Dennoch halte ich es für ein ganz falsches Signal für eine Branche, die zu einem Großteil auf Autodidaktentum gegründet ist, das Bisschen Ingenieurskunst, mit dem sie inzwischen aufgeladen wurde, so zu torpedieren. Der Mann, der Bärentango geschrieben hat, würde ihr damit einen Bärendienst erweisen.
Definiere Software Engineer
Was ist denn eigentlich das Problem mit dem Bild des Software-Ingenieurs, des Softwaretechnikers, des Software Engineer? Hier die grundlegenden Definitionen aus Wikipedia für Ingenieur bzw. Engineer:
“Der Begriff Ingenieur […] umfasst im herkömmlichen deutschen Sprachgebrauch im weiteren Sinne ein Berufsbild, welches durch die systematische Aneignung, Beherrschung und Anwendung von wissenschaftlich-theoretisch fundierten und empirisch gesicherten technischen Erkenntnissen und Methoden gekennzeichnet ist. […] Ingenieure sollten sich durch analytisches Denken, gute theoretische und anwendungsorientierte Fachkenntnisse, verbunden mit praxisorientierten und auf termingerechte Umsetzung bedachte Vorgehensweisen auszeichnen; Grundlage für erfolgreiches Arbeiten ist ein fundiertes Fachwissen und eine gute technische Allgemeinbildung. Die Hauptaufgabe des Ingenieurs stellt der Entwurf von Systemen dar. Dabei handelt es sich um einen komplexen Prozess, bei dem sowohl analytische Fähigkeiten als auch Kreativität eine große Rolle spielen. Die Entwurfstätigkeit ist eine schöpferische Tätigkeit, bei der der Ingenieur sein Wissen einsetzt, einem System eine bestimmte Funktion, Form oder Materialeigenschaft zu geben. Ein wichtiger Faktor bei der Entwicklung eines Systems ist aus Wettbewerbsgründen die Zeit. So muss sich der Ingenieur in der Praxis häufig mit einer nicht optimalen Lösung zufrieden geben, die aber dennoch als gut einstufbar ist.”, http://de.wikipedia.org/wiki/Ingenieur
“Engineers are concerned with developing economical and safe solutions to practical problems, by applying mathematics and scientific knowledge while considering technical constraints. The term is derived from the Latin root "ingenium," meaning "cleverness". The industrial revolution and continuing technological developments of the last few centuries have changed the connotation of the term slightly, resulting in the perception of engineers as applied scientists. The work of engineers is the link between perceived needs of society and commercial applications”, http://en.wikipedia.org/wiki/Engineer
Wo ist das sch… Problem mit diesen Definitionen? Warum sollten wir Softwareentwickler Anstoß daran nehmen? Warum sollten wir nicht danach streben, so zu arbeiten wie die hier beschriebenen Ingenieure?
Ja, gut, Software ist komplexer als ein Auto. Die Anforderungen für eine Software lassen sich schwieriger erheben als für eine Brücke. Und? So what? Sollten wir deshalb verzichten auf “systematische Aneignung, Beherrschung und Anwendung von wissenschaftlich-theoretisch fundierten und empirisch gesicherten technischen Erkenntnissen und Methoden”? Das kann weder Jeffs noch DeMarcos Ernst sein.
Gut, wir haben immer wieder Probleme mit dem Vorgehen bei der Softwareentwicklung und der Kommunikation mit Kunden und anderen Stakeholdern. Und? So what? Sollten wir deshalb nicht immer noch als Ziel haben “economical and safe solutions to practical problems, by applying mathematics and scientific knowledge while considering technical constraints”? Das können beide doch auch nicht ernsthaft meinen.
Die Softwaretechnik – deutscher Begriff für Softwareengineering – mag etwas aufgebläht sein und hier und da noch zu sehr versuchen, ihren Geschwistern einer mechanischen und elektronischen Welt nachzueifern. Sie mag noch zu sehr an einer Kontrollillusion festhalten. Aber muss sie deshalb für tot erklärt werden? Komplett tot? Da kann ich nicht anders als Quatsch! auszurufen. Da schütten Leute grad das Kind mit dem Bade aus. Und ich frage mich, was sie dazu treibt. Wie groß müssen Unsicherheit und Frust für solch eine pauschale Proklamation sein?
Sicherlich täte die Softwaretechnik gut daran, etwas aufzutauen und durchlässiger zu werden. Sie könnte von einem akademischen Dünkel entstaubt werden. Das wäre eine Integration eines Traditionsbegriffs, der nicht so falsch ist, wie Jeff und DeMarco Glauben machen wollen. Stattdessen: Ausgrenzung, Verdrängung, Amputation. Au weia!
Definiere Software Craftsmanship
Und was bietet Jeff als Alternative? Ein Hurra für das Handwerkertum. Webster´s definiert craftsman so:
“An artificer; a mechanic; one skilled in a manual occupation.”, http://1828.sorabji.com/1828/words/c/craftsman.html
Oder hier eine andere Definition:
“1. a worker in a skilled trade; artisan
2. any highly skilled, painstaking, technically dexterous worker, specif. in the manual arts”, http://www.yourdictionary.com/craftsman
Da steckt dann auch noch der artisan, der Kunsthandwerker drin:
“Der Begriff Kunsthandwerk steht für das Handwerk für dessen Ausübung künstlerische Fähigkeiten maßgebend und erforderlich sind. Die Produkte des Kunsthandwerks sind in eigenständiger, handwerklicher Arbeit und nach eigenen Entwürfen gefertigte Unikate (Kleinkunst/Autorenprodukte').”, http://de.wikipedia.org/wiki/Kunsthandwerk
Ist der Software Kunsthandwerker oder der Software Handwerker (von mir aus auch der Software Facharbeiter) nun eine soviel passendere Bezeichnung für das, wonach wir streben? Ich zumindest fühle mich nicht besser beschrieben als jmd, der “skilled in a manual occupation” ist. Und ich glaube auch nicht, dass ein Entwickler, der an einer Warenwirtschaft oder einer Hochregallagersoftware oder an einer Triebwerkssteuerung sitzt, danach streben sollte, “künstlerische Fähigkeitheit” auszubilden.
Zugegeben, wir produzieren meist Unikate. Und? So what? Ein Brückenbauingenieur tut das auch. Sind wir deshalb gleich (Kunst)Handwerker? Und auch zugegeben, wir vertun uns mit unseren Schätzungen und sollten daher ganz anders damit umgehen, agil zum Beispiel. Iterationen sind für ein Projekt wie den Potsdamer Platz eher nicht das akzeptierte Vorgehen und auch nicht nötig, wie wir sehen, wenn wir ihn besuchen. Für eine Anzeigenlayoutsoftware oder eine Gemeindeverwaltungsanwendung aber schon. Und? So what? Deshalb sollten wir uns unser Wissen nicht systematisch aneignen und nach wissenschaftlicher Erkennnis über unser Metier streben?
Termingerecht muss für uns anders definiert werden als für einen Maschinenbauer. Ok. Aber deshalb gilt doch auch für uns:
“Die Hauptaufgabe des [Softwareentwicklers] stellt der Entwurf von Systemen dar. Dabei handelt es sich um einen komplexen Prozess, bei dem sowohl analytische Fähigkeiten als auch Kreativität eine große Rolle spielen. Die Entwurfstätigkeit ist eine schöpferische Tätigkeit, bei der der Ingenieur sein Wissen einsetzt, einem System eine bestimmte Funktion, Form […] zu geben.”
Wenn die Software Craftsmanship Bewegung das nicht unterschreiben will, dann fällt mir nichts mehr ein. Wenn sie sich so gegen ein zugegeben überladenes Bild vom Software Engineer wendet, dass sie dessen Fundament - die Systematik, das Analytische, die Kreativität, die Gründung in der Wissenschaftlichkeit – aus dem Blick verliert, dann sehe ich nicht, wie sie der Branche einen Dienst erweist.
Damit behaupte ich nicht, dass die Software Craftsmen in allem falsch liegen. Keineswegs! Aber ihre plakative Botschaft, die seitenweise Zustimmung zu Jeffs Posting generiert, die halte ich für ab-so-lut kontraproduktiv.
Craftsman, d.h. Handwerker oder gar Kunsthandwerker, beschwört eine romantische Vorstellung herauf von Überschaubarkeit, Gemütlichkeit, Nähe, Ernsthaftigkeit, Stolz… dass es nur so eine Freude ist. Da riecht man förmlich den Holzleim und hört den Hobel; von Ferne tönt der Schlag des Schmieds im Verein mit dem Generalbass seines Blasebalgs; und da ein munteres Lied auf den Lippen des Schneidermeisters wie er zusammen auf dem Tisch mit seinen Lehrlingen sitzt.
Software Craftsmen sitzen natürlich nicht auf Tischen und schitzen auch nicht so wie Schmiede. Dafür wenden sie sich im Pair Programming väterlich ihren Adepten zu, lernen am liebsten auf der Walz, stehen über den technologischen Moden, bringen sich voll mit ihrer Kreativität ein und geben sich ganz der Produktqualität hin. Nicht die Tranfunzel erhellt ihre Hightech Büros, sondern die Lavalampe im Grün der korrekten Tests vom letzten automatischen Build. Zum Mittag treffen sie sich dann alle im Refektorium ihres Entwicklerklosters und lauschen der Lesung aus einer ihrer Bibeln, zum Beispiel “Clean Code” oder “Software Craftsmanship”. Anschließend zurück an die Softwarewerkbank oder in die Codeschreibstube.
Mir wird schon ganz warm ums Herz. Ich will auch…
Nein, natürlich nicht. So schön die Vorstellung ist, so verständlich ich den Wunsch nach einem anderem Leitbild als dem gescheiterten finde, das Handwerkertum halte ich für ab-so-lut ungeeignet als Vision für die Zukunft der Branche. Das ist etwas für Romantiker und überlastete Gekränkte. Kein Wunder auch in einer Branche, die am Burnout vorbeischrammt.
Fazit
Mir ist eigentlich egal, was genau “Software Engineering” bedeutet, wie es von den allgemeinen Definitionen von Ingenieur oder Engineer abweicht. Wenn ich lese, was Ingenieur bzw. Engineer im Allgemeinen tun, dann meine ich, dass wir weiterhin oder gar vermehrt danach streben sollten, so wie sie zu werden.
Die Softwareentwicklung muss noch einiges lernen. Ohne Frage. Doch dass sie mehr und besser lernt, wenn wir sie den Kunden oder nachwachsenden Generationen als Handwerk verkaufen, das kann ich nicht glauben. Software Craftsmanship, wenn es denn seinem Namen gerecht werden will, ist eine romantische Vorstellung; ich würde sogar fast schon sagen, Software Craftsmanship ist eine Regression eines Teil des kollektiven Psyche unserer Branche.
Alskönnten Ingenieure nicht mit Unwägbarkeiten umgehen, als würden sie nicht experimentieren, als würden sie nicht Stolz für ihre Arbeit empfinden, als strebten sie nicht nach Qualität, ja, und als seien sie nicht kreativ. Wasfürein Humbug, wenn Software Craftsmanship all das den Ingenieuren abspricht. Ein Elektrotechnik Ingenieur mag anders vorgehen als ein Softwareentwickler. Aber das tut auch ein Maschinenbauer oder Motorkonstrukteuer im Vergleich zu einem Elektrotechniker. Software Engineers müssen nicht in allem mit anderen Ingenieursdisziplinen gleichziehen.
Auch müssen nicht alle Softwareentwickler Software Engineers werden. Es bleibt Raum für Software Handwerker wie es Raum für Heizungsbauer und Klempner und Tischler gibt. Doch wir alle wissen, was wir einem Maurer zutrauen im Vergleich zu einem Bauingenieur. Und wir alle wissen, was wir dem korbflechtenden Kunsthandwerker zutrauen im Vergleich zu einem Webmaschineningenieur. Kunsthandwerk ist eine schöne Sache – im wahrsten Sinn des Wortes. Wenn die Schnitzerei aus schlechtem Holz ist, die getöpferte Schale nicht spülmaschinenfest… dann ist das nervig, aber nicht wirklich schlimm. Kunsthandwerkliche Produkte treiben uns selten in den Runin, wenn ihre Qualität nicht stimmt.
Wer möchte aber Hunderttausende Euro einem Kunsthandwerker anvertrauen? Oder wer lässt einen Eiffelturm von Handwerkern planen? Hand hoch!
Nein, nein, so einfach sollte es sich Software Craftsmanship oder zumindest Jeff Atwood nicht machen. Die Softwarewelt wird nicht durch mehr Romantik genesen. “Mehr Licht!” wie Goethe schon an seinem Ende sagte und vielleicht doch damit die Aufklärung meinte, das ist eher die Lösung.
Zu schade also, dass ansonsten sehr hell Köpfe wie Jeff Atwood und Tom DeMarco (der allerdings eher unfreiwillig) solchem Rückfall in “voraufklärerische Zeit” der Softwareentwicklung Vorschub leisten. Auch Robert C. Martin ist da kräftig tätig – was Clean Code Developer nicht davon abhält, seine Verdienste um “Clean Code” anzuerkennen.
Um meine Haare jetzt wieder zu glätten, lese ich am besten erstmal ein Werk über softwaretechnische Ingenieurskunst wie z.B. “das Drachenbuch” (gibt es auch in neuerer Auflage) oder dies hier.
Ja, das meine ich so. Wenn ich die erfolgreichen Bausteine anschaue, dann lehren sie uns, dass sie nur praktikabel sind, weil sie eben keine internen Abhängigkeiten haben. Wir stecken nichts in sie hinein. Es gibt keine Dependency Injection in eine Tonerkartusche hinein. Alle Abhängigkeiten sind an der Oberfläche und heißen Input. Ihnen stehen gegenüber andere “Oberflächlichkeiten”, nämlich der Output – der wiederum Input für andere Bauteile ist.
Für mich sind Change Tracking und Persistenz inzw. ganz klar orthogonale Belange. Sie sollten deshalb auch technologiemäßig ganz klar getrennt werden. Change Tracking darf nicht unser Blinder Fleck sein.