Follow my new blog

Donnerstag, 23. Juli 2009

Romantik rettet die Softwareentwicklung? [OOP 2009]

image

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.

imageDie 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.

image 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.

30 Kommentare:

Hannes Preishuber hat gesagt…

guten Morgen Ralf,
als Pragmatiker (und Ingenieur) halte ich diese Details für Haarspalterei. Die Softwarewelt unterscheidet sich nicht von anderen Welten (höchstens durch die verwendeten Acronyme).
Ich komme zu dieser Erkenntnis weil ich als Nachrichtentechniker vor 20 Jahren an der Entwicklung der ersten Mobiltelefone beteiligt war. Ich habe in einer kleinen Abteilung an HF Dichtungen für Philips Telefone gearbeitet. Früher wurden da Silikonschläuche mit Silbergeflecht umwickelt. Das war in der Zeit der kleiner werdenden Geräte nicht mehr zweckmäßig. Also hat jemand versucht versilberte Glaskugeln mit Silikon zu mischen und diese als Dichtungen zu pressen. Da waren lauter Ingenierure damit beschäftigt das Projekt durchzuführen, viel Forschung, viele Prozesse (wie z.B. das Messen und dokumentieren von Materialeigenschaften) bis hin zur Entwicklung der Massenfertigung. Für mich nichts anderes wie ein herausforderndes Software Projekt.
Also wir sollten aufhören uns als was Besonderes zu betrachten die mit besonderen Methoden arbeiten müssen. Wir sind real World, manchmal braucht es besondere Methoden um etwas in eine andere Richutng zu bewegen aber es gibt nicht die universelle passende "Religion" der wir alle nacheifern sollten. Es gibt hervorragend Handwerker, Architekten und Ingenieure in Software Teams und wir brauchen sie alle.

Ralf Westphal - One Man Think Tank hat gesagt…

@Hannes: Da stimme ich dir voll zu.

Dennoch halte ich es eben für keine Haarspalterei - das wäre Feilschen um Details -, sondern für eine eben unnötige oder kontraproduktibe Spaltung - das ist Krieg ums große Ganze, ein Schisma -, wenn Robert Martin, Jeff Atwood und in Maßen auch Tom DeMarco sagen, Software Engineering könne man vergessen.

Die lassen nämlich keinen Raum für die salomonische Erkenntnis von dir: "Es gibt hervorragend Handwerker, Architekten und Ingenieure in Software Teams und wir brauchen sie alle."

Deshalb standen mir die Haare zu Berge - ungespalten ;-)

-Ralf

Karsten Samaschke hat gesagt…

Ich sehe es nicht so "pragmatisch" wie Hannes: Software-Entwicklung ist heutzutage ein industrieller Prozess und keine Handwerkskunst mehr. Dementsprechend sind die Aussage der "Handwerker" (die natürlich irgendwo ihre Berechtigungen haben) auch schlicht Unfug. Software-Engineering als Prozess, als Ansatz, als Idee ist aktueller denn je - maximal muss es eben ein wenig entschlackt werden. Full ACK mit Ralf.

Anonym hat gesagt…

Interessant finde ich in diesem Zusammenhang Ideen über den Umgang mit hochkomplexen Systemen aus der Kybernetik. Die zwei Ansaetze haben imho grosse Relevanz fuer das Softwareengineering:

Kybernetik I: Systeme koennen durchanalysiert werden. Man nimmt an, dass eine Funktionalitaet von A-Z designed werden kann und man die Kontrolle hat ueber das Verhalten dieser Funktionalitaet.

Kybernetik II: Systeme sind oft hochkomplex (lebende Organismen, Gesellschaften, auch Softwareprodukte?) so dass man sie schlicht nicht durchdenken kann. Eine Kontrolle ueber das gewuenschte Verhalten kann nicht gewaehrt werden. Andere Methoden des Umgangs mit solch hochkomplexen Systemen werden angewandt.


Heutiges Softwareengineering folgt oft der Idee der Kybernetik I. Zb hat aktuell die SAP ihr neues Produkt Business-by-Design schulmaessig nach allen Massstaeben des Softwareengineerings erstellt um dann festzustellen: die designten und zusammengefuegten Teile verhalten sich ganz anders als vorab angedacht. Die Folgen sind bekannt.

Ich sehe deMarcos Ansicht auch als Chance in die Richtung der Kybernetik II zu gehen und neue Arbeitsmethoden im Umgang und in der Erstellung hochkomplexer Systeme miteinzubeziehen.

Gruesse

Roland T. Lichti hat gesagt…

Ich habe - als Entwickler noch nicht gesehen, daß irgendwo Software industriell gefertigt wird. Das würde bedeuten, daß es nur noch wenige Ingenieure gäbe, die die Software (bzw. Teile davon) konzipieren und dann Facharbeiter oder Anlernlinge sie in einem industriellen Prozeß ausformulieren.

Softwareentwicklung ist vom Stand höchstens auf dem Stand einer Manufaktur, wo Vorarbeiter die Regeln vorgeben und wie es aussehen soll und dann Handwerker/Ingenieure (ich mag diesen Streit nicht und halte weder Handwerker noch Ingenieur für irgendwie besser oder schlechter) dann die Software erzeugen.

Und ganz nebenbei: mein Onkel hat lange Jahre als Polier auf dem Bau gearbeitet und wenn er nicht die jungen Bauingenieure und Architekten zur Seite genommen hätte, um ihnen zu sagen, daß man doch hier ein bißchen mehr oder dort den Balkon nicht so weit rausbauen soll, dann wären einige Häuser weniger von den Bauingenieuren/Architekten "engineered" worden.

