Auch wenn dies meinen Ruf als .NET- und Java-Programmierer und Hardcore-Coder der alten Schule womöglich vollständig ruiniert, möchte ich Ihnen von meiner kuriosen Liebesgeschichte mit Low-Code erzählen.

hero-bp-from-java-to-low-code-integrations

Inhalt:


Der Weg zum Hardcore-Coder: Baby Steps

In meiner Kindheit gab es ein Ereignis, das mein Leben für immer verändern sollte. Eines Tages brachte mein Vater einen ZX Spectrum mit nach Hause. Mein Schicksal als Hardcore-Coder war besiegelt.

Nicht lange nachdem ich mich mit dem ZX vertraut gemacht hatte und in den Speccy-Spiele zum Ass geworden war, begannen mein Vater und ich, Code aus Büchern und Zeitschriften abzuschreiben. So habe ich BASIC und Assembly gelernt. Das mühsame Abschreiben von Hand führte dazu, das ich den Code nach und nach verstand. Schließlich habe ich den Code eingegeben und gebetet, dass er funktioniert: RUN, ENTER... Das war nicht immer der Fall. Und dann war Debuggen angesagt.

In der High School spielten ein paar Freunde und ich mit verschiedenen leistungsfähigeren Maschinen: dem Atari 800XE, dem Atari ST, dem BBC Micro und dem MSX. Viele von ihnen landeten später im IT-Bereich.

Als ich an die Uni kam, lernte ich, wie man mit Modula-2 (ziemlich genau basierend auf PASCAL), Java und C++ arbeitet. Und so kam ich zum ersten Mal mit dem neuen Konzept der objektorientierten Programmierung in Berührung.

Wie ich mit KISS gearbeitet und mich allem Debugging zum Trotz mit Objekten versöhnt habe

Nach einigen nächtlichen Coding-Jobs bekam ich schließlich genau zur Jahrtausendwende meine erste richtige Stelle in der IT bzw. als Programmierer. Aus irgendwelchen Gründen wurde ich zum Verantwortlichen für die Pflege des Firmen-Intranets. Dann kam der Tag, an dem ich es schaffte, als Super User das gute alte Killer-Kommando zu verwenden:

rm -rf

Remove. Recursive. Forced. Der absolut sichere Weg zur Katastrophe.

Ich geriet in leichte Panik. Das Schlimmste an der ganzen Sache – bzw. die Gelegenheit, auf schmerzhafte Art und Weise zu lernen – war, dass die Backups das System nicht in seinen früheren Zustand zurückversetzten. Also musste ich die Ärmel hochkrempeln und das Intranet neu aufbauen. In einer Nacht. Ich habe es geschafft, aber es war hart. Ich wäre damals gerne in der Lage gewesen, das Problem schneller zu lösen.

Ich erinnere mich an ein anderes Projekt, bei dem ich eine Schicht über dem ursprünglichen Code programmieren musste, weil der Kern einfach zu unflexibel und bizarr war. Das lag daran, dass er mit der KISS-Methode implementiert worden war. Wobei KISS in diesem Fall für Keep It Simple and Stupid stand.

Alles war ein Objekt und ich meine wirklich alles. Normalerweise wird die Grenze bei ganzen Zahlen und Zeichenketten gezogen, aber im Code dieses Projekts war sogar ein Buchstabe ein Objekt. Das bedeutete: Bis die richtige Methode gefunden war, musste man sich durch zig Klassen kämpfen. Das war der Moment, in dem ich mich zu fragen begann, ob die objektorientierte Programmierung wirklich die Wunderwaffe ist, als die sie in aller Munde war. Und wenn ja, warum war dann so viel Debugging nötig?

Chaos Monkeys: Der Übergang zu Low-Code

Ich hatte größte Hindernisse überwunden und hätte über den Dingen stehen sollen. Dann wuchs das Unternehmen, für das ich arbeitete, sehr schnell und wurde von einem noch größeren Unternehmen aufgekauft. Und damit begann für mich als Java-Programmierer und Hardcore-Coder eine Achterbahnfahrt der Sorgen und Zweifel.

Schließlich fand ich mich mit einem befristeten Vertrag bei einem Nicht-IT-Unternehmen wieder. Als der Vertrag endete, fragte ich, ob man mich direkt einstellen könne. Das wollte das Unternehmen gerne tun, aber es gab einen Haken. Ein anderes Unternehmen hatte es gekauft! Zum Glück hat mich das andere Unternehmen eingestellt. Zu dieser Zeit arbeitete ich wohlgemerkt noch immer an demselben Projekt. Ein typisches Beispiel für die damals so tragisch langen Vorlaufzeiten von Projekten.

