Was ist Software-Entwicklung

Das habe ich mich in letzter Zeit öfter gefragt, auch wenn es auf LinkedIn meistens sehr provokant formuliert wird.

Man liest davon, dass Entwickler überflüssig sind und alle von KI ersetzt werden, denn jeder kann ja jetzt programmieren. Und wenn das jeder kann, wofür braucht man mich dann noch?

Natürlich triggert mich diese Aussage, weil ich mich als Entwickler angesprochen fühle, aber ich mache mir weniger Sorgen um meinen Job und vielmehr macht es deutlich, wie wenig Verständnis von Software-Entwicklung bei demjenigen vorherrscht, der diese Aussage tätigt.

Denn Software-Entwicklung ist mehr als nur Code zu produzieren, es ist mehr als auf der Tastatur herumzutippen und dabei einen Buchstabensalat zu erzeugen. Es gibt auch Personen, die damit flexen wie viele Zeilen Code durch KI in ihrem Unternehmen generiert wurden. Dabei ist ein Entwickler nicht nach Zeilen Code zu beurteilen, denn an einem produktiven Tag kann es auch mal sein, dass ich mehr Code entferne als hinzufüge, weil ich das Projekt aufräume.

Aber zurück zum Thema:

Warum stelle ich mir diese Frage

Dieser Beitrag ist kein Selbstzweck, weil ich so gerne rede (bzw. schreibe), sondern eine Reaktion auf das zunehmende Missverständnis, was es bedeutet, wirklich Software zu entwickeln. Ich will einfach mal beleuchten, warum Entwickler auch neben großen KI-Wellen unverzichtbar bleiben.

Aber die offensichtliche Frage ist dann:

Was definiert einen Entwickler

Es ist nicht hilfreich, dass Begriffe nicht einheitlich genutzt werden oder sogar für jeden eine eigene Bedeutung haben. Es ist nichts Neues in der IT, dass Sachen nicht "genormt" sind, dafür ist unsere "Kunst" noch zu jung. Außerdem brauchen wir keine IHK, die uns reguliert, damit ich mir einen tollen Meisterbrief an die Wand hängen kann.

Daher versuche ich mal für mich (und auch für dich), das Ganze aufzudröseln, damit klar ist, worüber ich rede und was ich meine.

Es gibt sie ja, die Entwickler, Programmierer, Developer, Coder, und dabei lasse ich die Abstufungen wie Junior, Mid, Senior oder Software-Architekt (habe ich auch schon als besseren Senior gesehen) einfach mal alle weg und meine JEDEN, der am Ende des Tages Quellcode produziert oder dazu beiträgt, dass dieser produziert wird.

Was ich aber unterscheiden will und mir wichtig ist: Es gibt einen Unterschied zwischen Programmieren und Software-Entwicklung.

Die Definition

Software-Entwicklung ist für mich das Übersetzen von Business-Anforderungen und das Modellieren von Prozessen, die Abstimmung mit beteiligten Abteilungen und dem Betrieb mit anschließender Dokumentation als Quellcode.

Das Dokumentieren der Business-Anforderungen im Quellcode ist für mich Programmieren. Dabei geht es mir nicht um wissenschaftliche Korrektheit der Begriffe, sondern nur für diesen Text, damit klarer ist, was ich meine.

Diese Unterscheidung hilft uns, zu erkennen, dass Planen und Agieren im Team die Grundlagen liefern, bevor überhaupt eine Zeile Code entsteht.

Was ist die Aufgabe von Quellcode

Die Hauptaufgabe von Quellcode ist die Mensch-zu-Mensch-Kommunikation und nicht, wie die meisten denken würden, ein Artefakt zu produzieren, welches eine Maschine ausführen kann.

Denn wie ein Problem zu lösen ist, kann ich in vielen Programmiersprachen schreiben, wie diese Probleme gelöst sind, ist unterschiedlich. Ich kann es prozedural, objektorientiert, funktional oder deklarativ programmieren und damit muss ich je nach Ansatz auch komplett unterschiedliche Denkmuster nutzen, um mein Problem zu lösen.

Allein schon zwischen prozeduraler und objektorientierter Programmierung gibt es so große Unterschiede, dass eine Diskussion darüber religiöse Züge annehmen kann.