Denn man braucht in der realen Welt genau wie in der logischen Welt der Softwareentwicklung beides: die theoretische Kenntnis und die praktische Erfahrung wie sich das wirklich verhält.

Was wirklich Probleme macht ist es, wenn die Praktiker und die Theoretiker aufeinander treffen und eben NICHT aufeinander hören. Setzen sich die Praktiker durch, dann stagniert die Softwareentwicklung langsam aber sicher (denn neues ist immer unbekannt und unsicherer als die bekannten ausgetretenen Pfade). Haben aber die Theoretiker zu viel Gewicht, so finden leider oft zu viele neue und "hippe" Techniken Einzug und das Projekt scheitert oder erleidet gewaltigen Zeitverzug.

Axel hat gesagt…

Ich konnte mich der Sichtweise, das Softwareentwicklung heutzutage ein "industrieller Prozess" ist noch nie anschliessen. Trotz 100derter Versuche, Software zu modularisieren, wiederverwertbare Komponenten zu bauen, universelle SOA aufzubauen etc. wird doch immer noch geschaetzte 90% aller Software als individuelle Einzelstuecke entwickelt, eben weil eine modularisierte Komposition von Software auf Anwendungsebene nicht funktioniert.

Eben weil aber diese kundenspezifischen Entwicklungen jedesmal neu sind, jedesmal andere Fachdomaenen zugrunde liegen etc. kommt es doch genau zu den Problemen, die wir alle nur zu gut kennen (Stakeholder verstehen sich nicht, Planungen sind das Papier nicht wert auf dem sie stehen, Zeit- und Budgetplanungen sind Wunschdenken etc.) und wegen derer sich agile Methoden ueberhaupt erst entwickeln konnten.

Ich tendiere dazu, De Marcos (und in Teilen Atwoods) Sichtweise moderner Softwareentwicklung eher fuer realistisch zu halten die von Ralf. Einfach weil meine Erfahrung zeigt, das eine Vorgehensweise wie von Atwood vorgeschlagen ("ich weiss, wann das Projekt zuende sein soll, sage es euch aber nicht. Bitte arbeitet bewusst so, das ihr jeden Tag einen Entwicklungsstand habt, den ich nehmen kann und dem Kunden als fertiges Produkt geben kann"). Das ist doch genau das, was agile Prozesse erreichen wollen. Und das zur Erreichung eines solchen Zieles ein vernueftiges Planen und eine professionelle Ausfuehrung (TDD, Pairing etc.) gehoert duerfte wohl fuer alle Positionen voellig unstrittig sein.

Webconsults Europe hat gesagt…

Ich kann dem mit der Haarspalterei nur zustimmen, ob jemand nun Ingeneur oder Entwickler ist,
ob auf meiner visitenkarte Engineer, Entwickler, Developer, Architect oder sonstwas steht.

Ich halte nix von einer Spaltung in Ingineure, Entwickler, Architects und ich hab noch kein Project gesehen wo sowas gut Funktioniert.

Anonym hat gesagt…

Ich finde, der Vergleich mit dem Bau bzw. der Entwicklung eines Automobils hinkt gewaltig, besonders wenn man sich mal anschaut, was für ein Aufwand in den großen Automobilschmieden betrieben wird. Zusätzlich kommt auch noch hinzu, dass das Automobil sicher funktionieren und strenge Auflagen erfüllen muss. Dies ist dann auch noch haarklein zu dokumentieren und nachzuweisen.

Softwareentwickler müssen aufhören, die Softwareentwicklung als was besonderes zu sehen, nur weil sie angeblicher komplexer ist. Sie ist es definitiv nicht!

Was ich allerdings auch sehe, ist, dass es in der Softwaretechnik immernoch an geeigneten Methoden mangelt und die existierenden, sich auf die falschen Felder konzentrieren. Es muss mehr in Richtung Entwicklungsmethoden als in Richtung Controllingmethoden gehen. Ferner fehlt doch vielen auch ein Verständnis für Standardlösungen und deren Anwendung. Es wird vieles, weil es in Software eben einfach ist, zu oft neuerfunden.

Letztendlich kann ich nur sagen, das Software genauso behandelt werden sollte, wie jedes andere Produkt auch.

Ralf Westphal - One Man Think Tank hat gesagt…

@Axel und Roland: Ich glaube, bei euch liegt ein Missverständnis vor. Ingenieursmäßig bedeutet nicht sofort industriell gefertigt bzw. Massenfertigung!

Z.B. eine Firma wie Zühlke (www.zuehlke.com) beschäftigt viele Ingenieure und fertigt Hardware wie Software - aber nie in Masse.

Der Gedanke an Massenfertigung und insofern "übliche" Industrialisierung ist bei Software ohnehin fehl am Platze. Softwareentwicklung ist keine Produktion, sondern eben Entwicklung. Softwareentwickler tun das, was Ingenieure vor der Massenfertigung tun: sie entwickeln ein Produkt.

Die Fertigung/Produktion bei Software ist vergleichsweise trivial: compilieren, fertig. Naja, vielleicht noch ein Setup bauen. Das ist aber alles leicht automatisierbar. Die Klimmzüge der Autoproduktion etc. bei der Automatisierung, also das, was wir gemeinhin als Industrialisierung sehen, gibt es in der SWentwicklung nicht. Wir bewegen uns im Vorfeld, beim Design.

