Ich programmiere seit über 20 Jahren. Was sich geändert hat und was erstaunlich gleich geblieben ist

Wenn man lange genug Software entwickelt, sammelt man irgendwann Technologien, die einmal als Zukunft galten und heute nur noch in alten Projektverzeichnissen auftauchen.

Entwicklungsumgebungen verschwinden. Frameworks werden erst unverzichtbar und später „legacy“. Programmiersprachen gewinnen an Bedeutung, verlieren sie wieder oder erleben Jahre später ein überraschendes Comeback.

Die Softwareentwicklung von heute sieht an vielen Stellen völlig anders aus als die, mit der ich beruflich angefangen habe.

Und gleichzeitig ist erstaunlich viel gleich geblieben.

Vieles ist schneller geworden

Der offensichtlichste Unterschied sind die Werkzeuge.

Heute kann ich in wenigen Minuten ein Projekt aufsetzen, Abhängigkeiten installieren, Tests ausführen und einen Build erzeugen. Versionsverwaltung, automatisierte Builds und Paketverwaltung sind selbstverständlich geworden.

Viele Aufgaben, die früher Handarbeit waren, erledigt heute die Toolchain.

Das ist ein gewaltiger Fortschritt.

Auch die Informationsbeschaffung hat sich verändert. Früher standen Bücher neben dem Monitor. Heute sind Dokumentationen, Quellcode, Foren und inzwischen KI-Assistenten nur wenige Sekunden entfernt.

Die Entfernung zwischen einer Idee und einem ersten funktionierenden Prototyp ist dadurch drastisch geschrumpft.

Das bedeutet allerdings nicht automatisch, dass gute Software schneller entsteht.

Wir können schneller Fehler bauen

Das ist vielleicht eine der weniger romantischen Erkenntnisse aus vielen Jahren Entwicklung.

Werkzeuge machen Entwickler produktiver. Sie machen uns aber nicht automatisch klüger.

Mit modernen Frameworks lassen sich in sehr kurzer Zeit beeindruckende Anwendungen bauen. Man kann allerdings genauso schnell eine Architektur erzeugen, die sechs Monate später niemand mehr gerne anfasst.

Produktivität multipliziert eben auch schlechte Entscheidungen.

Je leistungsfähiger die Werkzeuge werden, desto wichtiger wird deshalb die Fähigkeit, zwischen einer schnellen Lösung und einer guten Lösung zu unterscheiden.

Und manchmal ist die schnelle Lösung tatsächlich die gute.

Architektur ist immer noch eine Frage von Konsequenzen

Technologien ändern sich. Die grundlegenden Architekturfragen erstaunlich wenig.

Wo liegen Verantwortlichkeiten?

Welche Teile dürfen voneinander abhängig sein?

Wo werden Daten gehalten?

Was passiert bei einem Fehler?

Welche Entscheidungen lassen sich später noch ändern und welche werden teuer?

Man kann dafür moderne Begriffe verwenden und beeindruckende Diagramme zeichnen. Am Ende geht es immer um Konsequenzen.

Eine Architektur ist für mich kein Kunstwerk. Sie ist eine Sammlung von Entscheidungen, die zukünftige Änderungen leichter oder schwieriger machen.

Daran hat sich wenig geändert.

Benutzer sind keine Testabteilung

Auch das ist zeitlos.

Technisch funktionierende Software kann trotzdem schlechte Software sein.

Ein Dialog kann korrekt programmiert sein und trotzdem unverständlich wirken. Ein Prozess kann alle Anforderungen erfüllen und trotzdem zehn Klicks zu viel benötigen.

Entwickler sehen Anwendungen zwangsläufig anders als deren Benutzer. Wir kennen das Datenmodell. Wir wissen, warum ein Button dort sitzt. Wir kennen die Bedeutung einer Option.

Der Benutzer weiß davon nichts.

Diese Perspektive einzunehmen war früher wichtig und ist es heute noch.

Vielleicht sogar mehr, weil moderne Software immer mehr Funktionen besitzt und damit mehr Möglichkeiten hat, kompliziert zu werden.

Der langweilige Code gewinnt erstaunlich oft

Früher fand ich besonders raffinierte Lösungen faszinierend.

Heute freue ich mich häufiger über Code, den man nach einem halben Jahr wieder öffnet und sofort versteht.