Dennoch war mein Unternehmen zufrieden, und ich auch. Bis die vermeintliche Katastrophe eintrat.

Wie Low-Code meine Karriere nicht ruiniert hat

Mein Unternehmen wollte Wege finden, noch mehr aus meiner Arbeit herauszuholen. Es wollte meine Programmierfähigkeiten optimieren und mir helfen, effizienter zu werden. Und so kam es, dass ich zu einem OutSystems Bootcamp geschickt wurde. Mein Unternehmen hatte gehört, dass hier die Zukunft der Programmierung vermittelt wurde und die Methoden weit über die üblichen objektorientierten Programmiersprachen hinausgehen.

Bei mir wurden sofort alle möglichen Alarme ausgelöst. Low-Code? Wie kann etwas, das meinen handgeschriebenen, wertvollen Code verschleiert, gut für mich sein? Ich wusste einfach, dass dabei Code herauskommen würde, der schlimmer war als der, den Frontpage produzierte. Wahrscheinlich mit 10-mal mehr HTML als nötig.

Ich war mir sicher, dass meine Karriere als Hardcore-Coder, auf die ich so stolz war, hiermit abgeschlossen war.

Die Bombe

Doch im Zuge des Bootcamps räumte OutSystems mit all meinen Vorurteilen über Low-Code auf. Ich stellte schnell fest, dass ich die Low-Code-Funktion für Abstraktion und Funktionalität nutzen und sie dennoch mit meinem C#-Code erweitern konnte.

Meine große Sorge – „Was würde passieren, wenn ich an die Grenzen der Plattform stoße?“ – war damit vom Tisch. Ich hatte nicht viel über Low-Code gewusst. Aber ich dachte, dass es einen Punkt geben muss, an dem ich gegen eine Wand stoßen würde. Falsch.

Mit OutSystems kann ich einfach Komponenten mit meinem bevorzugten Code erstellen. Dabei wird jede als DLL bzw. JAR bereitgestellt, gekapselt in einer wiederverwendbaren Erweiterungskomponente. Für Low-Level-Integrationen müssen Sie nur einmal mit Visual Studio programmieren und das Ergebnis als OutSystems-Komponente abstrahieren. Dann können Sie es mit der visuellen IDE von OutSystems immer wieder weiterverwenden.

Ein Plutonium Award

Ich finde die Lösung elegant. Und noch besser: Sie funktioniert. Ich kann meine Systeme integrieren – und sogar meine Nemesis, die böse Datenbank. Wenn Integration Studio eine Atombombe wäre, dann wäre die Datenmodellierung ihr Plutonium. Die Einrichtung zur Nutzung meiner externen Datenbanken erfolgt einmalig in OutSystems, und das war's.

Nachdem ich aus dem Bootcamp zurückgekehrt war, wagten mein Unternehmen und ich unser erstes richtiges Projekt mit OutSystems, das uns uns gleich eine Auszeichnung einbrachte. Und das war erst der Anfang. Wir ließen uns zertifizieren und erstellten Projekte. An diesem Punkt hatte ich eine Eingebung: Wenn man ein guter Entwickler ist, führt Low-Code einfach schneller zum Endergebnis.

Letztlich trifft es durchaus zu, dass Low-Code meine Karriere als Hardcore-Coder „ruiniert“ hat. Nur nicht so, wie ich es mir vorgestellt hatte.

Ist Low-Code eine Wunderwaffe? Nicht ganz, aber fast

Aus irgendeinem Grund erfindet die IT das Rad etwa alle zehn Jahre neu. Im Fall von Low-Code handelt es sich um einen großen Schritt – und ich bin gespannt, wie es weitergeht. Momentan höre ich viel zum Thema Cloud-Native, was die Low-Code-Welt noch weiter öffnen wird.

Schauen Sie sich zum Beispiel an, was OutSystems im Mobile-Bereich bewirkt hat. Mobile Entwicklung – das ist wirklich Hardcore! Glücklicherweise war OutSystems hier von Anfang an voll dabei und ist es immer noch. So bin ich zum Mobile-App-Entwickler geworden, indem ich dasselbe Tool genutzt habe, das ich seit Version 4.2 nutze.

Mittlerweile bin ich voll und ganz auf den Low-Code-Ansatz eingestellt und liebe ihn.

Lassen Sie uns weiter nach vorn schauen und uns auf die Zukunft freuen!