Deshalb geht es bei der Frage nach Ingenieur oder nicht um Denk- und Herangehensweisen: Systematik, Analytik, Experiment, Pragmatik, Kreativität, Fachwissen...

-Ralf

Thomas Vidic hat gesagt…

Hallo Ralf,
interessant, wie unterschliedlich man Jeffs Blogbeitrag (und auch den Artikel von Tom deMarco) auffassen kann. Ich glaube nicht, dass einer von beiden (und auch nicht die Software-Craftsmanship Community) eine Aufgabe der von Dir mehrfach zitierten Prinzipien der Ingeneurskunst fordern. Allerdings verbinden viele mit "engineering" einen in relativ klare Phasen aufgeteilten Prozess, in dem ein Modell / Konstruktionsplan oder vereinfacht gesagt eine "Bauanleitung" durch Berechnung, Simulation und viel Nachdenken erstellt wird, um dann auf dieser Grundlage das eigentliche Produkt erstellen zu können. Bei einem Haus oder einem Auto ist das auch vernünftig, da es einen Ziel-Zustand "Fertig" gibt, in dem dann viele Änderungen nur noch sehr schwer durchzuführen sind. Software verhält sich hier (oder besser: kann sich hier) aber anders verhalten. Das Produkt der Softwareentwicklung ist eben (wie Du ja auch schreibst) nicht ein ausführbares Kompilat, sondern der Quellcode (+ Build & Deployment etc).
Und mir scheint, die Erkenntnis der Software-"Handwerker" ist die folgende: Einen großen Anteil an der Qualität des Produktes "Software" haben die vermeintlich kleinen Dinge: Gute Namen, kleine Methoden, saubere Zuständigkeitstrennung (eben die sorgfältige Ausführung des Programmierhandwerks; mir fällt jedenfalls kein besserer Ausdruck dafür ein). Und einen deutlich geringern Anteil as früher angenommen haben Planung, Messung, (UML-) Modelle, Spezifikationen oder andere häufig mit Engineering assozierte Techniken.

Insofern finde ich deine Polemik der Craftsmenshipbewegung (auch wenn ich schmunzeln musste ;-) ) mindestens ebenso gefährlich wie die grob vereinfachende Aussage "Softwareengineering is dead".

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Wenn jmd sagst, Software Engineering sei tot, dann sagt er nicht, ein "in relativ klare Phasen aufgeteilte[r] Prozess" sei tot, also eine mögliche Sichtweise auf den Begriff, sondern der Begriff selbst.

Jmd, der sagt "Software Engineering" sei tot, kann sich nicht bei der Pauschalität seiner Aussage nicht darauf zurückziehen, dass er nur diese oder jene typischerweise mit dem Begriff verbundene Eigenschaft zurückweise. Nein, nein, so einfach sehe ich die Ehrenrettung von Jeff und Robert und DeMarco nicht. Sie sagen, Engineering ist tot. Und nicht nur das! Zumindest Jeff und Robert rufen sogleich einen neuen Berufsstand aus, den Software Craftsman.

Das ist keine differenzierte Diskussion. Das (!) ist Polemik, das ist Spaltertum.

Die Agilisten haben es viel effektiver gemacht, finde ich. Sie haben alle sein lassen, was sie wollten und haben nur ein paar Aspekte herausgepickt, an denen etwas verändert werden sollte. Sie haben keine Spaltung intendiert - auch wenn sich viele in ihrem Glauben an den Wasserfall erschüttert gefühlt haben.

Die Agilitätsbewegung ist sinnig an die Sache herangegangen, dass da was faul ist im Staate der Softwareentwicklung. Und die Lean-Bewegung folgt ihnen nun. Mit welchem Erfolg, das müssen wir sehen.

Genauso Clean Code Developer: wir lassen alle, wie sie sein wollen. CCD ist es egal, was einer sein will, Handwerker oder Ingenieur. CCD behauptet nur, dass manche Vorgehensweisen in Bezug auf einen Ausschnitt der Softwareentwicklung verlässlich zu besseren Ergebnissen führt. Der Ausschnitt ist die innere Qualität von Software. Auch das ist kein Spaltertum, sondern Ergänzung - und zwar sehr konkret.

Ich polemisiere nicht in sofern, als dass ich Differenzierung vermeide. Wie gesagt: Handwerker und Ingenieure sind beide nötig in der Softwareentwicklung. Und die Ingenieure müssen sich überlegen, inwiefern sie von ihren bisherigen Positionen abweichen können, um sich der Realität der Softwareentwicklung etwas mehr anzunähern.

Es polemisiert, wer sagt, Ingenieurskunst sei für die Softwareentwicklung nicht zu gebrauchen. Solche pauschale Aussage - und an der Pauschalität kann hier kaum gezweifelt werden - bedient vor allem die, die sich enttäuscht fühlen, die unsicher sind, die optionenverwirrt sind, die dem Elfenbeinturm immer schon misstraut haben...

"Software Engineering is dead" ist etwas anderes als "Software Engineering has to rethink itself" oder dergleichen. Tot ist tot, weg, ab dafür, bye bye, auf nimmerwiedersehen, ciao, hasta la vista, baby...

Dagegen wende ich mich. Aber nicht mit Polemik - wenn auch mit vielleicht scharfen Worten -, sondern mit einem simplen Argument: solche Aussage ist undifferenziert.

"Software Engineering" ist zu alt und zu groß, um es mit einem Federstrich wegzuwischen.

Und weil das eben nicht funktioniert, sondern nur zu Konflikten in einer Branche führen kann, die es eh nicht so mit der Kommunikation hat, deshalb ist es nicht nur undifferenziert, sondern kontraproduktiv im Sinne von Veränderung zu Besseren.

Ist diese Position polemisch?

-Ralf

Thomas Vidic hat gesagt…

Hallo Ralf.
"Ist diese Position polemisch?"
Nein!, und in vielen Punkten teile ich sie. Ich habe mich wohl auch unklar ausgedrückt: "polemisch" bezog sich auf den Abschnitt "Dafür wenden sie sich im Pair Programming väterlich ihren Adepten zu [...] Mir wird schon ganz warm ums Herz.", welcher, sagen wir mal, statirisch gefärbt ist?

Vielleicht ist das Grundproblem auch eher das folgende: Metaphern tragen immer nur innerhalb gewisser Grenzen. Und sowohl "Ingenieurskunst" als auch "Handwerk" sind eben nur Metaphern für die Tätigkeit, eine Software-Anwendung zu entwickeln. Manche Aspekte sind eher "engineering", andere eher "craftsmanship", und wieder andere Aspekte passen in keins der beiden Bilder.

Schließlich aber noch: Ein Artikel "Software Engineering has to rethink some of the aspects of the practices established over the last decades..." hätte wohl eher gelangweiltes Gähnen als eine fruchtbare Diskussion provoziert. Eine Diskussion, in der sicherlich Atwood, Martin oder deMarco (genauso wie vielleicht wir) im Detail deutlich unterschiedliche Positionen beziehen.

P.S.: Auch wenn ich es mir vor dem Hintergrund der Sachlichkeit verkneifen sollte: ""Software Engineering" ist zu alt und zu groß, um es mit einem Federstrich wegzuwischen." - Auch das "Geozentrische Weltbild" war alt und groß, bevor es mit einem Federstrich wegewischt werden musste...

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Ok, bei "satirisch gefärbt" fühle ich mich verstanden ;-)

Hier haben wir allerdings unterschiedl Auffassungen: Deinem "Und sowohl "Ingenieurskunst" als auch "Handwerk" sind eben nur Metaphern für die Tätigkeit, eine Software-Anwendung zu entwickeln." stimme ich gar nicht zu. Weder ich sehe sie als Metaphern, noch sehen Atwood & Co sie als Metaphern. Wenn du dir mal die Diskussionen um die "rechte Lebensweise" der Software Craftsmen ansiehst, dann ist findest du da keine Metaphern, sondern den Willen zum handwerkerlichen Leben.

Das finde ich auch gar nicht schlecht - wenn es denn nicht den Anstrich eines kompletten Gegenentwurfs hätte.

Und ich meine Ingenieur auch nicht als Metapher. Wenn der Bauing oder der Elektroing systematisch und analytisch und mit der Wissenschaft Hand in Hand und kreativ arbeiten, dann tun Softwareentwickler gut daran, sich da mal etwas abzuschauen. Ingenieure sind keine Märchengestalten, sondern Leute, min. 150 Jahre Erfolg vorleben.

Dass sich der nicht einfach 1:1 auf Software übertragen lässt, nun, das (!) wissen wir schon. Dafür braucht es keinen DeMarco oder Atwood mehr.

"Was können wir von Ingenieuren lernen?" - die Frage taucht in der Diskussion nicht wirklich auf.

Ob das Rethinking eher "gelangweiltes Gähnen als eine fruchtbare Diskussion provoziert" hätte, möchte ich mal dahingestellt lassen. Aber selbst wenn... letztlich wäre das besser gewesen als die Gefahr einer Spaltung.

Zum geozentrischen Weltbild: Das wurde nicht weggewischt, sondern um seine Ersetzung wurde gerungen.

Doch der Vergleich passt ohnehin nicht. Zum geozentrischen Weltbild gibt es keine echte Alternative. Wir können nicht halb geo-, halb heliozentrisch in die Welt schauen.

Beim Software Engineering ist das jedoch anders. Das gibt es nicht nur ganz oder gar nicht. Daran kann man basteln, feilen, was dazu tun, was wegnehmen. Es ist formbar. Dito das Software Handwerkertum. Beide können koexistieren. Es gibt deshalb keinen Bedarf, mit dem großen Rotstift zu kommen. Wer es trotzdem tut und ausruft, SE sei tot, der ist auf unnötigen Konflikt gebürstet.

-Ralf

Andreas Krey hat gesagt…

Herrje. Es gibt zwischen Softwareentwicklung und allen anderen Ingenieurdisziplinen einen himmelweiten Unterschied.

Wenn der nicht wäre, würden die Architekten des Potsdamer Platzes nach Fertigstellung der Blaupausen einfach den nightly Build anstoßen und könnten am nächsten Tag durch ihr Werk laufen. Und wenn ihnen oder ihren Kunden was nicht gefällt, einfach die Blaupausen ändern und am nächsten Tag wieder gucken.

Wenn die Firefox-Entwickler der Meinung sind, daß die Scrollbalken doch nach links statt nach recht gehören (and they do), können sie das im Code ändern, und am nächsten Tag ist das in allen Firefox-Instanzen der Welt, die automatischen Update machen, so.

Versucht das mal mit einer Brücke oder einem massengefertigtem Auto. Könnten wir uns ein paar Rückrufaktionen sparen.

