One platform to rule them all – so könnte wohl das Motto vieler Softwareunternehmen/-abteilungen lauten. Man ist ein Java-Shop oder eine .NET-Bude oder eine Ruby-Schmiede usw. Hier und da machen einige Entwickler vielleicht einen Ausflug in andere Gefilde, doch das Hauptprodukt wird auf einer Entwicklungsplattform hergestellt.
Das ist kein Zufall. Das ist gewollt. Das will das Management so, weil Vereinheitlichung eine gute Sache ist. Dadurch kann man immer Geld sparen, oder? Und das wollen die Entwickler auch so, weil das weniger verwirrend ist. Es würde sich doch keiner mehr auskennen, wenn ein bisschen Code in Java, ein bisschen in C#, ein bisschen in Ruby und noch ein bisschen in JavaScript oder Clojure oder C++ vorläge. Oder?
Da ist natürlich etwas dran. Eine gewisse Vereinheitlichung, ein Fokus ist ökonomisch. Aber nur bis zu einem gewissen Grad. Darüber hinaus kippt Vereinheitlichung, d.h. Homogenität um in Monokultur mit all ihren Nachteilen.
Aus Plattform-Fokus wird dann Plattform Lock-In. Man kann dann nicht mehr anders. Die Plattform ist dann eine systemrelevante Größe. An der ist nicht mehr zu rütteln.
Das hat negative Auswirkungen auf die Evolution der Software. Die kann dann nämlich nicht mehr mit der Zeit gehen. Entwicklungen auf anderen Plattformen oder gar Entwicklungen ganz neuer Plattformen ziehen an ihr vorbei. Und oft genug sind es sogar Entwicklungen der Plattform selbst, die man nicht nutzen kann. Gerade neulich war ich wieder bei einem Team, das sich noch an .NET 2.0 bindet. Erweiterungsmethoden, Lambda-Ausdrücke, yield return, Linq, dynamische Typen, aync/await und mehr sind dort kein Thema.
Zu den negativen Auswirkungen auf die Software kommen negative Auswirkungen auf das Team. Teams verkalken, wenn sie Jahre lang auf eine Plattform starren. Sie werden immer mehr zu einer Echokammer, durch die dieselben alten Glaubenssätze und derselbe alte Code hallen. Sie werden damit immer unattraktiver für andere Entwickler.
Bei allem Verständnis für den Vereinheitlichungsreflex halte ich diese Nachteile für so offensichtlich, dass ich mich frage, warum der Plattform-Fokus landauf, landab so groß ist. Mir scheint es eine Lücke in der Argumentation dafür zu geben.
Die meine ich nun gefunden zu haben. Ich glaube, ich kenne jetzt das fehlende Argument der Entwickler für die eine Plattform. Und dieses Argumente ist keines, das sich auf einen Vorteil der einen oder anderen Plattform bezieht. Es geht vielmehr um die Kompensation eines Mangels.
Teams mangelt es an einer anderen Sprache für die Beschreibung von Software außerhalb ihrer Programmiersprache.
Oder anders herum: Ich glaube, Teams fühlen sich zu der einen Plattform hingezogen, weil deren Programmiersprache für sie das einzig verlässliche Kommunikationsmittel über Software darstellt.
Es geht weniger um technische Vorteile einer bestimmten Plattform. Es geht auch weniger um technische Vorteile durch Konzentration auf nur eine Plattform. Es geht auch nicht um personelle Vorteile durch eine Vereinheitlichung [1].
Nein, die eine Plattform dient auch als die eine Sprache. Denn wie ein Blick auf aktuelle Konferenzprogramme zeigt, gibt es keine Sprache, um über Code zu reden. Es gibt nur Code und Technologien/Frameworks. Auf der Meta-Ebene findet im Grunde nichts mehr statt.
Früher gab es die ehrwürdige Disziplin des Softwareentwurfs. Die hatte den Anspruch, eine Lösung sprach-/plattformunabhängig zu beschreiben. Zugegeben, das ist manchmal ein bisschen weit getrieben worden. Doch der Grundgedanke war richtig, finde ich. Code war “nur” ein notwendiges und nicht triviales Implementationsdetail.
Diese Disziplin hat eigene Hochsprachen entwickelt. EBNF, RegEx, Zustandsdiagramm, Struktogramm, UML-Diagramme, sogar noch Blockdiagramme mit dem Schichtendiagramm als Sonderfall gehören dazu.
Doch das ist heute alles hohles Geschwätz. Wer nicht codiert, verschwendet Zeit an Flüchtiges. Diagramme haben keinen Bestand, sie veralten in dem Moment, da man sie implementiert. Also gar nicht erst damit anfangen. Jedenfalls nicht offiziell.
Ich kenne kein Tutorial, das eine Vorgehensweise zur Entwicklung von Software von Anforderungen bis zum Code beschreibt, in dem nicht schnellstmöglich zur Tastatur gegriffen wird. Code ist Trumpf! Code ist die einzige Wahrheit! Das wird mantrahaft wiederholt. Und alles andere wird entweder gar nicht thematisiert oder rein textuell abgehandelt. Und so wird aus einem Text ein anderer. Keine Abstraktion, keine Visualisierung. Diagramme sind selten und unsystematisch [2].
Code und Infrastruktur: das ist der Inhalt des Entwicklerlebens.
Und weil das so ist, müssen Code und Infrastruktur vereinheitlicht sein. Denn sie stellen die einzige Sprache dar, auf die Verlass ist.
Was aber nun, wenn Entwickler sich üben würden, ihre Software auch anders ausdrücken zu können. UML hat dazu einen Vorschlag gemacht – leider einen zu schwerfälligen. Vielleicht geht es ja aber auch einfacher. Ich denke, die Suche nach einer leichtgewichtigen Weise zur Beschreibung von Software, ist lohnend [3]. Dabei geht es ja nicht um einen Ersatz für Programmiersprachen. Dann wäre nichts gewonnen. Leichtgewichtigkeit bedeutet Entlastung von den ganzen Details, die sich beim und durch Codieren ergeben. So wie das Codieren in heutigen Hochsprachen auch eine Entlastung ist von ekeligen Details, wie sie bei der Assembler- und Maschinencodeprogrammierung wichtig sind. Speichermanagement, Registerallokation, Kontrollstrukturenbau und vieles mehr liegt hinter uns.
Der Gewinn einer plattformunabhängigen, vom Code abstrahierenden Sprache läge für mich nicht nur in verbesserter Möglichkeit, allein oder im Team über Codestrukturen nachzudenken. Softwareentwurf könnte damit also besser skalieren. Er würde von einer persönlichen Angelegenheit, die beim TDD-Codieren passiert, zu einer Angelegenheit des Teams. Die Collective Software Ownership würde steigen.
Der Gewinn würde außerdem in einer Befreiung aus der Umklammerung einer Plattform bestehen. Endlich könnten Entwickler verschiedener Plattformen an einem Tisch sitzen und gemeinsam über Softwarestrukturen nachdenken. Die würden sie unterschiedlich implementieren, je nach Plattform. Aber sie hätten zunächst einmal eine gemeinsame Vorstellung vom bigger picture.
Eine leichtgewichtige Sprache, um über und (weitgehend) unabhängig von Code zu “reden”, würde die Softwareherstellung also aus dem Plattform Lock-In befreien. Endlich könnte Software leichter aus Code auf verschiedenen Plattformen zusammengesetzt werden. Und das würde die Evolvierbarkeit von Codebasis und Team beflügeln.
Expliziter Entwurf in einer Entwurfssprache ist kein Selbstzweck. Mir scheint er vielmehr eine Bedingung für die Möglichkeit nachhaltiger Softwareentwicklung.
Medizin, Soziologie, Psychologie, Land- und Forstwirtschaft und Politik haben erkannt, dass Monokulturen mittelfristig schädlich sind. Überall da, wo es um Leben, um Entwicklung geht, fördert Vielfalt dieses Ziel. Nur bei der Software-Entwicklung glaubt man noch Gegenteiliges. Da setzt man noch auf Homogenisierung, Monokultur, Vereinheitlichung, Konsolidierung.
Damit sollten wir aufhören. Dafür ist aber eine praktikable Entwurfssprache und –methode nötig. Daran sollten wir arbeiten. Dazu brauchen wir mehr Ideen [4].
Endnoten
[1] Eine Plattformvielfalt kann personell nur von Vorteil sein. Nicht nur würde sie Diversität im Denken fördern, was inzwischen allgemein anerkannt einen immer größerer Überlebensvorteil für Unternehmen darstellt. Noch konkreter bedeutet Plattformvielfalt eine viel größere Auswahl an Entwicklern.
Wer nur Java oder C# macht, der kann nur aus der Java- oder C#-Community rekrutieren. Wer aber Java und C# und Python und JavaScript und Ruby macht, der kann in all diesen Communities nach neuen Teammitgliedern suchen.
Wo Plattformvielfalt Programm ist, gibt es keine zähneknirschende Einstellung plattformfremder Entwickler mehr, die dann mühsam auf die eigene Plattform umgehoben werden müssen. Dann kann jeder mit seiner Plattform zum Gelingen der Software viel schneller beitragen. Das spart bares Geld!
[2] Hier uns da tauchen mal UML-Diagramme auf: ein Klassendiagramm, ein Sequenzdiagramm. Auch Blockdiagramme gibt es hier und da. Doch auch wenn deren Syntax definiert sein mag, ihre Nutzung ist unsystematisch. Sie ist punktuell, steht in keinem Zusammenhang, ist nicht Teil einer Methode oder übergreifenden Sprache oder Kultur.
Diagramme werden nicht als gleichberechtigtes Mittel neben Code angesehen. Sie sind eher Notlösungen, wenn man grad nicht anders kann.
[3] Natürlich wäre es auch gut, wenn Entwickler sich mit mehr Programmiersprachen beschäftigen würden. Dann wären andere Plattformen ihnen nicht so fremd; sie wären offener, für manche Funktionalität auch mal etwas anderes auszuprobieren.
Dass der wahrhaft polyglotte Programmierer jedoch bald Realität würde, sehe ich nicht. Genauso wenig wie Menschen, die mehr als zwei Fremdsprachen sprechen, selten sind. Bei den natürlichen Sprachen hat sich deshalb eine Universalsprache zur kulturübergreifenden Verständigung durchgesetzt: Englisch.
Allerdings ist das kein Englisch, das alle Feinheiten der englischen Sprache enthält, sondern eine Verflachung. Allemal das gebrochene gesprochene Englisch. Doch das reicht für die meisten Situationen, in denen viele Details, Feinheiten, Nuancen ausgelassen werden können.
Warum nicht genauso in der Softwareentwicklung? Womit natürlich keine verflachte 3GL gemeint ist, sondern eine echte Abstraktion.
[4] Wie gesagt, die UML hat einmal versucht, so etwas zu sein. Doch sie ist gescheitert. Ich würde sagen, an Hybris. Sie hat sich nicht beschränken wollen in Breite und Tiefe. Oder es waren zu viele Köche an diesem Brei beteiligt?
Das bedeutet nicht, dass die UML nichts verwertbares enthielte. Ich sehe aber nicht UML 3.0 als Lösung, sondern eher etwas anderes, das hier und da aus der UML etwas entlehnt, ansonsten aber eigenständig ist.
17 Kommentare:
Mir gefällt, dass Du Heterogenität bewirbst mit der Warnung dass zu viel Homogenität ungesund sein kann. Aber Deine Lösung sehe ich nicht ganz. Genauso wenig wie Du polyglotte Programmierer als Standard irgendwo am Horizont siehst (das teile ich), erkenne ich, dass "unproduktive" Sprachen vor allem in agilen Teams zu einem generell besseren Verständnis führen, geschweige denn polyglotte Programmierung ermöglichen. Die häufigste Barriere sehe ich eher in der richtigen Benutzung von Technologie (Tools, Ablaufumgebung, Sprachkonzepte, Bibliotheken) selbst als darin, Domänen- oder Algorithmenwissen aus dem Code lesen zu können.
Wo ich meine, dass man viel machen kann, ist, wo die Probleme sind. Bei Bibliotheken und Sprachkonzepten kann man freilich oft wenig machen. Wenn man aber zumindest die Infrastruktur und Tools so gut macht, dass das Benutzen, automatische Testen und Releasen so einfach wie möglich ist, dann sollten Technologien eine viel geringere Hürde sein. Und konkret hier sehe ich auch den Bedarf von beschreibenden Sprachen um das zu Grunde liegende Architekturschema zu bewerben und immer wieder zu diskutieren in verbessern. Sicher noch an ein paar anderen Stellen: Überblick, Managementpräsen.
Aber so ganz allgemein kann ich Deiner Schlussfolgerung so nicht folgen. Dazu habe ich schon zu viele veraltete Dokumentationen beerdigt.
Hm... wo sage ich denn, dass man erstens viel "Dokumentation" schreiben soll. Und zweitens, dass das, was man unabhängig von einer Programmiersprache ist, veralten soll?
Ich glaube, es herrscht immer noch eine Furcht vor etwas anderem als Code. Vor allem aus Unsicherheit. Weil man sich nicht vorstellen kann, dass man etwas wertvolles ohne Code produzieren kann, was im Code erhalten wird (!) und insofern leicht aus Code zu reproduzieren ist bei Bedarf.
UML Roundtrip Engineering hat nicht recht funktioniert, also kann es auch nix sein mir irgendwas anderem als Code? Schade. Damit stehen wir uns als Branche selbst im Wege.
Die Idee einer "plattformunabhängigen, vom Code abstrahierenden Sprache" gab es vor gar nicht allzulanger Zeit schon mal - sie wurde unter dem Namen "Model Driven Development" vermarktet. Und weil UML damals gerade "Hip" war (und weil vielleicht auch nichts besseres da war), haben diverse Berater und Toolhersteller es damit dann auch versucht.
Dass das nicht allzu gut geklappt hat, sehe ich ganz genauso. Dass ihr mit "Flow Design" und "EBC" da inzwischen etwas erheblich Praxistauglicheres entwickelt habt, davon hast du mich schon seit langem überzeugt. Das ist modellbasierte Softwareentwicklung, die auf dem richtigen Abstraktionslevel ansetzt.
Nichtsdestotrotz sehe ich da allerdings derzeit noch folgende Probleme:
- eure Design-Methodik ist (noch?) nicht hinreichend verbreitet, vor allem nicht im internationalen Raum. Das Meiste, was du so darüber geschrieben hast, ist nur in deutscher Sprache erhältlich, und wird meines Wissens auch fast nur im deutschsprachigen "Software-Entwicklungs"- Raum diskutiert.
- eine solche Methodik ist insofern nicht plattformneutral, weil sie eine eigene Plattform darstellt. Wer eure Flow-Runtime oder EBC-Sprachen einsetzt, koppelt sich damit an etwas, das derzeit kein allgemein anerkannter Standard ist, sondern nur von einer kleinen, elitären Gruppe entwickelt und vorangetrieben wird.
Wie stehst du zu diesen zwei Punkten?
Zu den von dir genannten Problemen:
1. Dass ich mich mit Flow-Design/EBC nicht stärker im Ausland engagiere hat zwei Gründe: Zum einen möchte ich die Methode erstmal in einer überschaubareren Community entwickeln und testen. Die Entwickler in DACH sind genauso kompetent wie die in USA oder Australien - aber in DACH habe ich besseren Zugang zu den Medien. Und mir liegt mancher Dogmatismus bei Leuten aus den USA nicht so sehr. Darauf hab ich keine Lust, wenn es noch etwas auszuarbeiten gilt. Aber das ändert sich langsam. "Clean Code Design" als Summe aus mehreren Ansätzen wird 2013 erwachsen :-) Und dann schaue ich mal über den Sandkasten DACH hinaus :-)
Zum anderen ist es mir wichtig, bei einer Sache, die mir so am Herzen liegt, mit voller Bandbreite kommunizieren zu können. Das kann ich in Wort und Schrift am besten in meiner Muttersprache. Ich habe in den USA gelebt und habe jahrelang Vorträge in den USA auf Konferenzen gehalten. Dennoch sind mir die Nuancen und die Beweglichkeit, die ich im Deutschen und in Bezug auf die hiesige Kultur habe, lieb und teuer. Kaum ein Schriftsteller würde ja auch auf die Idee kommen, in einer Fremdsprache zu schreiben. So empfinde ich das auch.
Da mag man dagegen halten, es ginge doch nur um Technik. Die sollte doch auch ohne viele Worte überzeugen. Kann sein... Aber es ist halt meine persönliche Note, dass ich Wert auf diese Art Bandbreite lege - zusätzlich zur Technik.
2. Flow-Design/EBC oder noch umfassender "Clean Code Design" sind keine Plattform. Dazu ist nicht ein Fitzelchen Spezialsoftware nötig. Auch nicht die Flow Runtime. Eine "EBC-Sprache" gibt es eh nicht.
Es geht ausschließlich um Prinzipien, eine ganz simple Notation und - naja, da hilft alles nix - um eine Weise über Software nachzudenken. Von Paradigma würde ich da gar nicht sprechen. So groß ist es nun auch wieder nicht. Jeder darf weiterhin mit seiner Lieblingssprache arbeiten.
Nur was sich mit einigen Prinzipien und Werten nicht verträgt, sollte über Bord geworfen werden. Oder zumindest nur noch in einem Rahmen angewendet werden, der überschaubar ist und wo keine Gefahr der "Selbst- oder Fremdgefährung" besteht ;-)
Es gibt also überhaupt keine Plattformhürde.
Codeloses Softwaredesign muss natürlich nicht veralten. Es passiert einfach. Mal schneller und mal langsamer. Das Wissen über den Zweck dessen ist in Köpfen. Und Köpfe vergessen, verlieren die Lust, sehen den Sinn nicht mehr, haben keine Zeit, verlassen das Team.
Das ist der Unterschied zu Code. Code tut oder er tut nicht. Dass codelose Artefakte ihren Zweck nicht mehr erfüllen, merkt manchmal jahrelang keiner mehr. Kein Kunde ruft beim Kundendienst an, weil die Pläne nicht mehr aktuell sind.
Oder, weil wir ja Vergleiche mit Physical Life mögen: Weder den Makler, noch die Hausverwaltung, noch die alten Eigentümer hat es interessiert, dass zu meiner Mietwohnung kein Plan mit den Installationen existiert, geschweige denn ein akkurater Grundriss.
Und ich nehme zwar Angst vor ausführlichen codelosen Designs wahr. Aber es passiert sehr viel. Es gibt nur außer ähnlichen Modellsprachen wenig Systematik heutzutage. Und es setzt sich auch nichts als wirklich wirkungsvoll und erfolgreich durch.
Das kann zwei Gründe haben: Entweder sind wir noch nicht gut genug (gilt immer) und haben nur noch nicht lange genug gesucht - oder der vermeintlich geschaffene Wert ist einfach nicht transparent genug. Wenn es sich nichtmal für Elektroinstallationen einer Altbauwohnung lohnt, Pläne aufzuheben, warum soll es sich lohnen für ein virtuelles Modell ein noch abstrakteres virtuelles Modell zu machen? Wohl nur in wenigen Situationen: Schiere Kompliziertheit (z.B. eines Geschäftsprozesses) oder aber Komplexität des Gesamtsystems - wo sich, das habe ich ja vorhin schon geschrieben, Investitionen in das Design der Infrastruktur, Tools etc. lohnen, die eine gewisse Standardisierung erfordern, die wiederum codelos designt und dokumentiert werden muss - so generell bin ich nicht gegen codelos. Ich glaube nur, dass der Schwellwert für ein weiteres Werkzeug (ist auch Komplexität) recht hoch ist - es muss also offensichtlich notwendig sein um kontinuierlich angewandt zu werden. Und das ist es häufig nicht.
@pvblivs, @anonym,
die Darstellung von Ralf kann ich vollends unterstreichen. Das ganze Gedankengut rund um Agilität soll und darf nicht dazu führen, zu stark Code als Kommunikationsmittel zu sehen.
Ja, ich weiss, die Agilen MMF, kleine Produktinkremente, alles ist im Flow gemäß Business-Value. Aber was ist, wenn der Produktowner keine Strukturen "wert" schätzt? Hat das Team Gedanken über die Struktur der Inkremente, des immer größer werdenden Puzzles? Striktes TDD, KISS und YAGNY sind zu wenig, weil sie schlechte Strukturen ermöglichen könnten - was mittelfristig zu größeren Umbauten führen kann.
Einzig und allein Code "sprechen" zu lassen, habe ich bisher nicht erlebt - hingegen reicht es aber auch unzureichend zu glauben, Schichten sind ausreichend für eine oder gar die Architektur. UML ist kein Maßstab und keine Begründung nicht über Strukturen nachzudenken, zu skizzieren und Verbesserungen einzubringen.
Ich entdecke aber auch eine Diskrepanz: gröbere Strukturen (sofern kein Monolith) ändern sich gar nicht so stark, die kleinen Strukturen (der Feinentwurf, der Code) viel öfters. Warum hält man trotzdem immer an einer Lösung (z.B. eine Sprache) dauerhaft fest? Dort wo die Dynamik hoch ist, ist die Sturheit ebenso so hoch.
Wie können wir außer der Box denken? Woher wissen wir, dass Technologie X nicht doch besser ist bzw. sein könnte?
Antizipation, Teile-und-Herrsche, die Option zu haben/zu eröffnen und zu erhalten, bestimmte Teile in Zukunft zu ersetzen, zu erneuern, zu verteilen oder sonstwie änderbar zu haben, sind wichtige Elemente eines lebendigen Systems.
Der Grund der Abneigung gegen Ployglot ist meiner Meinung nach Angst. Die Angst der Menschen vor dem Neuen, dem Unbekannten, der Angst des Verlusts seines Wissens, seiner Kompetenz, weil man Gefahr läuft, nicht mehr als Experte sondern als Anfänger darzustehen. (so könnten Entwickler denken, insbesondere die älteren Semester). Aber ebenso ist die Angst bei den "führenden" zu finden. Die Angst vor dem Unbekannten, das haben wir immer so gemacht bzw. das Personal/Know-How scheint man nicht zu haben - oder nicht haben zu wollen? "Was Hänschen nicht lernt, lernt Hans nimmer mehr"?
Angst vor dem Ungwissenem. Erhalt des Status-Quo = Stillstand. Stillstand für Unternehmen ist Rückschritt.
Ja, eine Lernkurve ist zu durchschreiten: zuerst ist man langsamer. Unterschätzt wird aber, dass man Vorwissen mit bringt, jede neue Technologie (sofern passend) eröffnet einem Möglichkeiten und letztlich stellen sie einen Gewinn dar. Wenn nicht jetzt sofort, dann beim nächsten Wechsel.
Im Berufsalltag ist alles zäh und schwierig, angestaubt, manche Teile sind wie Museumsbesichtigungen, wie Telefone mit Wählscheibe. In der Open Source Welt ist die Dynamik viel höher, warum eigentlich? Ist das Business erzwungener Stillstand? Wieso ist das so? Wie gross müssenn die Schmerzen werden, bis das Unternehmen ausradiert ist? Habt Mut für Änderungen, jetzt und heute.
Java war in den ersten Stunden nicht auf der Serverlandschaft zu finden. Javascript wandert vom Frontend ist Backend. Vor 15 Jahren war NoSQL undenkbar als Ablösung von RDBMS. Die Hardware ist heute sehr leistungsfähig und eröffnet einem neue Möglichkeiten, zeitgleich hat sich das Volumen vervielfacht und Komplexität erhöht - sodass es immer noch ein schwieriger Weg ist. Aber daraus kann ich nicht ableiten, dass man immer an dem klebt, was vor 20 Jahren einmal zeitgemäß war.
Ich möchte drei Aspekte beitragen:
1) Ich könnte mir eine text basierte DSL für einen neutralen Entwurf sehr gut vorstellen. Ich finde 'texten'mit spezifischen Vokabular allemal schneller und konkreter als zeichenbasierte Darstellungen - wie UML.
Ausserdem kann das dann in jedem Editor gemacht werden.
Das würde aber ein allgemeines Interesse voraussetzen und das sehe ich nicht - wie Du ja erläutert hast ist gegenwärtig schnell loslegen und sofort Code schreiben 'angesagt'.
2)Marketing, Vertrieb und Presales Consultants. Die Plattformen werden doch oft genug 'in den Markt gedrückt',
die Kaufentscheidung im Management gefällt.
3) Zum Thema Vielsprachigkeit
Es werden wenige Menschen, die mit etwas anderem als der Softwareentwicklung Geld verdienen, mehrere Programmiersprachen lernen und Plattformen erforschen.
Bleiben die Professionellen. Die müssen ihre Fähigkeiten aber verkaufen. Schaue ich mir Stellenanzeigen und Projektangebote an, wird i.d.R. aber kein vielsprachiger Entwickler gesucht, sondern Leute, die auf feingranulare Anforderungen 'passen', bis hin zur Ausformulierung des Test-Stacks und der minor version no der Persistenzschicht.
Das passt nicht zueinander und hält eine Veränderung in Richtung Poly Plattform / polyglotte Entwicklung auf.
Joachim
@pvblivs: Ich plädiere nicht dafür, Entwürfe in großem Maßstab aufzuheben. Natürlich veralten die. Genauso wie eine Karte veraltet.
Es muss vielmehr leicht sein, die Abstraktion aus dem Konkreten wieder herauszulesen bei Bedarf. Das ist beim heutigen Vorgehen aber eher nicht möglich. Erstens, weil es keine Abstraktion/Entwurf gab. Zweitens weil die Umsetzung unsystematisch und verlustbehaftet ist.
@Anonym: Ein textbasierter Entwurf ist für mich eher kein hilfreicher Entwurf. Text hat einfach nicht soviele Freiheitsgrade. Ich möchte beim Entwurf nicht begrenzt sein in meinen Ausdrucksmitteln. Wenn ich malen will, dann will ich malen. Oder eine Formel hinschreiben mit mathematischer Notation. Oder eine Architektur mit Personen aufstellen. Oder oder oder.
Text limitiert schon beim Codieren genug.
"Oder oder oder."
Genau deshalb kommt das Thema auch nicht aus den Schuhen !
Der Spatz in der Hand ...
Nicht "oder oder oder" ist ein Problem, sondern die Suche nach der endgültigen Lösung für das Problem Modellierung.
Statt rumzusuchen und auf das finale Tool zu warten, sollte man lieber hier und heute anfangen, aus der selbstverschuldeten Sprachabhängigkeit rauszukommen.
Wie das gehen kann? Dazu habe ich ja schon tonnenweise hier Material vorgelegt. Damit muss man nur einfach mal anfangen und es ausprobieren. UML nicht zu benutzen, mit OOP nur irgendwie rumzuhüsern und auf irgendwas zu warten, hilft nicht.
Solange sich Design in der Branche heutzutage auf die Demonstration von TDD in einer konkreten Sprache beschränkt, wird nichts besser. Und der Verweis darauf, dass es mit UML und vorher CASE und letztlich auch mit MDSD heute nicht so recht einfacher geworden ist, hilft auch nicht.
Ich denke, die Probleme sind klar:
1. TDD skaliert nicht und ist sprachabhängig. Mit TDD kann nur einer zur Zeit Design betreiben.
2. UML ist unhandlich groß. Und es fehlt eine Methode, damit von Anforderungen zu codierbaren Funktionseinheiten zu kommen. Daher wird UML höchstens bei 10% der SWentwickler eingesetzt.
3. MDSD funktioniert in manchen bereichen, ist aber sehr werkzeuglastig und vorbereitungsintensiv (Stichwort DSL-Entwurf). Damit ist MDSD zumindest für mich noch auf lange Sicht keine Hilfe für plattformneutrales Nachdenken über Code.
Was wir also brauchen ist eine skalierbare und leichtgewichtige Methode, die ohne großen Werkzeugeinsatz und Vorbereitung auskommt. Und die sollte auch noch zur Agilität passen.
Lock-In hat aus meiner Erfahrung heraus noch zwei ganz andere Gründe, nämlich Geld und Hörigkeit auf Mangementebene.
Ich habe 10 Jahre als Entwicklungsleiter und Softwarearchitekt in verschiedenen Firmen sowohl im In- als auch im Ausland gearbeitet. Das Verständis der Mangamentment-Schicht - besser gesagt - der Budget-Verteiler-Schicht-Bestimmer geht für Lizenzkosten gegen null. Warum den "schon wieder Geld ausgeben, VS 2005 tut's doch noch." Das ist übrigens ein Zitat von einem hochrangigen Budget-Bestimmer in einem großen Unternehmen ... 2010! - gruselig, oder?
Zum zweiten ist da die Management-Hörigkeit gegenüber einem bestimmten Software-Lieferanten. Hat man sich für MS entschieden, "darf" man halt kein Java cool finden - und natürlich umgekehrt. Bedauerlicherweise scheint es so zu sein, dass das Verständnis für Softwareentwicklung doppelt so schnell abnimmt, wie die Budget-Verantwortung zu.
Meiner Beobachtung nach kommen diese Verhalten noch stärker zum Tragen, je mehr die Kernkompetenz des Unternehmens nicht auf Software-Entwicklung ausgerichtet ist.
Ein weiteres Beispiel: Projekt bei einer großen deutschen Bank - Name darf ich logischerweise nicht nennen :-)
Kernkompetenz: Versenken von Kundengeldern
Software-Entwicklung: .NET 1.1, weil man ja die ganzen Controls, die man so gekauft hat, nicht umstellen kann. Neuere Versionen kosten Geld, ganz zu schweigen von den Entwicklungsumgebungen.
Es wurde eine Kommission von Nicht-Software-Entwicklern eingesetzt, die eine Untersuchung angestellt haben, wie hoch denn die zu erwartenden Kosten der Aktualisierung auf (damals .NET 3.5)sein würden.
Ergebnis: Die entwickler total verzweifelt, die wollten gerne was neues
Das Mangement: Zu teuer, lohnt sich nicht, da die Software nach der Umstellung ja nichts neues kann. "Und schließlich verdiene man ja sein Geld nicht mit der Software, sondern mit den Geldanlagen der Kunden"
Externer (ich): Mir war es letztendlich egal, denn ich wurde gut bezahlt, und in einer anderen Firma hab ich dann halt andere Umgebungen, Sprachen, etc. Bleibe also am Ball :-)
Fazit: Oft sind die Bremsen nicht die Entwickler, sondern die, die keine Ahnung haben. Als entwickler mit Familie überlegt man es sich allerdings dreimal, ob der (vermeintlich) sichere Arbeitsplatz eine Diskussion mit dem Vorgesetzten und / oder eine neue Stelle wert ist ...
entwickler -> Entwickler ... da war wohl meine Tastaturkartusche leer ;-)
>Kaum ein Schriftsteller würde ja auch auf die Idee kommen, in einer Fremdsprache zu schreiben
so ist das eben... Ein z.Bsp. technischer Softwareentwickler hat fast immer ein riesiges Domain(en)-Wissen entwickelt (Sprache 2), welches er mit Sprache 1(.Net xx, c, c++)
ausdrueckt und zum Laufen bringt und auch dokumentiert! Er mag ja nicht der grosse Speci fuer C# sein und es waere kontraproduktiv, noch eine Sprache 3 zur Modellbeschreibung zu erlernen bzw. damit sein Domainen-Wissen darzustellen.
Er ist einfach ein Spezialist, der mit einer Sprache sein Ziel erreichen muss.
Lieber Ralf,
vielen Dank für den Artikel. Ich habe die Erfahrung gesammelt, das angestellte (freiberufliche?) Entwickler sich mit zunehmendem Alter immer stärker auf die Nutzung der Axt konzentrieren und das Reflektieren des Entwurfs-/Planungs- sowie Produktionsprozesses kaum noch stattfindet. Ein Grund dafür ist ganz klar das Fehlen einer entsprechenden Kultur. Zu wenige sehen einen Wert in der Nutzung einer abstrakten Formulierung der Probleme. Das wiederum ist bedingt durch das Fehlen von Übung (viele können es auch nicht) und oder der Suche nach irgendwelchen Superwerkzeugen, anstatt einfach die heute schon existierenden Möglichkeiten (Diagramme, Grafiken, Pseudocode) einfach zu nutzen.
Gruß
AndreasW
@Chris: Ob jemand auf Deutsch oder Englisch über Entwurf spreche, ist der Sache egal. Wenn man Deutsch oder Englisch gut kann, dann kann man ausdrücken, was auszudrücken ist.
Deutsch eine eventuelle Entwurfssprache sind orthogonal. In einer Dimension (natürliche Sprache oder Entwurfssprache) kann man wechseln.
Und auch Sprachen dazu lernen, wenn sich dadurch weitere Dimensionen auftun, ist sinnvoll.
Das bedeutet: Es mag einer eine Domänensprache kennen. Und der mag dann auch noch eine Codierungssprache kennen. Und er spricht auch noch Deutsch. Dann ist es nicht überflüssig, auch noch eine Entwurfssprache zu lernen. Das ist ja gerade mein Punkt. Die Entwurfssprache verfolgt einen anderen Zweck als die Domänensprache und die Codierungssprache.
Englisch verfolgt keinen anderen Zweck als Deutsch. C# keinen anderen als Java. Aber UML verfolgt einen anderen Zweck als C# oder Deutsch.
Es geht um die richtige Sprache für den richtigen Job. Und die fehlt. Es wird eine Codierungssprache wie C# mit ein paar Hilfsmitteln missbraucht, um das zu leisten, was eine Entwurfssprache will.
Das halte ich für einen Übelstand. Mit der Krücke humpelt die Softwareentwicklung nur voran.
"Von Paradigma würde ich da gar nicht sprechen."
Ralf, Deine Bescheidenheit in Ehren, aber was Du (zusammen mit Stefan?) erfunden hast, trägt meiner Meinung nach schon alle Merkmale eines neuen Design-Paradigmas. Gerade weil es unabhängig von der jedweder Programmiersprache ist, deutet es auf ein neues Paradigma hin.
In Deinen Artikeln propagierst Du ja auch immer wieder einen Paradigmenwechsel in der Design-Methodik. Und ja, - aus den Erfahrungen die ich mit dieser Methodik bis jetzt gemacht habe - es "fühlt" es sich an, wie der nächste qualitative Sprung in der Software-Design-Methodik, eben ein Paradigmenwechsel.
Bei objektorientierten Design-Paradigma war es auch ähnlich. Es war sprachunabhängig, man konnte es mit imperativen Sprachen genauso realisieren, wie mit objektorientierten. Natürlich war es sehr viel aufwendiger ein objektorientiertes Design mit C umzusetzen, weil eben Compiler und Laufzeitsystem kaum eine Hilfe waren. Man musste viel von Hand programmieren. Aber genau dies war doch auch, in meinem Verständnis, die Motivation eine Flow-Runtime für das Flow-Design zu realisieren; um sich immer wiederkehrende Implementierungsdetails zu ersparen und per deklarativer Spezifikation Übersichtlichkeit und Lesbarkeit zu gewinnen.
Eine Laufzeitumgebung für das Flow-Design-Paradigma gibt es also schon (zumindest für .NET). Fehlt noch die erste Flow-Design-Sprache...
In diesem Zusammenhang experimentiere ich gerade mit Scala, wo man recht geschickt über interne DSLs neue Sprachkonzepte integrieren kann. EBC-ähnliche Konstrukte zusammen mit einer Flow-Port-Verknüpfungssprache, die der von Dir benutzten Flow-Spezifikationssprache gleicht, funktionieren schon recht gut. Die EBCs sind sogar wesentlich kompakter zu realisieren als in C#. Bis zur Flow-Runtime ist es aber noch ein gutes Stück.
@anonym1: So gesehen wäre eine erfolgreiche Realisierung in Scala ein Hinweis (vielleicht sogar Beweis), dass die von Ralf propagierte Methodik plattformunabhängig ist. Aber es gibt auch jetzt schon andere Hinweise ob der Plattformunabhängigkeit. http://blog.jebc.de/ zeigt eine Realsierung in Java. Ralf hat vor kurzem eine Realisierung für Ruby gezeigt. Auch wenn man die Artikel von Ralf liest, merkt man, dass die Methodik plattformneutral ist. Ich bin z.B. eher auf der Java-Plattform unterwegs und die Flow-Design-Methodik funktioniert für mich auch dort. OK, es fehlen noch Werkzeuge, aber das tut der Validität der Methodik doch keine Abbruch, es macht nur mehr Arbeit bei der Implementierung, dafür hilft es ungemein beim Design.
@Denis: Danke für die Blumen ;-)
Flow-Design ist natürlich plattformneutral.
Und eine Runtime ist nicht nötig. Flow-Design lässt sich mit (fast) jeder Sprache realisieren.
Ob wirklich eine textuelle DSL nötig ist... Ich weiß nicht. Mit der Flow Runtime habe ich in dieser Richtung experimentiert. Das funktioniert recht ordentlich. Inzwischen bin ich aber wieder zurück bei der Übersetzung nach Methoden und EBC. Jenachdem, was am besten passt.
Damit ist auch die Einstiegshürde so niedrig wie möglich. Die Lesbarkeit des Codes ist hoch. Ich kann aus ihm ohne Probleme das Modell herauslesen.
Also: Malen am Whiteboard, 1:1 übersetzen in Code, Malerei archivieren oder wegschmeißen. So können Modell und Code auch nicht aus dem Tritt geraten. Der Code ist die Wahrheit - aber in systematischerer Weise.
Kommentar veröffentlichen