Das ist vermutlich eine typische Entwicklung.

Clevere Abstraktionen fühlen sich während der Entwicklung gut an. Verständliche Strukturen fühlen sich während der Wartung gut an.

Und Software verbringt meistens deutlich mehr Zeit in Wartung als in ihrer ersten Entwicklung.

Deshalb hat „langweiliger“ Code für mich inzwischen einen ziemlich guten Ruf.

Trends sind nützlich, aber keine Architekturentscheidung

Die IT-Branche liebt neue Begriffe.

Alle paar Jahre gibt es Technologien, die angeblich nahezu jedes Problem lösen. Dann erscheinen Konferenzen, Bücher, Beratungsangebote und natürlich Architekturdiagramme mit sehr vielen Pfeilen.

Einige dieser Entwicklungen verändern tatsächlich viel.

Andere lösen hauptsächlich Probleme, die kleinere Projekte gar nicht besitzen.

Mit Erfahrung wird man vielleicht nicht weniger neugierig, aber selektiver.

Ich möchte neue Technologien verstehen. Ich muss sie deshalb noch lange nicht überall einsetzen.

Die interessanteste Frage lautet für mich nicht: Ist das modern?

Sondern: Welches konkrete Problem löst es hier?

Fehlerbehandlung bleibt unbeliebt und wichtig

Der glückliche Pfad ist meistens schnell programmiert.

Datei öffnen. Daten laden. Verarbeitung starten. Ergebnis speichern.

Spannend wird es, wenn die Datei gesperrt ist. Wenn das Netzwerk ausfällt. Wenn ein Prozess abgebrochen wird. Wenn Daten aus einer älteren Version stammen.

Diese Fälle waren vor zwanzig Jahren lästig und sind es heute noch.

Nur die Erwartung der Benutzer ist gestiegen.

Gute Software darf intern kompliziert reagieren. Nach außen sollte sie ruhig bleiben.

Auch das ist eines dieser Dinge, die kaum jemand bemerkt, solange sie funktionieren.

KI ist neu. Verantwortung nicht.

KI-Werkzeuge verändern die Softwareentwicklung gerade sehr deutlich.

Sie können Code erklären, Varianten erzeugen, Tests vorschlagen und bei Routineaufgaben enorm beschleunigen.

Das finde ich spannend.

Aber sie verändern eine grundlegende Sache nicht: Irgendjemand muss entscheiden, ob eine Lösung sinnvoll ist.

Code zu erzeugen war nie der einzige Teil von Softwareentwicklung.

Anforderungen verstehen, Konsequenzen abschätzen, Architektur gestalten, Sicherheit berücksichtigen und Entscheidungen verantworten gehören genauso dazu.

Die Werkzeuge werden besser.

Die Verantwortung bleibt.

Erfahrung bedeutet nicht, alles zu wissen

Mit den Jahren kennt man mehr Muster. Man erkennt manche Probleme früher und hat vermutlich schon einige Fehler selbst gemacht, vor denen man andere warnen kann.

Gleichzeitig wächst das Bewusstsein dafür, wie groß das Gebiet eigentlich ist.

Niemand beherrscht „die Softwareentwicklung“.

Dafür gibt es zu viele Plattformen, Sprachen, Domänen und Spezialgebiete.

Erfahrung zeigt sich für mich deshalb weniger darin, sofort eine Antwort zu haben.

Sie zeigt sich darin, die richtigen Fragen früher zu stellen.

Die grundlegenden Fragen bleiben

Wenn ich auf die Veränderungen der letzten Jahrzehnte schaue, finde ich das eigentlich beruhigend.

Wir haben bessere Editoren, bessere Bibliotheken, bessere Infrastruktur und inzwischen Werkzeuge, die vor wenigen Jahren noch nach Science-Fiction geklungen hätten.

Trotzdem beginnt gute Softwareentwicklung noch immer mit ziemlich einfachen Fragen.

Welches Problem lösen wir?

Für wen?

Was muss wirklich funktionieren?

Welche Komplexität ist notwendig?

Was passiert, wenn etwas schiefgeht?

Und wird jemand anderes diesen Code später noch verstehen?

Die Antworten verändern sich.

Die Fragen erstaunlich wenig.