In der Softwarewelt wird alles, was 'industriell' geht, in Nullkommanix automatisiert.

Ralf Westphal - One Man Think Tank hat gesagt…

@Andreas: Da hast du Recht.

Aber wofür ist das ein Argument? Für mehr Handwerkertum? Oder dafür, dass Software Engineering nicht tot ist? Oder für die Notwendigkeit einer Koexistenz von beidem? Oder dafür, dass sich auch Softwareentwicklung "industrialisieren" lässt? Oder dagegen? Hm...

-Ralf

Markus Gärtner hat gesagt…

Die Historie der Entstehung der Software Craftsmanship Bewegung bei dieser kontroversen Diskussion zu ignorieren, halte ich für kontra-produktiv. "Craftsmanship over Crap" oder "Craftsmanship over Execution" hat Robert Martin im vergangenen Jahr bei Agile 2008 eingworfen, da er gesehen hat, dass Agile nicht mehr als ein Buzzword für das Marketing geworden ist. Auf die Frage nach dem Einsatz von TDD hatten noch einige die Hände gehoben, auf die Frage nach der Abdeckung der geschriebenen Tests wußte keiner eine Antwort. Weder für einen Ingineur noch für einen Handwerker halte ich dieses mittlerweile als ein professionelles Verhalten, und doch sehe ich kaum bis wenig derartige Praktiken im täglichen Einsatz - aber vielleicht arbeite ich auch nur mit den falschen Firmen zusammen.

Zum Thema Komplexität fühlte ich mich gleich an ein Statement von Michael Bolton erinnert:

When someone complains that something too complex, I've been trained ... to ask too complex compared to what? ... There's a difference between "it's too complex" and "I don't have a more useful model than the one I currently have".

Software muss nicht komplex sein, wenn ich eine adäquate Abbildung finden konnten, mit der mein assoziatives Gedächtnis umgehen kann. Auf Lebensformen (beispielsweise Menschen) trifft das nicht zu.

Just my 2 cents.

Ralf Westphal - One Man Think Tank hat gesagt…

@Markus: Die Geschichte von Software Craftsmanship (SC) habe ich keineswegs aus den Augen verloren. Nur halte ich sie Angesichts von Aussagen wie "Software Engineering ist tot" für irrelevant.

Dass Agilität ein manchmal holes Buzzword geworden ist, kann nicht geleugnet werden.

Dass TDD für den einen dies und den anderen jenes bedeutet, dass autom. Tests unterschiedlich gelebt werden, kann auch nicht geleugnet werden.

Und? Was sagst uns das über Software Engineering? Nichts. Was sagt uns das über Agilität? Nichts.

Das sagt uns nur etwas über Kommunikation und Marketing und Politik und die conditio humana.

Um weniger Mist (crap) zu produzieren, muss nicht ein Arm der Softwareentwicklung abgehackt werden.

Und ich sage jetzt schon voraus: Nach agile wird in 3 Jahren lean "falsch verstanden" werden und zum Buzzword verkommen. Nach TDD oder sonstwas wird SC zu einer holen Phrase verkommen. Und umso eher, je weniger konkret SC ist.

