Erkenntnisse aus dem ThoughtWorks Technology Radar Makrotrends in der Software-Entwicklung 2021

Aktuelle Trends in der Software-Entwicklung beleuchtet die internationale Softwareberatung ThoughtWorks zweimal jährlich im Technology Radar. Von Praktiken über Plattformen, Tools und Frameworks bis hin zu Programmiersprachen: Dieser Artikel nennt einige größere Trends der Techbranche basierend auf dem Technology Radar.

„Demokratisierung“ der Programmierung

Einer der zurzeit bedeutendsten und anhaltenden Technologietrends ist die sogenannte „Demokratisierung“ der Programmierung. Hier geht es darum, die Programmierung einer Maschine oder eines Systems für Nicht-Programmiererinnen und -Programmierer zugänglicher zu machen.

Diese Idee ist nicht neu. COBOL – die „Common Business-Oriented Language“ – stammt aus den 1960er-Jahren und stellte den Versuch dar, Computerprogramme mithilfe einer an das Englische angelehnten Sprache zu entwickeln, die für Nicht-Programmiererinnen und -Programmierer verständlicher sein sollte.

Heute ist das Interesse an „Low-Code“-Plattformen groß, die versprechen, Software ganz ohne Programmierkenntnisse entwickeln zu können. Mit Plattformen wie IFTTT für Endanwender und Zapier für Unternehmen können technisch weniger versierte Benutzer verschiedene Geräte, SaaS-Plattformen, Endpunkte und Workflows verbinden und interessante und nützliche Projekte umsetzen.

Apiant, Blendr, Microsoft Flow, Pipedream, Quickwork und Tray.io sind nur einige von vielen verfügbaren Lösungen, die ein Integrations-Framework bieten. Im Bereich der Anwendungsentwicklung hat Amazon Honeycode an Fahrt aufgenommen – obwohl ein Radar-Autor die Lösung als „Microsoft Access in der Cloud“ beschreibt.

Die Fähigkeit des Programmierens bzw. zumindest ein gewisses Mitspracherecht in Bezug auf die Funktionen genutzter Systeme ist unserer Ansicht nach äußerst wichtig. Douglas Rushkoff erörtert in seinem Buch Program or Be Programmed, dass wir uns entscheiden müssen, ob wir die Technologie steuern oder uns von ihr und von denen, die sie beherrschen, leiten lassen. Jenseits dieser philosophischen Betrachtungsweise ist es jedoch tatsächlich so, dass die Welt nach mehr Software verlangt als bestehende IT-Teams entwickeln können.

Ein gängiges Beispiel sind Spreadsheets bzw. Tabellenkalkulationen. Fast jedes Unternehmen arbeitet mit Spreadsheets und alle in der IT-Branche kennen die damit verbundenen Probleme. Riesige Spreadsheets mit kritischer, nicht geprüfter Geschäftslogik sind keine Seltenheit. Noch alarmierender ist die Tatsache, dass mehrere Gesundheitsdienstleister auf der ganzen Welt COVID-19-Daten verloren oder falsch verarbeitet haben – und zwar aufgrund fehlerhafter Spreadsheets.

Spreadsheets dienen in der Regel dazu, dass Nicht-Programmierer*innen das schnelle Erstellen, Speichern und Bearbeiten von Daten ohne langwierige Entwicklungszyklen mit „echten“ Programmier-Teams leisten können. „Low-Code“-Plattformen versprechen ähnliche Vorteile. Sie sollen die Softwareentwicklung beschleunigen, indem sie vorgefertigte Komponenten und Konfigurationen anstelle von Code verwenden.

Spreadsheets und „Low-Code“ haben eines gemeinsam: Beide eignen sich gut für bestimmte Anwendungsbereiche in Bezug auf die benötigten Funktionen und die damit einhergehende Komplexität. Außerhalb des „Sweet Spot“ sollten sie allerdings nicht verwendet werden.

Unglücklicherweise verhindert der Grund, warum eine solche Lösung überhaupt gewählt wird – Knappheit an technischem Talent oder Zeit – auch, dass jemand, der eine Tabellenkalkulation oder Low-Code-Umgebung verwendet, erkennt, dass er die Lösung über ihren Sweet Spot hinausgetrieben hat. Wir empfehlen daher den Einsatz von „Bounded Low-Code“-Plattformen, um diesem Risiko zu begegnen und gleichzeitig die mögliche Zeitersparnis einer demokratisierten Programmierplattform nutzen zu können.

Rust auf dem Vormarsch

Eine unserer Lieblings-Programmiersprachen ist Rust. In Rust geschriebene Programme sind in der Ausführung schnell und verwalten Speicher immer korrekt. Damit ist diese Sprache als Systemprogrammiersprache (anstelle von C oder C++) oder für sich genommen als allgemeine Programmiersprache verwendbar. Rust wird immer beliebter und wurde bereits zum fünften Jahr in Folge von Stack Overflow zur meistgeliebten Programmiersprache gekürt.

In der aktuellen Radar-Ausgabe stellen wir fest, dass Rust für Big Data und Machine Learning (ML) verwendet wird – Bereiche, in denen traditionellerweise Python zum Einsatz kommt und in einigen Fällen bemerkenswerte Performance-Vorteile bietet. Außerdem wird Materialize erwähnt, eine Streaming-Datenbank mit geringer Latenz, die in Rust programmiert wurde.

Was also macht Rust so beliebt? Persönlich sehe ich die Kombination der starken Ausdruckskraft und der vom Compiler gewährleisteten Typsicherheit als ein klares Alleinstellungsmerkmal. Laut Stack Overflow ist Rust eine Programmiersprache, die „augenscheinlich von User Experience Designern entwickelt wurde“, die eine klare Vorstellung der Sprache haben und ihre Bestandteile sorgfältig auswählen. Es gibt eine unterstützende, leicht zugängliche Rust-Community und ein immer besseres Ökosystem mit zahlreichen Bibliotheken und Tools.

Visualisierung aller Dinge

Die aktuelle Radar-Ausgabe beinhaltet einige großartige Beispiele für Visualisierungs-Tools. Mehr denn je ist die Fähigkeit, sich ein gutes Bild von etwas zu machen – Architektur, Codekomplexität, Systemleistung oder verteilte Traces in einem Microservices-Ökosystem – entscheidend für das Verständnis der komplexen Systeme, die wir heute bauen. Zu den besprochenen Visualisierungs-Tools zählen:

• Streamlit, ein Framework zur Entwicklung von ML- und Data-Science-Web-Apps

• Dash, das sowohl für derartige ML-Apps als auch im Business-Intelligence-Kontext zur Entwicklung benutzerdefinierter Berichte und Dashboards zum Einsatz kommt

• Kiali, eine Management-Konsole für Istio-basierte Service-Meshes mit Dashboards und anderen Observability-Tools

• OpenTelemetry, ein API und SDK zur Erfassung verteilter Traces und Metriken

• Polyglot Code Explorer, ein Tool zur visuellen Prüfung der Codebasis und zur Analyse ihres Zustands und ihrer Struktur

Recht bekannt sind bereits die Visualisierungsfunktionen von Mainstream-BI-Tools wie Tableau oder Power BI. In diesem Bereich kommen immer mehr Features auf den Markt. Aber Tools wie Dash und Streamlit bieten einen Code-basierten Visualisierungsansatz mit allen Vorteilen – Flexibilität, Anpassbarkeit, Versionskontrolle und automatisierten Deployments. Alles gute Gründe, eher ein Framework als ein umfassendes Werkzeug im Stil eines „Datenstudios“ in Betracht zu ziehen.

„Infrastructure as Code“ immer beliebter und besser

Für die Radar-Themen wurde bewusst der Begriff der Adoleszenz von Infrastructure as Code verwendet, ein Begriff, der sowohl einen positiven als auch einen negativen Beigeschmack hat. Ähnlich wie ein etwas unbeholfener Teenager wird auch Infrastructure as Code erwachsen. Das ist positiv, denn mit zunehmender Reife entstehen bessere Ergebnisse und ein wachsendes Ökosystem rund um diese Praktiken. Jedoch gibt es auch „Wachstumsschmerzen“, z. B. Inkonsistenz bei einigen Tools sowie konkurrierende Ansätze und Philosophien.

Aber was ist „Infrastructure as Code“ eigentlich? Kurz gesagt: Es handelt sich um die Automatisierung der Infrastruktur und das umsichtige Management dieser Automatisierung. Es gibt in Bezug auf „Infrastructure as Code“ verschiedene Denkschulen: Pulumi-Anhänger reden von „Infrastructure as Software“, Hightower spricht von „Infrastructure as Data“ und WeaveWorks verwendet den Begriff „GitOps“.

Es bleibt abzuwarten, wohin diese verschiedenen Ansätze führen. Wir bezeichnen sie zunächst einmal als verschiedene Ausprägungen von „Infrastructure as Code“ und nicht als signifikante Abweichung dieses Konzepts. Die Tools in diesem Bereich haben sich deutlich verbessert. CDK und Pulumi sind gute Beispiele für den höheren Reifegrad des Ökosystems.

Der Browser als „versehentliche“ Anwendungsplattform

Der Internet-Browser war ursprünglich eine Anwendung für das Betrachten von HTML-Dokumenten und die Navigation zwischen diesen Dokumenten mittels Hyperlinks. Aufgrund der zunehmenden Beliebtheit des Browsers wurden in HTML 2.0 deutlich mehr Tags hinzugefügt. Außerdem wurden die Webseiten durch die Möglichkeit, „Formulare“ an einen Server zu übermitteln, noch interaktiver.

Im Zuge der Auseinandersetzung zwischen Netscape und Microsoft stellte man allerdings fest, dass der Browser eine Skript-Sprache benötigte. Also wurde JavaScript (ursprünglich Mocha genannt) in nur zehn Tagen entwickelt und zu Netscape hinzugefügt. In dieser Zeit der „Browser-Kriege“ ergänzten Unternehmen wie Netscape und Microsoft HTML um eigene Erweiterungen, um gegenüber Mitbewerbern die Nase vorn zu haben.

Seinerzeit wurde auf Webseiten häufig der Hinweis „optimiert für Internet Explorer“ verwendet. Flash und eingebettete Java-Applets sorgten für Interaktivität auf Webseiten. Der Ajax-Standard kam auf den Markt. JavaScript wurde von Entwicklern wiederentdeckt und sogar als Backend-Sprache verwendet (z. B. in node.js).

Die Sache ist die: Der Browser war ursprünglich nur für die Dokumentanzeige gedacht, wurde dann aber zu einer Anwendungsplattform umfunktioniert. Man kann Artikel in Google Docs schreiben, dabei Musik auf YouTube hören und über Google Chat mit anderen Personen sprechen. Der Chat läuft in einem scheinbar nativen Anwendungsfenster, tatsächlich handelt es sich aber um ein separates Fenster mit einer Webseite.

Im Laufe der Jahre wurde der Browser zu einem vielseitigen Tool weiterentwickelt. Heute fungiert er sowohl als komplexe Plattform als auch als Ökosystem. In der Regel bieten die verschiedenen Browser eine umfassende Kompatibilität. Polyfills schließen Lücken und machen es Entwickler*innen einfacher, für mehrere Browser zu programmieren. Das JavaScript-Ökosystem selbst ist aber nach wie vor verblüffend komplex und entwickelt sich rasant weiter.

In der aktuellen Radar-Ausgabe ist ein Thema die Änderung der Empfehlung für Redux von „Adopt“ zu „Trial“, da Teams sich bezüglich des State-Managements ihrer React-Applikationen anderweitig orientieren (sie nutzen z. B. Recoil). Auch heute noch wird die „richtige“ Methode zur Erstellung von Webanwendungen weiterentwickelt: Svelte weckt immer mehr Interesse und stellt ein bewährtes Konzept der beliebten Anwendungs-Frameworks React und Vue.js infrage: das Virtual DOM.

Das Testen ist ein weiterer Bereich, in dem der Browser mehr oder weniger zur Kooperation genötigt wurde. Das Problem ist jedoch, dass Automatisierungs- und Test-Tools nach wie vor nachgerüstet statt von Grund auf für den vorrangigen Zweck entwickelt und unterstützt werden. In der aktuellen Radar-Ausgabe werden Playwright als Alternative zur Optimierung von UI-Tests und Mock Service Worker als Ansatz zur Entkopplung von Tests und Backend-Interaktionen beschrieben.

Des Weiteren entwickelt sich der Browser weiter in Richtung einer „nativen“ Code-Plattform. WebAssembly bietet eine effiziente Virtual Machine, die darauf abzielt, Code mit nahezu nativer Geschwindigkeit auszuführen. Interessant ist auch eine experimentelle Portierung von Doom 3, die mit 60 FPS im Browser läuft.

Webbrowser bleiben, aber die Tatsache, dass es sich hauptsächlich um eine „versehentliche“ Anwendungsplattform handelt, ist nach wie vor Thema in der Tech-Community. Bei jedem Projekt sollte daher Zeit dafür eingeplant werden, in Bezug auf die aktuelle Browser-Entwicklung auf dem Laufenden zu bleiben.

* Als Global Head of Technology ist Mike Mason bei ThoughtWorks für die strategische Ausrichtung der Technologie sowie für den Erfolg der Kundenprojekte verantwortlich. Es ist seine Leidenschaft, Spitzentechnologie zur Lösung geschäftlicher Herausforderungen einzusetzen und die Kunden zu beraten, auf welche Weise Technologie ein kritischer Teil ihres Geschäfts sein kann.

Mike Mason ist Global Head of Technology bei ThoughtWorks.

(ID:47067909)