Dabei ist das reine Programmieren nur die konkrete Umsetzung dieser Anforderungen im Quelltext und nicht die Hauptaufgabe eines Entwicklers.

Und was ist dann Software-Entwicklung?

Neben dem Programmieren umfasst Software-Entwicklung nämlich auch

• die Planung,
• das Design,
• den Betrieb,
• das Monitoring,
• das Logging,
• Anpassungen an sich ändernde Anforderungen
• und vor allem auch Kommunikation mit allen Projektbeteiligten.

Quellcode ist also dafür da, Menschen zu erzählen, welche Business-Regeln wie eingehalten werden müssen, damit die Daten in der Datenbank valide bleiben und unsere Absprachen mit anderen Teams weiterhin funktionieren und alle die Daten bekommen, die sie benötigen.

Dabei ist der Merksatz hilfreich:

Das bedeutet für mich, dass Software auch Quellcode enthält, aber nicht nur Quellcode ist.

Ich hoffe, dass bis hier klar geworden ist, was ich davon halte, wenn jemand sagt, er kann mit KI Quellcode generieren. Denn mehr machen die meisten auch nicht.

Von diesem Standpunkt zu schließen, dass KI "falsch" wäre oder es sogar abzulehnen, ist genauso falsch und auch viel zu kurzsichtig.

Was kann also KI und wo nutze ich sie gerne

Künstliche Intelligenz kann Code schneller generieren, als ich ihn jemals schreiben könnte. Ich kann zwar schnell tippen, aber nicht so schnell. Gerade Boilerplate-Code, der immer gleich ist, viel Zeit in Anspruch nimmt, aber meistens keine Businesslogik enthält, mich damit "langweilt" und oft bei jedem Projekt aufs Neue geschrieben wird.

Bei dieser Aufgabe ist künstliche Intelligenz unschlagbar.

Wo ich gerne künstliche Intelligenz außerdem nutze, ist bei Code Reviews als erster "Scan", um mich auf die wichtigen Sachen zu konzentrieren, oder beim Transformieren von Daten (einfach mal fünf neue Sprachen für die Double-Opt-In-Mail in zehn Minuten erstellen lassen rockt).

Die Konsequenz davon ist, wir sind schneller beim Umsetzen, aber nicht automatisch besser beim Entscheiden.

Und hier entsteht der Trugschluss, der viele zu der Aussage verleitet, dass künstliche Intelligenz Entwickler überflüssig macht.

Code generieren ist nicht Software-Entwicklung, denn der Großteil der Arbeit ist nicht Code zu generieren, sondern zu planen, zu kommunizieren, zu verifizieren und zu debuggen.

Den Großteil meiner Zeit verbringe ich nicht tippend am Rechner und produziere Code, sondern entweder in Meetings oder ich recherchiere, ich dokumentiere, analysiere bestehenden Code und das alles, um Lösungen zu planen, Änderungen abzustimmen und Machbarkeit zu verifizieren und dabei alle Beteiligten auf dem gleichen Stand zu halten.

Es gibt so viele Bereiche, die nichts mit Programmieren zu tun haben oder vorab passieren müssen, damit ich überhaupt programmieren kann.

Problemverständnis

Software-Entwicklung beginnt lange vor der ersten Zeile Code mit Meetings und Prozessanalysen, um das konkrete Problem zu verstehen, was man zu lösen versucht, denn die einzige Daseinsberechtigung für Software ist ein real existierendes Problem, welches dadurch vereinfacht oder gelöst wird.

Gerade hier ist es wichtig, zwischen den Zeilen zu lesen, denn die Lösung ist manchmal einfach und offensichtlich oder so abstrakt, dass bisher niemand daran gedacht hat.

Solche Informationen gewinnt man aber nur in der Kommunikation mit Menschen und dem Verständnis des bestehenden Problems, welches es zu lösen gilt.

Jetzt, wo wir die Unterschiede geklärt haben und wissen, dass Quellcode ein Kommunikationsmittel zwischen Entwicklern ist, wir wissen, dass wir ein Problem brauchen, welches es zu verstehen und lösen gilt, kommen wir zu den Hauptaufgaben eines Entwicklers:

1. Architekturentscheidungen

Wenn das Problem bekannt ist, beginnt der Prozess der Lösungsfindung und die Suche nach einem Weg, welcher im aktuellen Kontext zu einer Lösung führt, mit den wenigsten Nachteilen.

Dabei gibt es viele Möglichkeiten mit Vor- und Nachteilen, die es gegeneinander abzuwägen gilt, und abhängig von langfristigen Zielen unterschiedlich gewichtet werden.

Dann werden noch kurzfristige Erfolge gegen langfristige Prioritäten abgewogen und dann zeichnet sich oft eine passende Lösung ab.

Diese Reflexion schafft Klarheit, welche Architekturentscheidungen dauerhaft sinnvoll sind und welche eher kurzfristig den Anforderungen folgen und in Zukunft überarbeitet werden müssen.

2. Planen von Datenmodellen

Anschließend müssen Datenmodelle so gestaltet werden, dass sie einen schnellen Zugriff im Betrieb auf die Daten ermöglichen, Kontext und Informationen erhalten bleiben und auch ein späteres Weiterverarbeiten problemlos möglich ist, ohne Business-Regeln zu verletzen.

Dabei geht es um Regeln wie: Es kann keine Rechnungen ohne Artikel geben, ein Kunde muss immer eine Anschrift haben, aber er darf mehr als eine haben, muss aber eine Standard-Adresse bestimmt haben.

Dank solcher Grundlagen lässt sich die anschließende Herausforderung besser adressieren: Nebenläufigkeit und Skalierung.

3. Nebenläufigkeit und Skalierung

Das Aufteilen von Aufgaben beziehungsweise das Priorisieren und Verteilen auf unterschiedliche Systeme, um Last zu verteilen oder Systeme so zu bauen, dass diese problemlos skalieren können, ist auch ein wichtiger Bestandteil der Software-Entwicklung.

Leider ist es später viel schwieriger, ein bestehendes System so umzubauen, dass es mehr Besucher gleichzeitig schafft. Das wäre dann ein horizontales Skalieren, indem man mehrere Server hinzufügt um die Welle an Anfragen zu bewältigen.

Ebenso ist es aufwendig, ein Projekt schnell auf einen stärkeren Server umzuziehen, damit mehr Leistung verfügbar ist. Das wäre dann vertikales Skalieren, weil man auf einem Server verscucht die Rechnleistung und Arbeitsspeicher zu erhöhen.

Damit ein Projekt live gehen kann, muss schon beim Start auch die Kostenkalkulation im Blick sein.

4. Kostenkalkulation

Kein Projekt wird lange bestehen, wenn es als Lösung für das Problem, welches es lösen soll, zu teuer ist, denn dann kann man es ja wieder von Hand machen (macht keinen Spaß, aber wenn es günstiger ist, würde niemand ändern wollen, wie es gelöst wird).

5. Environments und Reproduzierbarkeit

Um Änderungen vorab testen zu können und sicherzustellen, dass das System beim nächsten Deployment stabil weiterläuft, braucht es auch eine Umgebung, die der produktiven Umgebung ähnelt und nicht der Rechner des Entwicklers ist.

6. Monitoring und Logging

Wenn Business-Regeln verletzt werden, weil Daten fehlen, weil ein Zustand eintritt, der kritisch ist (externer Dienst ist nicht erreichbar), oder andere Erwartungen nicht erfüllt werden, kann es die Zeit bis zum Fix stark reduzieren, wenn es Logs mit Einträgen gibt, die bereits mitteilen, welche Daten nicht der Erwartung entsprechen oder welche Funktion nicht sauber ausgeführt werden konnte und wo im Quellcode dieser Fehler mit welchen Daten aufgetreten ist.

Das kann entscheidend sein, ob ein Onlineshop "nur" fünf Minuten oder mehrere Stunden offline ist, weil der Entwickler bereits eine gute Fehlermeldung sieht oder erst den Quelltext analysieren muss, den Fehler lokal nachstellt und dann Rückschlüsse auf das Produktiv-System ziehen muss.

Ein gutes Logging muss von Anfang an berücksichtigt werden und zahlt sich im Fehlerfall immer aus, wenn dann noch darauf basierend Meldungen beim Auftreten an die Ansprechpartner bzw. Verantwortlichen rausgehen, dann macht das einen riesigen Unterschied, was Umsatz betrifft (z.B. Onlineshop), viel weniger Bauchschmerzen oder gar schlaflose Nächte bei allen Beteiligten.

7. Komplettes Incident-Handling

Was auch nicht zu unterschätzen ist, sind sogenannte Incident Reports, also Meetings mit allen Beteiligten, nachdem es einen Zwischenfall gab.

So ein Meeting hat den Zweck, die Ursache für den Ausfall klar zu benennen und zu identifizieren. Dabei geht es nicht um Personen, sondern um Prozesse, die dazu geführt haben, oder deren Abwesenheit den Incident begünstigt haben.

Sobald die Ursache identifiziert ist, wird besprochen und festgelegt, wie ein erneutes Auftreten verhindert werden kann.

Auch hier entsteht sehr viel Mehrwert und Entwickler können viele technische Möglichkeiten benennen, um sicherzustellen, dass Regeln, die die Software betreffen, eingehalten werden.

Was für mich noch ungeklärt ist:

Wer soll die ganzen vorhin genannten Schritte leisten, wenn niemand den Quelltext kennt und damit die Lösung des Problems unbekannt ist?

Wer übernimmt die Verantwortung für den Quelltext, wenn er ihn nie gesehen hat?

Wie kann ich als Entwickler Vorschläge für Optimierungen machen, wenn ich nicht weiß, wie es jetzt funktioniert?

und am wichtigsten:

Was ist künstliche Intelligenz?

Moderne KI basiert auf statistischen Modellen, meist neuronalen Netzen. Sie speichern keine Fakten als Knoten und Kanten, sondern Wahrscheinlichkeitsverteilungen in Millionen bis Milliarden Parametern. Wissen ist implizit kodiert, nicht explizit abrufbar.

KI ist kein großes Nachschlagewerk. Sie ist ein statistisches Modell der Welt, das Verhalten approximiert. Nicht Wahrheit gespeichert, sondern Wahrscheinlichkeit lernt.

In der KI werden neuronale Netzwerke als Rechengraphen abgebildet, Knoten sind Operationen. Kanten sind Datenfluss. Kein Wissen, keine Semantik, nur Transformationen. Training ist Optimierung entlang dieses Graphen.

Als Beispiel ein Wissensgraph:

Knoten sind Entitäten, Kanten sind Relationen.

Berlin → istHauptstadtVon → Deutschland

Hier kommt Semantik hinzu, aber nur durch menschliche Interpretation oder Regeln. Der Graph selbst denkt nicht.

oder

Neuronales Netz als Rechengraph:

Knoten sind mathematische Operationen, Kanten sind Datenfluss

Eingabe → Gewichtung → Aktivierung → Ausgabe

Das Training passt Gewichte an. Kein expliziter Fakt gespeichert. Kein Knoten für Berlin

Die Beispiele sind vereinfacht, funktionieren aber hoffentlich zur Veranschaulichung, dass das Wort Intelligenz vielleicht mehr Marketingzweck hat, also eine beschreibende Funktion der Eigenschaften.

Fazit: Brauchen wir noch Entwickler, wenn KI besser wird?

JA, denn künstliche Intelligenz ist ein Werkzeug und wird mich in den nächsten Jahren nicht ersetzen, aber sie macht mich schneller, aber dadurch treffe ich nicht automatisch bessere Entscheidungen.

Denn ob die KI richtig liegt oder gerade halluziniert, ob ich mich bewusst für den kurzfrist schlechter wirkenden Weg entscheide, weil ich langfristig plane, das kann mir die KI nicht abnehmen.

Noch besser

Künstliche Intelligenz ermöglicht es Personen, ohne Erfahrung im Programmieren bereits erste Versionen ihrer Idee zu erstellen, und das begrüße ich.

Für mich sind das die Kunden (oder Kollegen) von morgen, heute erstellen sie ihren eigenen MVP und validieren damit bereits ihre Idee, sie machen sich Gedanken um UX, Farben, Texte werden sich klarer in der Intention ihrer Anwendung.

Und tauchen somit tiefer in die Softwareentwicklung ein, als dem einen oder anderen bewusst ist.

Was will ich mehr, als Kunden, die sich bereits Gedanken zu ihrem Produkt gemacht haben, die aber auch merken, dass da noch viel mehr zu tun ist und der Erfolg nicht nur einen Prompt entfernt ist!