Das Problem mit so allgemeinen Äußerungen wie die der SC-Ethik (http://agileinaflash.blogspot.com/2009/04/pillars-of-software-craftsmanship.html) ist eben und war es schon immer, dass sie so auslegungsbedürftig sind.

Das ist einerseits gut; ich bin ja auch für Flexibilität, solange man sie braucht.

Andererseits gibt solche Allgemeinheit eben wenig notwendige Guidance.

"Die Umwertung aller Werte" muss manchmal sein. Dass sie aber in Bezug auf Software Engineering nötig war, glaube ich nicht. Und sozusagen im Vorbeigehen Software Engineering mit crap gleichzusetzen, das ist unbeholfen bis arrogant.

Die Branche (bzw. die Kunden) leidet unter crap. Das ist überhaupt keine Frage. Aber "der sanfte Weg der Agilisten" hat soviel mehr zur Reduktion von crap beigetragen - trotz allem Buzzwordtums -, dass SC noch einen langen, langen Weg vor sich hat, das zu toppen.

Zum Thema Komplexität: Da weiß ich grad nicht, was der Bezug zu meinem Beitrag ist.

Aber hier eine Meinung: Komplexität entsteht nicht im Auge des Betrachters. Sie ist eine Eigenschaft eines Systems.

Die Schwierigkeit mit einer gegebenen Komplexität umzugehen, die hängt vom Betrachter ab. Wenn ich einen Raum ohne Termostat von Hand auf eine konstante Temperatur einregeln soll, dann ist das für mich aus dem Stand schwierig. Das ist eine komplexe Situation, weil Änderungen an der Heizungseinstellungen erst verzögert den Zustand messbar verändern. Habe ich das jedoch schon ein paar Mal gemacht, dann ist es wohl nicht mehr so schwierig.

-Ralf

Sebastian Jancke hat gesagt…

>> Anwendung von wissenschaftlich-theoretisch fundierten und empirisch gesicherten technischen Erkenntnissen und Methoden <<

Genau da liegt meiner Meinung nach ein Problem: es gibt keine oder kaum Empirie in der Computer Science, geschweige denn in unserer Industrie. Selbst einfachste Zusammenhänge sind nicht empirisch bewiesen, gar untersucht und werden nur basierend auf Erfahrungen oder Hörensagen angenommen.

-Gruß,
Sebastian

Ralf Westphal - One Man Think Tank hat gesagt…

@Sebastian: Ja, das halte ich auch für ein Problem. Es fehlt Empirie. Aber warum eigentlich?

Das Problem liegt wahrscheinlich in der Historie: Softwareentwicklung ist ein Kind der Mathematik und der Elektrotechnik.

In der Mathematik gibt es aber keine Empirie. Das liegt sozusagen in der Natur der Sache.

In der Elektrotechnik gibt es auch keine Empirie - aber das Experiment. Experimente funktionieren aber am besten, wenn man einen überschaubaren Versuchsaufbau hat: vor sich ein paar Bauteile, mal Spannung anlegen und schauen, was passiert. Wenn es anfängt zu rauchen, dann ist was falsch; wenn die Lämpchen nicht brennen, dann ist was falsch. Elektrotechnik hat mit "harter Wirklichkeit" zu tun.

Softwareentwicklung nun ist anders. Von ihrer Mutter, der Mathematik, hat sie keine Empirie mitbekommen. Und das Experiment vom Vater, der Elektrotechnik, ist auf sie nur bedingt anwendbar. Softwareentwicklung hat mit "weiter Wirklichkeit" zu tun, weil es hier - gerade, wenn es um Vorgehensmodelle geht - um soziale Systeme geht. Und es gibt häufig nicht so ein binäres Scheitern. Die Falsifikation einer Theorie (und nichts anderes ist ja möglich) ist schwierig, weil der Parameter soviele sind und vor allem sowenig Einigkeit über Qualitätsmaßstäbe existiert.

"Funktioniert" als Zustand kann man immer irgendwie hinkriegen.

Ich habe mit einer Uni über eine Studie zum Thema CCD gesprochen. Wir haben lange diskutiert und sind letztlich (noch) nicht übereingekommen, wie das gehen sollte. Um statistische Signifikanz zu erreichen und nicht nur wieder ein anekdotisches Ergebnis zu erzielen, ist ganz viel zu beachten. Echt krass. Und dabei habe ich das Qualitätsmaß schon maximal eingeschränkt: es zählt nur die Zeit. Nur wenn eine Gruppe weniger Zeit braucht als eine andere, ist deren Verfahren insg besser.

Na, schaun mer mal...

-Ralf

Horst Blechinger hat gesagt…

Tja da frägt man sich dann schon wie es kleine und große Softwarefirmen immer wieder hinbekommen ein lauffähiges Produkt zu entwickeln. Mich würde mal interesseieren ob in Redmond ähnlich diskutiert wird.

Wie schaffen die das nur bei IBM, Microsoft, Oracle, SAP ???

Brauchen die vielleicht Herrn Westphal als Berater?????

Wie wird Open Source Software zum laufen gebracht???

Bei all dieser unterstellten Unkenntnis, Unfähigkeit und was weiss ich.


Die Diskussion ist wichtig aber man kann vieles kaputt quatschen.


Mal Hand hoch. Wer arbeitet in einem Entwicklerteam mit mehr als 20 Leuten?
Oder 100??
1000????

Ein Fahrzeug wird von zig-tausenden Leuten gebaut.
Vom Ingenieur bis zum Bandarbeiter. Das ist alles dabei.

Von genial bis voll daneben.


Gruß Horst

Ralf Westphal - One Man Think Tank hat gesagt…

@Horst Blechinger: Ich unterstelle keine Unkenntnis. Die Unkenntnis ist vorhanden. Daran gibt es keinen Zweifel. Ich sehe sie, wenn ich Assessments durchführe; andere Entwickler berichten mir von ihr. Auch die Kommentare hier zu diesem Beitrag machen das deutlich.

Das heißt aber natürlich nicht, dass es keine kompetenten Entwickler gäbe. Natürlich gibt es die. Nur viel weniger als wir brauchen. Und die fehlenden werden nicht verlässlich ausgebildet.

Ein Schisma in der Branche, bei dem Handwerker auf Ingenieure runterschauen, ist da das letzte, was wir brauchen. Darum geht es mir, wenn ich hier öffentlich den Kopf über Atwood & Co schüttle.

Warum produzieren Microsoft, IBM und SAP so qualitativ hochwerte Software? Wie schafft es Open Source zu hoher Qualität?

1. Open Source ist meistens von minderer Qualität. Der Anteil, der OSS Projekte, die Sichtbarkeit erlangen, ist als minimal. Und warum erlangen sie Sichtbarkeit? Weil sie hohe Qualität haben. Ursache und Wirkung darf also nicht verwechselt werden. OSS macht nicht gute Qualität, sondern gute Qualität zusammen mit OSS macht Sichtbarkeit. Woher kommt die gute Qualität? Weil entweder sehr viele daran mitarbeiten oder sehr wenige mit viel Zeit und hohem Anspruch.

2. Produzieren Microsoft & Co wirklich soviel hohe Qualität? Können wir es daran ablesen, dass die Software funktioniert? Nein. Wer schonmal in .NET Quellcode geschaut hat weiß, dass die Qualität intern nicht superhoch ist. Aber es funktioniert eben. Das ist derselbe Anspruch wie bei der Programmierbude um die Ecke. Was das jedoch langfristig bedeutet... Warum ist Word so schwergewichtig? Warum Visual Studio? Weil auch das schlecht wartbare Moloche sind. Das Microsoft die Weißheit nicht mit Löffeln gefressen hat sieht doch jeder, der VS anschaut: dessen Architektur ist einfach schlechter als die von Eclipse. Microsoft hat es also wider besseren Wissens aufgrund einer Legacy Code Basis nicht wirklich gut gemacht.

Warum konnten die das? Weil sie so groß sind. Wir sind nicht in Scharen weggelaufen, weil wir es nicht konnten. Also haben wir mit VS 1.0 gelebt. Es war nicht schlimm genug für uns - aber es war auch nicht gut.

-Ralf

Anonym hat gesagt…

Und ich dachte immer Eclipse wäre OSS. ;-))

Gruß Horst

Anonym hat gesagt…

OK.


Open Source ist meistens ...

Hab's übersehen.

Gruß Horst

Anonym hat gesagt…

ich habe den Eindruck, dass in solchen Diskussionen oft viele Informatiker und allgemein Leute, die mit Software zu tun haben Beispiele aus der Maschinenbau bringen (Automobil), ohne selber Maschinenbauingenieuere zu sein. Aus der Wiki zu zitieren (was ein Ingenieur ist) reicht aber nicht aus.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Mag sein, dass Wikipedia nicht weiß, was ein Maschinenbauer (also, der typische ;-) "ist". Aber Wikipedia oder auch der Brockhaus wissen, was "man" darunter verstehen soll. Wikipedia & Co beschreiben also ein allgemeines (Selbst)verständnis - dem natürlich nicht alle folgen müssen und auch nicht 100% können. So ist das eben mit Definitionen.

Wenn du aber einschlägige Kenntnisse des "Seins" von Maschinenbauern o.ä. haben solltest, die vom "Sollen" abweichen, dann wären alle hier erfreut, wenn du sie mitteiltest.

-Ralf

Anonym hat gesagt…

zugegeben, es ist schwer und die Zeit ist knapp. Deswegen ist es vielleicht am sinnvollsten es mit einem berühmten Witz auszudrücken.

Ein Mathematiker, ein Physiker und ein Ingenieur wollen das Volumen eines roten Balles bestimmen.

Der Mathematiker mißt dem Umfang, bestimmt den Radius, indem er den Umfang durch zwei und durch Pi teilt und rechnet über Radius hoch drei mal vier Drittel Pi das Volumen aus, welches er mit 10 Nachkommastellen angibt.

Der Physiker mißt das Volumen direkt mit einer Meßvorrichtung, die das Volumen des vom vollkommen eigetauchten roten Ball verdrängten Wassers mißt. Diese Messung führt er neunmal durch und anschließend eine Fehlerrechnung, nach der er sich in der Lage sieht, das gesuchte Volumen auf drei Nachkommastellen anzugeben.

Der Ingenieur schlägt das Volumen im Handbuch für Ingenieure unter "roter Ball" nach.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Aha, soviel zum Bild vom Ingenieur.

Wenn wir den Mathematiker mal außen vor lassen - Software zu berechnen, wie es z.B. für Korrektheitsbeweise nötig wäre, ist schon seit Jahrzehnten eine harte Nuss -, dann bin ich sicher, dass wir Softwarephysiker und Softwareingenieure brauchen.

Die Ingenieure sind den Physikern nachgelagert, denn die Physiker erarbeiten das, was in den Nachschlagewerken der Ingenieure drin steht.

Und so ist es ja auch in der Softwareentwicklung: Physiker erarbeiten z.B. das relationale Datenmodell oder das objektorientierte oder das Tupel-basierte usw. Und Ingenieure schlagen dann nach, was es so gibt und wählen das passende für einen Entwicklungsauftrag aus. Sie wenden es an und grübeln nicht über neue Datenmodelle.

Was mich jetzt aber interessiert, um in dem Witz zu bleiben: Und was würde der Handwerker tun?

Hier ein paar Antworten, die mir einfallen:

-Der Handwerker versteht die Frage nicht. Was bedeutet Volumen?
-Der Handwerker versteht zwar die Frage, aber sagt, "Mir doch egal" und nimmt den roten Ball und schaut, ob der noch in den Koffer passt. (Wenn ich mal einen zu füllenden Reisekoffer als Ausgangsproblem annehme.)
-Der Handwerker lässt die anderen über ihren Ball rätseln, geht in seine Werkstatt und dreht sich einen Ball aus Holz, der ihm gefällt.
-Der Handwerker wendet sich seinen Lehrlingen zu und sagt: "Seht ihr, so ist das mit den Akademikern; alles Theoretiker. Mit denen wollen wir uns nicht gemein machen. Ich zeige euch jetzt mal, wie man mit einer Drehbank umgeht."

Welche weiteren Reaktionsmöglichkeiten gäbe es?

-Ralf

Anonym hat gesagt…

Ich denke man sollte den Begriff "Handwerker" nicht so negativ sehen, da wenn man es mal sich von oben anschaut sind Ingenieure oder Physiker auf Handwerker angewiesen da sie zwar die Theorie haben aber von praktischer Arbeit oft nicht genügend Praxis haben.
Besonders wenn man sich darüber im klaren ist das Häuser zwar von einem Architekten geplant werden, aber von Handwerkern gebaut werden.
(ich möchte nicht das der Architekt die Kelle schwingt oder meinen Dachstuhl aufbaut) Wenn alles zufriedenstellend funktioniert und nirgends was klappert ,dann ist man mit der Arbeit des Handwerkers zufrieden und so ist es bei unseren Kunden doch auch.
Und so wie es schlechte und unbegabte Handwerker gibt, so gibt es diese auch in unserer Branche.

