Sag mal...

Alles kann, nichts muss – Wie ist das eigentlich mit Innovationen?

Niko Köbler, Carina Schipper

© Shutterstock / Olivier Le Moal

Innovationen sind richtig und wichtig – keine Frage. In der Welt der Softwareentwicklung rollt ständig eine ganze Flut Neues auf uns zu: hier ein neues Framework, da eine neue Bibliothek. Da den Überblick zu behalten, ist alleine schon schwer. Bei einer Tasse Kaffee haben wir uns neulich gefragt, wie das mit den Innovationen eigentlich ist. Wie sollte man mit dem ganzen „heißen Sch…“ denn überhaupt umgehen? Über was sollte man sich da Gedanken machen?

Carina: Sag mal, Niko, wie ist denn das eigentlich mit diesen ganzen technischen Neuerungen? Eine Innovation jagt die nächste – sieht man da den Wald vor lauter Bäumen überhaupt noch?

NikoTechnische Innovationen sind ja per se erst mal was Gutes. Zeigt es doch, dass noch nicht alle unsere Herausforderungen gelöst sind – was ja auch irgendwie langweilig wäre. Gleichzeitig fallen cleveren Menschen immer neue Anforderungen ein, die dann ja auch irgendwie gelöst werden müssen, so entsteht die nächste Innovation. Das ist ja das Schöne an den meisten Frameworks, Bibliotheken und Lösungen: Sie entstehen nicht, weil irgendjemandem langweilig ist. Ja, es gibt auch Sachen, die entstehen, weil es geht, nicht weil es sinnvoll ist. Wie sagt man so schön: „Just because Because!“ Das ist aber glücklicherweise die Minderheit und kann und sollte vernachlässigt werden. Sehr gut sagt das auch dieser eine Tweet aus, über den ich letzt gestolpert bin:

