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.