24 Mrz

Entwickler schaffen sich ab: WebAssembly, jHipster und Low-Code – und das ist gut so

Wir machen uns überflüssig. Meine These: Und das ist gut so. Wir wollen es noch nicht wahr haben und genießen derzeit noch eine Art Schutzposition. Während es Mangel an IT-Kräften gibt und die Digitalisierung für viele Bereiche Stellenabbau bedeutet entwickeln sich die Technologien paradox. Paradox ist es aber nur auf den ersten Blick.
Die scheinbare Paradoxie: Entwickler werden durch ihre eigene Digitalisierung selbst von den Auswirkungen auf den minimierten Arbeitskräftebedarf betroffen sein. Nicht langfristig, sondern es steht kurz bevor! Wie kann das sein?

Entwickler sind derzeit noch in einer Position, dass die Digitalisierung so langsam akzeptiert ist, in manchen Bereichen bereits Fahrt aufnimmt, aber so richtig verankert in vielen Bereichen noch nicht ist. Auch mit dem Pandemieschub ist im Allgemeinen die Führungskraft abhängig von ihren Technologieberatern, meist Entwickler, die Aufgaben planen und Aufwände einschätzen. Überliche Muster dabei sind: Backendentwicklung ist sehr aufwändig im Vergleich zur Frontendentwicklung, native Appentwicklung ist keine einfache Webentwicklung und zu einem gegeben Design benötigt es grafikaffine Entwickler, die dies auch Umsetzen können. Die Entwicklung verrät dem Management natürlich nur zögerlich, dass diese Aufgaben heute zu einem Bruchteil des Aufwandes zu erledigen sind.
Die drei Kernbereiche, aus denen die Aufwände für die Entwicklung entstehen, sind kurz davor zu fallen.

Kernbereich 1: Backendentwicklung wird durch Standgeneratoren ersetzt

Die Backendentwicklung hat den Ruf, das eigentliche Feld des hochspezialisierten Entwicklers zu sein. Das ist historisch so gewachsen. Betriebssystementwicklung (Linux-Kernel, etc.), Algorithmenentwicklung (Facebook, Google) sind das Herzstück der jeweiligen Innovationen. Und in der Tat, überall dort, wo es viel neue Businesslogik zu entwickeln gibt, werden auch in Zukunft noch die spezialisierten Entwickler benötigt. Doch für die meisten Geschäftsmodelle gibt es heute Frameworks, die in dem Backendbereich eingesetzt wird. Dazu kommen Generatoren, wie jHipster, die nicht nur große Teile des Backends einfach auf Basis von standardisierten Diagrammen automatisiert erzeugen können. Auch Swagger geht nach dem Konzept „Interface-First“ vor. Gar nicht so unglaublich aber wahr: Eigentlich braucht man nur beschreiben, welche Daten ausgetauscht werden sollen und schon steht fast das gesamte Backend. Und das ist ein sinnvoller Fortschritt, der dort vollzogen wird. Warum sollen die immerselben Businesslogiken von der Backendtruppe immer wieder auf neue händisch eingetippt werden? Oder warum soll der Entwickler sich Stunden aufschreiben, in denen er eigentlich nur Altes kopiert und sich ansonsten auf die faule Haut legt?

Da wir bereits von Businesslogik sprechen, die früher üblicherweise im Backend angesiedelt war, so kommt der eine oder andere vielleicht auf die Idee, dass diese nun einfach in die Frontendentwicklung abwandert und dann eben dort stattfindet. Das ist nicht richtig. Sie wandert zwar im Zuge der ebenfalls richtigen Evolution von klassischen, serverabhängigen, mehrseitigen Anwendungen in richtung Singlepage-Application oder PWA (Progressive Web Apps) also Anwendungen, die eher unabhängig von einem Server funktionieren und deshalb viel Businesslogik in der Anwedung selbst und nicht im Server haben. Doch diese wird bereits von den entsprechenden Generator wie jHipster gleich mitgeneriert.

Kernbereich 2: Spezialisten für native Appentwicklung

Derzeit ist es sinnvoll für Innovationen, mit einem plattformunabhängigen Framework App für mobile Geräte zu entwickeln. Einfach weil es günstiger ist, gleich für mehrere Plattformen zu entwickeln. Besser und hochwertiger allerdings ist die native Entwicklung für jede Plattform im Speziellen. Also eigens für Apple (iOS) und eigens für Android. Dafür benötigt man spezielle Swift oder Java-Entwickler. WebAssambly ist die nächste Evolutionsstufe: So wie Website einfach von eine Domain geladen werden, können mit WebAssembly schon heute native Apps entwickelt werden, die nicht über einen AppStore geladen werden müssen, sondern einfach über eine Domain abgerufen werden können. Und diese werden, sobald es die entsprechenden Phones dafür gibt, gleichmaßen gut auf dem Phone, dem Tablet und dem Desktop laufen. Schnell, nativ entwickelt.

Kernbereich 3: Frontendentwickler ablösen

Zu meiner Anfangszeit gab es Microsoft Frontend. Wer mit diesem Tool glaubte, Webentwicklung betreiben zu können, wurde schnell eines besseren belehrt. Das Tool wurde praktisch zu einem Witz unter allen Menschen, die sich mit der Entwicklung von Software oder auch nur einfachen Webseiten im Web beschätigten. Auch andere Tools, die Frontends irgendwie grafisch entwickeln lassen wollten, erreicht nie den Wartbarkeits und Erweiterbarkeits und Sauberkeitsanspruch echter Softwareentwickler. Heute gibt es allerdings die ersten Tools, wie WebFlow, die einen Grafiker in die Lage versetzen, seine Designs quasi direkt in diesem Tool umzusetzen, mit den üblichen Werkzeugen, mit leicht ungewohnter Herangehensweise. Ist diese Herangehensweise in gewissen Blöcken zu denken, allerdings akzeptiert, so generiert der Design gleich das gesamt Frontend. Ein Entwickler stöpselt bloß noch die Details zusammen. So ein Tools ist beispielsweise WebFlow.

Was für den Entwickler bleibt ist Zusammenstöpseln: Das werden die Waldundwiesenentwickler übernehmen. Davon wird der Bedarf dann in Zukunft gewaltig abnehmen. Und neue Businesslogik für echte Innovationen wird weiterhin benötigt. Das wiederum werden die besten Spezialisten auf ihrem Gebiet ausführen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.