Müssen wir wirklich, nur weil wir es können? (Quelle: https://twitter.com/miss_jwo/status/978560169805271041)

Je mehr Lösungen auf dem Markt sind, desto anspruchsvoller wird es natürlich, hier den Überblick zu behalten. Wichtig ist, sich ständig zu informieren, was es denn Neues gibt, und wo die Entwicklung hinläuft, um für zukünftige Anforderungen und Entwicklungen gewappnet zu sein. Dieses Wissen muss allerdings nicht in aller Tiefe für alle neuen Produkte gleich zu Beginn erarbeitet werden. Hier reicht viel mehr ein „ich hab da mal was über eine Bibliothek XY gelesen, die soll sowas können, was wir suchen“. Dann kann man sich zum gegebenen Zeitpunkt immer noch um die Details kümmern.

Carina: Also ist alles Neue erst einmal mit Vorsicht zu genießen? Freust du dich nicht, wenn du neue Dinge ausprobieren und in einem Projekt anwenden kannst?

Niko: Doch, prinzipiell freue ich mich über neue Spielzeuge (Bibliotheken, Frameworks, was auch immer) natürlich schon. Doch man muss die Dinge mit Vorsicht genießen und abwägen, ob es das Richtige ist. Nehmen wir zum Beispiel die ewige Diskussion über das richtige Schnittstellenprotokoll. Soll es SOAP sein oder doch lieber REST? Um hier weiter diskutieren zu können, müssen wir wissen, dass SOAP überwiegend einen RPC, Remote Procedure Call, also einen Aufruf einer entfernten (nicht auf dem auslösenden System befindlichen) Prozedur, abbildet. REST dagegen hantiert mit Ressourcen.

Irgendwann hat jemand gesagt, dass REST besser ist als SOAP (SOAP hat zudem einiges suboptimal umgesetzt), außerdem wäre JSON ja ein viel besseres, weil leichtgewichtigeres Datenformat. Fazit: Alle rennen dieser einer Aussage hinterher und versuchen, ihre RPCs über REST abzudecken, was nur schieflaufen kann. Und warum? Weil sie blind irgendeiner Aussage vertraut haben, ohne sie zu hinterfragen. Es ist ja was Neues, also muss es gut sein. RPC über HTTP mit XML oder JSON ist per se nichts Schlechtes und in vielen Fällen das, was die Unternehmen eigentlich machen.

Das gleiche Verhalten kann ich derzeit bei Webanwendungen beobachten. Es gibt einen ganz speziellen Teil von Webanwendungen, die eine hohe Anzahl von Anfragen und große Datenmengen verarbeiten müssen können. Dies soll möglichst nicht blockierend geschehen, um die zur Verfügung stehenden Ressourcen bestmöglichst ausnutzen zu können. Hier setzen sich zunehmend reaktive Ansätze durch, und die Anbieter der Reactive-Frameworks werden nicht müde, zu proklamieren, dass das jetzt das einzig Richtige ist, wenn man Webanwendungen entwickelt.

Reaktivität und Asynchronität sind eine tolle Sache, doch sind viele Anforderungen von Unternehmensanwendungen noch lange nicht an dieser Stelle angekommen und bedienen sich weiterhin dem üblichen Request-Response-Prinzip der guten alten Servlet-Technologie. Das halte ich auch für völlig in Ordnung, wenn ich eine reine Intranetanwendung baue, in die meine Anwender ein paar Daten eingeben und diese wieder dargestellt werden. Der Flaschenhals ist hier meist nicht das vermeintlich langsame und blockierende, weil „alte“ Servlet, sondern ganz banale Programmierfehler der Entwickler, die ohne Tests ihre Geschäftslogik entwickeln.

Aller guten Dinge sind drei – nehmen wir Kafka. Kafka ist ein tolles Werkzeug, um sehr umfangreiche Datenströme zu bearbeiten und von A nach B zu schicken. Ich mag Kafka sehr, wenn denn wirklich die Anforderungen da sind. Leider sehe ich in der Praxis oftmals, dass Kafka für ein Messaging eingesetzt wird, wo es auch eine gute alte JMS Queue getan hätte – eine Technologie, in der also das Know-how bereits im Haus für Entwicklung und Betrieb ist.

Aber nein, Kafka ist das Neue, das Tolle, und irgendjemand hat gesagt, „dass man das jetzt so und damit macht“. Also wird sich so eine Abhängigkeit, um nicht gleich von technischer Schuld zu sprechen, ins Haus geholt. Dafür gibt es kein bis wenig Know-how und es wird auch nicht aufgebaut, da für so etwas ja nie Zeit und Geld da sind. Die Projektdeadline winkt ja schon am Horizont. Ergo: Das kann nur schief gehen.

Ich könnte hier jetzt noch ewig weiter erzählen, zum Beispiel über Container, Docker und Kubernetes, weil alle nur noch Cloud-native sein wollen, ohne zu wissen, was dahintersteckt.

Carina: Wow, das klingt, als würden sich viele einfach blindlings auf den „hot shit“ stürzen, ohne darüber nachzudenken, was sie damit eigentlich bezwecken wollen. Dabei ist doch das die wichtigste Frage, oder? Stell dir mal vor, ich kaufe mir ein High-End-Rennrad, will aber eigentlich nur spazieren fahren. Während ich so cruise, stelle ich allmählich fest, dass es für diesen Zweck auch bequemere, sprich geeignetere Fahrräder gibt. Ja, ich habe sogar das alte Fahrrad meiner Oma noch in der Garage stehen. Da nehme ich doch lieber das her, um spazieren zu fahren. Was meinst du, warum rennen die Leute immer dem Neuen hinterher und schauen nicht zuerst einmal, was sie mit dem „Alten“ anfangen können?

Damit lässt sich cruisen. (Quelle: S&S Media)

Niko: Die „alte“ Technologie liefert eine breite Basis, mit ihr können die berühmten 80 Prozent der Anforderungen abgedeckt werden. Da diese Technologien bereits seit langer Zeit auf dem Markt sind, sind sie bewährt, erprobt, es gibt ausreichendes Know-how, Support, Entwickler und was weiß ich nicht noch alles. Alt heißt also nicht zwingend schlecht – eine gewachsene und funktionierende Technologie wird ja meistens noch weiterentwickelt, um sich den modernen Anforderungen anzupassen.

Vielleicht ist es hier und dort mal etwas komplizierter, das Gewünschte zu erreichen, dennoch kommt man ans Ziel. Würde man die Möglichkeiten, die die bewährten Technologien bieten, mit menschlichen Fähigkeiten vergleichen, würde ich das am ehesten als T-shaped bezeichnen, es ist also gleichermaßen möglich, in die Breite wie auch in die Tiefe zu gehen.

Neue Technologieansätze lösen oft nur ein ganz bestimmtes Problem, das aber sehr effektiv und effizient gleichzeitig. Dafür ist aber viel neues Know-how notwendig, das erst aufgebaut werden muss. Vergleiche ich das wieder mit den menschlichen Fähigkeiten, so käme ein I-Shape dabei raus, also die Möglichkeit, sehr schmal in die Tiefe zu gehen.

Carina: Ha! Ich sehe das Problem. Die Leute sehen, sinnbildlich gesprochen, nur, wie schön ihr neues Rennrad glänzt. Herrlich, wie man sich drin spiegeln kann. Allerdings denken sie dabei keine Sekunde darüber nach, was noch alles am Rennradfahren hängt. Rennradreifen und Schotterwege vertragen sich zum Beispiel weniger gut. Springen wir zurück in die Tech-Welt. Ich stelle mir gerade die Frage, ob es nicht auch Situationen gibt, in denen es genau anders herum ist. Ein Team klammert sich, warum auch immer, an seiner „alten“ Lösung fest. Die läuft ja, und dann kann ja nichts schief gehen. Zentnerschwere Datenbanken fallen mir da ein.

Niko: Na klar. Nehmen wir gleich noch mal Kafka, denn Kafka ist, wie gesagt, ein tolles Werkzeug. Es gab bei einem Kunden eben genau die Anforderung, sehr viele Ereignisse, die von verschiedenen Systemen erzeugt wurden, zu verarbeiten, zu aggregieren und zu speichern. Weiterhin sollten die Rohdaten auch zu späteren Zeitpunkten noch mal neu in einem anderen Kontext berechnet und an andere Zielsysteme ausgeliefert werden können.

Ein Projektmitglied schlug daraufhin Kafka als mögliche Lösung vor. Leider war der Rest des Teams und vor allem der Betrieb des Kunden sehr beratungsresistent und beharrte auf der „bekannten“ Lösung einer sehr schwergewichtigen relationalen Datenbank. Das war natürlich sehr schade, da die Datenverarbeitung und -speicherung letztendlich viel komplizierter und langsamer wurde. Hätte man hier den neuen heißen Sch… verwendet, wäre das nicht passiert und das Projekt wäre erfolgreicher gewesen.

Oder auch vor Kurzem wieder erlebt: In der Java-Anwendung muss ein Templating-Mechanismus eingesetzt werden. Templating ist jetzt nichts, was spektakulär spannend ist, und die Anforderungen gibt es schon ewig. Deshalb gibt es auch schon ewig Frameworks, die das sehr solide können. Leider werden diese Frameworks aber nicht mehr großartig weiterentwickelt, da sich an den grundsätzlichen Templating-Anforderungen ja nichts ändert.

Gleichzeitig bringen diese Frameworks aber auch eine ganze Armada an Abhängigkeiten (Bibliotheken aus anderen Projekten) mit, die ich eigentlich gar nicht in meinem Projekt haben möchte, oder die sogar zu Problemen mit meinen eigenen Abhängigkeiten führen. Zudem haben sich Einflüsse und Lösungen aus anderen Programmiersprachen im Templating mittlerweile als besser handhabbar herausgestellt und auch in das Java-Ökosystem Einzug gehalten. Man muss diese Bibliotheken nur kennen und auch nutzen und nicht, „weil ich es immer schon so mache“ auf die fünfzehn Jahre alte Lösung zurückgreifen.

Carina: Ich werde das Gefühl nicht los, dass viele allzu schnell dabei sind, in schwarz und weiß aufzuteilen.

Niko: Leider ist diese zweigeteilte und oft gegensätzliche Resistenz gegenüber dem Neuen oder dem Etablierten sehr oft anzutreffen. Die Bereitschaft, sich zunächst mal mit der Fachlichkeit auseinanderzusetzen und dann gemeinsam zu entscheiden, welche Anforderungen mit welcher Technologie umgesetzt werden und welche Kompromisse getroffen werden (müssen), tendiert sehr oft gegen null. Dies ist letztendlich nicht nur schädlich für die Projekte und Produkte, für die wir arbeiten, sondern auch für uns selbst.

Sag mal…
In der Reihe „Sag mal…“ kommentieren Java-Magazin-Redakteurin Carina Schipper und Software-Architekt Niko Köbler verschiedene Themen aus der Welt der Softwareentwicklung.
Geschrieben von
Niko Köbler
Niko Köbler
Niko Köbler ist freiberuflicher Software-Architekt, Developer & Trainer für Java & JavaScript-(Enterprise-)Lösungen, Integrationen und Webdevelopment. Er ist Co-Lead der JUG Darmstadt, schreibt Artikel für Fachmagazine und ist regelmäßig als Sprecher auf internationalen Fachkonferenzen anzutreffen. Niko twittert @dasniko.
Carina Schipper
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: