Code, der allmählich verschwindet

Bei all dem medialen Wirbel rund um No-Code- undLow-Code-Entwicklung könnte man leicht zu der Annahme verleitet werden, dass diese beidenKonzepte völlig neuartige Erfindungen darstellen. Aber tun sie das wirklich?

Seit Jahren verfolgt unser Unternehmen, Xmethod, nichtnur diese Ansätze, sondern wendet sie auch in verschiedenen Kundenprojekten an,was uns unserer Meinung nach eine gewisse Perspektive verschafft. Lassen Sie uns also etwas tiefereintauchen, wie No-Code und Low-Code entstanden sind.

Die Zeit vor dem Internet

Die ersten Computer, so erzählen es uns die Geschichtslehrer, kamenMitte des 20. Jahrhunderts auf den Markt und waren zunächst eher unansehnlich (oder zumindest sehr groß). Sie zu programmieren war die Domäne vonIngenieuren, die einiges über Computerarchitektur wissen mussten, um überhauptetwas zustande zu bringen. Ihr Arbeitsjargon war die spezifische Assemblersprache ihres Prozessors,und statt einer IDE mussten sie sich mit einem Lochkartenleser herumschlagen.Wann immer Sie einen Softwareentwickler über seine Arbeitswerkzeuge klagen hören, dürfenSie ihn gerne an die missliche Lage jener frühen Programmierer erinnern.

Lochkarten oder Tastatur – der wichtige Gedanke, den man sichmerken sollte, ist, dass zu Beginn des Computerzeitalters Dinge fürIhr Unternehmen zu erledigen bedeutete, sehr, sehr viel über den Computer wissen zu müssen, den Sieverwendeten. Von diesem niedrigen Ausgangspunkt aus begannen sich die Dinge jedoch zu verbessern.

Eine frühe Verbesserung kam in Form einer"Formelübersetzungs"-Sprache, besser bekannt als Fortran, die dieProgrammierer ein wenig davon befreite, die kleinsten Details ihrer Computer-Hardwareeigenheiten kennen zu müssen. Fortran machte den Prozess des Codierens außerdem viel schneller undviel weniger fehleranfällig und verschaffte uns so mehr Portabilität, Produktivität undZuverlässigkeit. Cobol und Algol folgten einige Jahre später und verbesserten allediese drei Dimensionen weiter.

In sehr groben Zügen kann man sagen, dass abden 1960er Jahren Programmiersprachen zunehmend ausgereifterund zunehmend abstrakter wurden. Es wurde immer einfacher, zu formulieren, was"getan werden musste", und die Details dem Compiler (oder dem Interpreter; lassen Sieuns hier nicht abschweifen und die Unterschiede diskutieren) zu überlassen.

Die Internet-Ära

Die explosionsartige Ausbreitung des Internets in den 1990er Jahrenbrachte uns die erste wirklich moderne Sprache, JavaScript, die wahrscheinlicheine Art Titel dafür verdient hätte, häufiger als jede andere Programmiersprache in der Geschichte falscherklärt und/oder eingeführt worden zu sein (es genügt zu sagen,dass sie weder eine Skriptsprache ist noch viel mit Java zu tun hat,das bereits existierte, als JavaScript auf den Markt kam). Es ist eine Sprache, die"in" jedem Browser "lebt", den wir heute verwenden – Chrome, Safari, Firefox,Brave oder Edge, obwohl sie seither auch auf die Serverseite migriert ist.

Obwohl die ganze Geschichte von JavaScript nicht nureinen eigenen Artikel, sondern ein Buch (oder mehrere) verdient, ist das besondersInteressante daran, dass sie einen weiteren, oft unterschätzten Schritt inRichtung mehr Abstraktion machte: Sie erlaubte Programmierern, das"Document Object Model" zu manipulieren, das jeder Webseite zugrunde liegt. Zunächst warendie Menschen damit zufrieden, Low-Level-Seitenelemente zu handhaben, wie Titel, Absätzeund Tabellenzellen, doch schon bald begannen Bibliotheken aufzutauchen, die dieListe der zu manipulierenden Objekte viel länger und die Abstraktionsfähigkeiten – vielgrößer machten. So kamen wir schließlich in den Genuss von monströsgroßen Frameworks wie Angular.

Die richtigen Werkzeuge für die Aufgabe

Obwohl man argumentieren könnte, dass die Verwendung einerBibliothek oder eines Frameworks den Programmierer nicht vollständig davon befreit, etwas codieren zu müssen, ist der wichtige Punkt hier, dass die Strukturen und Konzepte,die "programmiert" (oder durch Code manipuliert) werden, immer mehrauf höherem Niveau angesiedelt sind.  

Ein ähnlicher Trend betrifft Geschäftsprozesse.Allmählich neigen Unternehmen dazu, ihr eigenes "Vokabular" anObjekten und Operationen zu entwickeln, das sich immer weiter von ihren Low-Level-Darstellungen entfernt. Diese Konzepte müssen in geeignetenAbstraktionen ausgedrückt werden.

Um ein oft verwendetes Beispiel zu geben: Stellen Sie sich vor, Sie müsstenein paar Tabellenkalkulationsformeln in einer Programmiersprache programmieren. Sicherlich kann man alles, was Sie in Excel tun können (und vieles mehr), auch in einer Sprachewie Python tun – von der Datenformatierung über die Berechnung bis zum Zeichnen von Diagrammen. Sie können Ihre Tabellenkalkulationen also definitiv "programmieren" und brauchbare Ergebnisse erzielen. Aber werwürde das wollen? Denken Sie an die Einstiegshürde (ein Business-Analyst oder einBuchhalter müsste Python lernen, *bevor* er irgendetwas Nützlicheserledigen könnte), den Produktivitätsverlust und die verschwendete Zeit, eine einfacheGeschäftsaufgabe auf sehr umständliche und ineffiziente Weise anzugehen. Und am Ende wäre es, sofernkeine hochspezialisierte Anforderung umzusetzen wäre, nahezu sicher, dass die einfache Verwendung von Excel ein besseres Ergebnis erzielt hätte.

Excel ist bei Weitem nicht die einzige No-/Low-Code-Anwendung, die eine bestimmte Geschäftsaufgabe revolutionierte. Nahezu allespezialisierten Softwarepakete können heute genutzt werden, um großartige Produktezu erstellen, ganz ohne Programmierkenntnisse. Beispiele gibt es in Hülle und Fülle. Die meisten Blogger tippen fröhlichdrauflos und veröffentlichen Aufsätze, ohne sich der internen Funktionsweise von Wordpress oderMedium oder Substack bewusst zu sein. Musiker können ihren Sound formen und einzigartigeelektronische Instrumente gestalten, indem sie Point-and-Click-Oberflächen von Programmen wie Max nutzen.

Der Schlüssel zum Erfolg eines jeden Geschäftsprojekts liegt darin,die richtige Mischung aus Werkzeugen und Abstraktionen auszuwählen und dann... auszuführen. Schnell. Wenn etwas codefrei erledigt werden kann, sollte es das wahrscheinlich auch werden. Manche Dinge lassen sich nicht vollständig ohne Codierung umsetzen (zumindest nochnicht) und diese müssen programmiert werden.

Die Schwierigkeit liegt daher darin, ein Geschäftsprojekt richtigzu strukturieren und zu bestimmen, welche Teile des Puzzles vonNo-Code-Werkzeugen bewältigt werden können, welche in Low-Code umgesetzt werden sollten und welcheIhnen keine andere Wahl lassen, als die Ärmel hochzukrempeln und es auf die altmodischeWeise zu codieren.

Moment, sagen Sie sich jetzt wahrscheinlich. Diesemoderner" Prozess scheint also komplizierter geworden zu sein alszuvor: Sie müssen nicht nur wissen, wie Sie die Dinge umsetzen, die umgesetzt werden müssen, sondern Sie müssen auch entscheiden können, welche Teile Ihres Projekts Sienicht codieren sollten. Wie ist das ein Fortschritt? Nun, das ist es, denndiese Teilprobleme sind nun überschaubarer und lassen sich schneller lösen.

Darüber hinaus können Sie sowohl die Strukturierungals auch den Codierungsteil (falls nötig) einem vertrauenswürdigen Partner überlassen.  Dürfen wir bescheiden unsere eigene Agentur vorschlagen? Mitüber 150 Projekten auf unserem Konto und unter Nutzung unserer charakteristischen Mischung aus No-Code,Low-Code und Full-Stack-Lösungen sind wir stets bereit, Ihrem Unternehmen zu helfen, einer neuen Herausforderung zu begegnen – sei es ein internes Planungssystem, ein maßgeschneidertes CRModer eine neue App. Wir arbeiten schnell (die meisten Projekte können in nur wenigen Wochen abgeschlossen werden)und unsere Preise werden Sie angenehm überraschen. Wenn Sie eine Geschäftsaufgabe haben, fürdie Sie ein maßgeschneidertes Werkzeug benötigen, rufen Sie keine Headhunter an … zumindest nicht, bevor Sie mit unsgesprochen haben: Eine Lösung kann schneller (und günstiger) bereitstehen, als Sie für möglich gehalten haben.