Viele Projekte, viele Sprachen

Wenn man vor der Aufgabe steht, ein Projekt umzusetzen, stellt sich oft die Frage nach der genutzten Programmiersprache. Mitunter entstehen wilde Diskussionen zu diesem Thema. An dieser Stelle auch einen Dank an meine Kollegen für die angeregten Gespräche. Wenn man sich Projekte näher anschaut, kann man sehen, dass in Projekten oft viele verschiedene Sprachen zum Einsatz kommen. Teilweise kommen diese dabei implizit zum Einsatz, z. B. Skriptsprachen für Deployment, Installer oder Tests, manchmal explizit, wenn verschiedene Microservices in unterschiedlichen Sprachen realisiert wurden.

Aus Sicht eines Entwicklers ist es angenehm und hilfreich, wenn man mit Kollegen auf ähnlichem Niveau über Probleme und Sonderfälle reden kann. Das allein führt schon zu einer Spezialisierung innerhalb einer Gruppe von Entwicklern. Andererseits erlaubt der Austausch mit Entwicklern aus völlig anderen Sprachgebieten auch den Blick über den Tellerrand hinaus. Dies hilft ungemein, um dem täglichen Trott wieder zu entkommen und vielleicht auch neue Konzepte in der eigenen Sprache zu entdecken, die man bisher nicht genutzt hat.

Aus Sicht des Unternehmens kann der Einsatz von mehreren Sprachen sogar nötig sein, z. B. wenn die unterschiedlichen Problemstellungen dies erfordern. Zusätzlich bietet dieses Vorgehen die Möglichkeit, auf ein breiteres Spektrum an Mitarbeitern zugreifen zu können. Ein Nachteil beim Einsatz von verschiedenen Programmiersprachen ist, dass bei größeren Problemen das vorhandene Know-how nicht mehr ausreichen kann, um die Probleme hausintern lösen zu können. Hierzu sind dann oft externe Spezialisten notwendig, die – sofern überhaupt verfügbar – einen Einfluss auf Zeitplan und Budget des umzusetzenden Projektes haben.

Bei kleineren Firmen droht der Know-how-Verlust, wenn einzelne Mitarbeiter das Unternehmen verlassen. Gerade bei etwas selteneren Programmiersprachen kann dies zum Problem werden, da nicht schnell genug passende Mitarbeiter gefunden oder geschult werden können. Aus Sicht des Projektes kann der Einsatz verschiedener Sprachen die Möglichkeit bieten, gewisse Aufgabenstellungen besonders zeiteffizient zu lösen. Vor allem im Bereich systemnaher Entwicklung kann dies dazu führen, dass etwas mehr Aufwand z. B. in andere Hardware oder zusätzliche Software investiert werden muss. Trotz der Verlockungen von neuen Sprachen sollte trotzdem die Einarbeitungszeit in die neue Sprache sowie der Erfahrungsschatz des Entwicklers in Relation zum geplanten Projektumfang und zur Projektdauer gestellt werden. Neue Sprachen werden oft aufgrund der offensichtlichen Anforderungen ausgewählt und können dort ihre Stärken auch ausspielen. Erfahrungsgemäß gelangt man aber früher oder später in Projekten an den Punkt, an dem etwas nicht mehr so einfach ist wie ursprünglich gedacht. Manchmal fällt dann der Satz: "Also das wäre mit der alten Sprache einfacher gewesen."

Aus Sicht des Kunden wächst mit jeder eingesetzten Programmiersprache zuerst die Flexibilität beim Zugriff auf Entwickler. Gleichzeitig steigt jedoch auch die Komplexität im Projekt. Um der steigenden Komplexität entgegenzuwirken, sollte hier dann die alte UNIX-Philosophie "Do one thing well" gelten mit einem Zusatz "and add clear and comprehensive APIs". So können spätere Erweiterungen einfacher aufeinander aufbauen, unabhängig davon, welche Sprache eingesetzt wird. Dies ist vor allem dann wichtig, wenn davon ausgegangen werden kann, dass der entsprechende Code oder das entsprechende Produkt über viele Jahre hinweg eingesetzt werden soll.

Gerade bei Beauftragung von externen Dienstleistern sollte man sich als Kunde dann die Frage stellen, ob man den zu entwickelnden Code später auch selbst warten oder erweitern können möchte. Hierzu sollte nicht auf das günstigste Angebot geachtet werden, sondern vielmehr eine langfristige und vertrauensvolle Partnerschaft zwischen Dienstleister und Auftraggeber angestrebt werden.

Ausreichend große Projekte werden immer mit vielen Programmiersprachen zu tun haben. Dies bringt mehr Komplexität ins Spiel, hilft aber der Langlebigkeit des Projektes, weil immer wieder Entwickler unterschiedlicher Art mitarbeiten. Andernfalls würden wir die Geschichten der Bankensoftware mit COBOL und RPG nur wiederholen. Ein Verschließen vor Neuerungen bringt langfristig nur Probleme und führt zu Isolation.

Durch die Nutzung von Microservicearchitekturen wird die Anzahl der Projekte mit vielen verschiedenen Programmiersprachen vermutlich stärker zunehmen als bisher. Wenn die Schnittstellen hier gut definiert sind, können solche Projekte lange ohne umfangreiches Redesign überstehen.

Unabhängig davon werden sich auch die neuen Generationen von Entwicklern für "neue" Programmiersprachen und Konzepte interessieren und diese dann in die bestehenden Projekte einbringen. Und mit den passenden Schnittstellen ist das auch gut so.

For fun: Wem "COBOL", "RPG" oder auch "Brainfuck", "Whitespace" und "Omgrofl" nichts sagen, findet hier eine Liste sehr vieler verschiedener Programmiersprachen: www.99-bottles-of-beer.net