Der Handwerker dagegen hat zwar nicht das umfassende theoretische Wissen wie ein Ingenieur, doch hat er soviel Theorie wieviel er für seine Arbeit braucht und der Rest wird bei Bedarf aufgearbeitet/nachgelesen/nachgefragt.

Besonders in der Zeitabschätzung und Problemlösung ist der Handwerker dem Architekten oft etwas vorraus da er aus der praktischen Erfahrung ein besseres Zeitgefühl hat und auch die anderen Gewerke sieht und mit diesen zusammen auf der Baustelle spricht.

Meiner Meinung nach sollte man den Begriff "Handwerker" durch den "Techniker" ersetzen. Welcher ein fortgebildeter Handwerker ist.


Um bei dem Witz zu bleiben.

Was würde der Handwerker machen:

1. Überschlagen
2. Aus seiner Erfahrung abschätzen
3. Datenblatt lesen
4. Nachrechnen

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Mir kommt hier der Handwerker zu gut weg. Sorry.

Ich sehe nicht, dass er den anderen etwas voraus hat. Der Handwerker, der nicht soviel theoretisches Wissen hat, aber am Ende eigentlich doch alles kann und ohne den vor allem der Ingenieur nicht kann - nun, der ist für mich ein idealisierte Person, die im Grunde die Arbeitsteilung aushebelt.

Wenn wir Arbeitsteilung denken, dann sind darin immer alle gegenseitig abhängig. Der Ing kann nicht ohne den Handwerker - und umgekehrt.

Denn wenn ich nicht möchte, dass der Bauing meinen Dachstuhl zimmert, dann möchte ich nicht, dass der Dachdecker das Empire State Building plant.

Und genau diese gegenseitige Abhängigkeit fällt für mich auch auch bei den Software Craftsmen hinten runter.

Aber das ist dann Trapper und Siedler Menatlität. Die ist gut, wenn keine Infrastruktur da ist und wir in Planwagen den Westen erobern. Dann müssen wir ad hoc entscheiden, wie wir den Fluss überqueren und bauen ein Provisorium. Oder wir bauen ein kleines Dorf aus Blockhütten.

Alles sehr schön - nur eben nicht dasselbe wie New York.

Wer immer in einem 300 Seelen Nest mit Blockhütten leben will, der braucht nicht mehr als Handwerker. Wer aber mehr möchte... wer DSL haben will und eine Intensivstation und einen Krankenwagen, der in 2 Minuten da ist und einen Flughafen, der kommt nicht ohne Ings aus.

Nur wenn Wissenschaftler, Ing und Handwerker sich gegenseitig (!) schätzen, können wir hoffen, gute Qualität in jeder Größenordnung zu bekommen.

-Ralf

Bernhard Pollak hat gesagt…

Ich würde meinen, dass es in der Vergangenheit eine deutliche Übertreibung in Richtung des Engineering Begriffs gegeben hat.

Der Schaden der dadurch entsteht, wurde im Artikel angesprochen: Die Kontrollillusion. Und ich würde vielleicht einen weiteren Begriff prägen: die Fertigungsillusion.

Das wiederum hat aber gravierende Effekte auf das Management von Unternehmen, die versuchen Softwareentwicklung wie andere Engineering Disziplinen zu betreiben.

Der Versuch von klassischen Engineering Disziplinen zu lernen, hat schon längst stattgefunden, allerdings mit dem Ergebnis, dass sich solche klassischen Konzepte schlecht mit Softwareentwicklung vertragen (Auch dieser Einblick ist natürlich wertvoll).

Softwareentwicklung kann nicht in eine klassische Design- und Produktionsphase getrennt werden, weil für Software keine fundamentale Theorie, wie die physikalischen Gesetzmaßigkeiten in anderen Disziplinen, existiert. Dadurch ist es per Definitionem nicht möglich, überhaupt solche Phasen zu unterscheiden. Zum Beispiel haben wir kein mathematisches Model einer "Softwarearchitektur". Wir können genau genommen nicht einmal sagen wo eine solche beginnt bzw. aufhört.

Bei einer Berechnung eines Bauingenieurs ist die Abgrenzung des Designs (im Sinne der mathematischen Berechnungen) von der eigentlichen Herstellung sehr viel klarer definiert und auch beweisbar. Selbst wenn die Rahmenbedingungen teilweise auf Erfahrungswerten (also geplanten oder ungeplanten Experimenten) basieren.

Den quasi "Minderwertigkeitskomplex" den das Software "Engineering" dadurch erleidet, ist beträchtlich und führt im Versuch der hektischen Auflösung zu allerlei "Wenn du einen Hammer hast, ist jedes Problem ein Nagel" Entwicklungen, wie z.B. der Illusion "OO" wäre die Lösung aller Probleme, aber auch "agile Methoden" wären die Lösung aller Probleme usw.

Meine Hoffnung ist, dass durch diesen "SE is dead" Schock ;-) mehr Bewußtsein dafür geschaffen wird, dass wir von Engineering ähnlichen Prozessen noch weit entfernt sind (und vielleicht immer bleiben werden) und man in der Folge dieser hoffentlich tiefen Einsicht ;-) besser in der Lage ist, neue Wege zu beschreiten und zu akzeptieren, dass es in der Softwareentwicklung auch bezüglich der Lösungsstrategien "soft" zugehen muss (was aber nicht mit chaotisch zu verwechseln ist).