Die Zunft
Werdegang und Zukunftsbild des Software-Developers — von einem Algorithmus ohne Maschine bis zu einer Maschine, die Algorithmen schreibt.
Diese Seite altert mit ihrem Gegenstand. Sie beginnt auf Papier, weil der Beruf auf Papier begann — und sie kippt dort ins Digitale, wo der Beruf es tat. Scrolle weiter, und das Licht im Raum geht aus.
Ein Algorithmus ohne Maschine
Das Programmieren war hundert Jahre älter als der Computer — und hatte in dieser Zeit keinen Namen, keinen Arbeitgeber und keinen Markt.
1843 übersetzte Ada Lovelace einen Aufsatz über Babbages geplante Analytical Engine — und hängte Anmerkungen an, die länger waren als der Text selbst. In Note G steht eine vollständige Rechenvorschrift für die Bernoulli-Zahlen: mit Schleife, mit Zwischenvariablen, mit Sprung.
Die Maschine dazu wurde nie fertig. Genau das macht die Stelle so aufschlussreich: Das Programm war zuerst da, die Hardware kam später. Wer heute eine Spezifikation schreibt, bevor eine Zeile Code existiert, tut nichts anderes.
Was in dieser Epoche fehlte, war nicht die Tätigkeit, sondern die Rolle. Es gab niemanden, der sich davon ernährte. Ein Beruf braucht mehr als eine Fähigkeit: Er braucht jemanden, der dafür bezahlt.
Programmieren war Handarbeit
Der Beruf beginnt als körperliche Tätigkeit: Kabel stecken, Schalter stellen, Lochkarten sortieren. Und er beginnt mit Frauen.
Der ENIAC wurde 1945 in Betrieb genommen. Wer ihn programmierte, hieß damals nicht Programmierer, sondern Operator — und war in den ersten Jahren fast ausschließlich weiblich. Sechs Frauen richteten die Rechenläufe ein, ohne Handbuch, direkt aus den Schaltplänen.
Die entscheidende Verschiebung kam 1952 mit Grace Hoppers A-0: dem ersten System, das Programme in Maschinencode übersetzte. Der Widerstand dagegen war beträchtlich — ein Rechner, hieß es, könne keine Programme schreiben.
Das Muster wiederholt sich in diesem Report noch dreimal: Eine Tätigkeit, die als unersetzlich galt, wird an eine Maschine abgegeben, und der Beruf rückt eine Etage höher. Er verschwindet nicht. Er wechselt die Abstraktionsebene.
Der Beruf bekommt einen Namen — in einer Krise
„Software Engineering“ war keine Auszeichnung. Der Begriff wurde 1968 als Provokation gewählt, weil die Projekte reihenweise scheiterten.
Mit FORTRAN (1957), COBOL (1959/60) und ALGOL 60 bekommt der Beruf eine Sprache, die Menschen lesen können. Die Folge ist nicht Entlastung, sondern Maßstabssprung: Wer mehr schreiben kann, bekommt größere Aufgaben — und größere Aufgaben scheitern anders.
Im Oktober 1968 ruft die NATO nach Garmisch zu einer Konferenz, die dem Problem einen Namen gibt: Software Engineering. Der Begriff war programmatisch gemeint, fast trotzig — eine Ingenieursdisziplin einfordern, die es noch nicht gab.
Von hier an hat der Beruf zwei Seelen, die er bis heute nicht versöhnt hat: die des Handwerks, das Dinge baut, und die der Ingenieurskunst, die beweisen soll, dass sie halten.
Struktur, kleine Werkzeuge, und die Entdeckung des Menschen
Die Antwort auf die Krise war dreifach: Ordne den Code. Baue kleine Teile, die zusammenpassen. Und rechne damit, dass das Nadelöhr nicht die Maschine ist, sondern die Absprache.
1968 veröffentlicht Dijkstra seinen Einwand gegen den unbeschränkten Sprung. Die strukturierte Programmierung setzt sich durch, weil sie etwas liefert, das der Beruf dringend braucht: lesbaren Kontrollfluss.
Zur selben Zeit entsteht in den Bell Labs Unix (ab 1969) und mit ihm C (ab 1972). Die kulturelle Leistung ist nicht die Sprache, sondern die Pipe: kleine Programme mit einem so schmalen Vertrag, dass sie kombinierbar sind, ohne dass ihre Autoren je miteinander reden müssten.
1975 schreibt Fred Brooks „The Mythical Man-Month“ und formuliert den unbequemsten Satz des Berufs: Mehr Leute auf ein verspätetes Projekt machen es später. Der Engpass ist nicht die Tastatur, sondern die Absprache — und die wächst quadratisch.
Werkzeug-Archäologie
Vier Werkbänke, sechzig Jahre. Nicht die Namen sind die Geschichte, sondern was jede Stufe an Arbeit verschwinden ließ.
| Zeit | Werkbank | Was dadurch entfiel |
|---|---|---|
| 1945 | Steckfeld, Kippschalter | — |
| 1955 | Lochkarte, Stapelbetrieb | Das physische Umstecken |
| 1970 | Zeileneditor am Terminal | Die Wartezeit bis zum nächsten Lauf |
| 1983 | Turbo Pascal: Editor + Compiler in einem | Der Werkzeugwechsel selbst |
| 2000 | IDE mit Refactoring-Befehlen | Das Umbenennen von Hand |
| 2021 | Vervollständigung aus einem Sprachmodell | Der Weg von der Absicht zum Entwurf |
| Zeit | Werkbank | Was dadurch entfiel |
|---|---|---|
| 1960er | Kartenstapel im Schrank, datiert | — |
| 1982 | RCS: Versionen je Datei | Das Kopieren ganzer Verzeichnisse |
| 1990 | CVS: ein Server fürs ganze Projekt | Die Absprache, wer gerade schreibt |
| 2000 | Subversion: atomare Übergaben | Der halb eingespielte Stand |
| 2005 | Git: jede Kopie ein volles Archiv | Die Erlaubnis, überhaupt zu verzweigen |
| Zeit | Werkbank | Was dadurch entfiel |
|---|---|---|
| 1976 | make: Abhängigkeiten als Regeln | Das Merken der Bau-Reihenfolge |
| 1990er | Nächtlicher Gesamtbau | Die Wochen bis zum ersten Zusammenbau |
| 2000er | Laufende Integration bei jeder Übergabe | Der Integrationsschock am Projektende |
| 2013 | Container: die Umgebung wird mitgeliefert | „Bei mir läuft es“ |
| 2015 | Auslieferung als Pipeline-Schritt | Der Freitagabend-Rollout |
| Zeit | Werkbank | Was dadurch entfiel |
|---|---|---|
| 1947 | Der Motte im Relais — Fehlersuche als Inspektion | — |
| 1970er | Ausgabezeilen an verdächtigen Stellen | Das Anhalten der ganzen Maschine |
| 1990er | Haltepunkte, Einzelschritt, Variablenansicht | Das Raten über den Zustand |
| 2000er | Automatisierte Tests als Netz | Die Angst vor dem Umbau |
| 2010er | Ablaufverfolgung über Dienstgrenzen | Der blinde Fleck zwischen zwei Systemen |
Der Rechner kommt auf den Schreibtisch
Zum ersten Mal gehört die Maschine dem Entwickler. Das verändert nicht nur die Arbeit, sondern wer sie überhaupt beginnen darf.
Der IBM PC von 1981 und Turbo Pascal von 1983 verschieben die Eintrittsschwelle radikal. Vorher brauchte man eine Institution, um überhaupt an eine Maschine zu kommen. Jetzt genügt ein Schreibtisch. Der Beruf wird zugänglich — und zum ersten Mal auch autodidaktisch erlernbar.
Gleichzeitig wird die Ordnung zum Thema. Die Objektorientierung (Smalltalk-80, C++ ab 1985) verspricht, große Systeme durch Hüllen beherrschbar zu machen. Die Versionsverwaltung (RCS 1982, CVS 1990) erlaubt erstmals eine zweite Wahrheit auf Zeit: den Zweig.
Beides sind Antworten auf dieselbe Frage — die aus Kapitel 4. Wie arbeiten viele an einem Ding, ohne sich ständig abzustimmen? Die Hülle trennt im Raum, der Zweig in der Zeit.
Der Rückkanal wird geöffnet
Zwei Dinge passieren gleichzeitig: Software verlässt die Schachtel, und die Zunft widerspricht ihren eigenen Vorgesetzten. Beides hängt zusammen.
Im September 1991 veröffentlicht ein Student die Version 0.01 eines Betriebssystemkerns. Die eigentliche Neuerung ist nicht die Lizenz, sondern der Rückkanal: Zum ersten Mal verbessern Menschen ein System, die niemand dafür eingestellt hat.
Im Februar 2001 treffen sich siebzehn Praktiker in Snowbird und schreiben vier Wertepaare auf. Das Agile Manifest ist weniger eine Methode als ein Standesdokument: Die Zunft beansprucht, selbst zu bestimmen, wie sie arbeitet.
Hier endet die Papier-Epoche dieses Reports — nicht, weil die Technik sie beendet hätte, sondern weil sich der Arbeitsgegenstand ändert. Bis hierher wurde Software hergestellt und ausgeliefert. Ab jetzt wird sie betrieben. Das ist der größte Bruch im ganzen Bogen.
Wohin die Stunden wandern
Der Beruf hat nie an Arbeit verloren. Er hat sie verschoben — jedes Mal eine Etage höher.
Dieselben Zahlen als Tabelle
| Anteil in % | 1960 | 1975 | 1990 | 2005 | 2020 | 2035 |
|---|---|---|---|---|---|---|
| Schreiben & Übersetzen | 55 | 45 | 38 | 30 | 22 | 12 |
| Zusammenfügen | 15 | 20 | 25 | 30 | 30 | 28 |
| Betreiben & Absichern | 20 | 20 | 17 | 22 | 26 | 25 |
| Urteilen & Abnehmen | 10 | 15 | 20 | 18 | 22 | 35 |
Jede Stufe — Compiler, Hochsprache, Bibliothek, Cloud, Agent — nimmt dem Beruf eine Tätigkeit ab, die vorher als sein Kern galt. Und jedes Mal wurde daraus nicht weniger Arbeit, sondern größere Systeme.
Der einzige Anteil, der in achtzig Jahren nie kleiner wurde, ist Urteilen: entscheiden, was gebaut wird, ob es stimmt, und was der Schaden ist, wenn nicht. Genau dort landet die Kurve am rechten Rand.
Der Entwickler wird Betreiber
In zehn Jahren bekommt der Beruf ein neues Archiv, einen neuen Marktplatz, ein neues Rechenzentrum — und eine Rufbereitschaft.
2005 baut Linus Torvalds in wenigen Wochen Git — nicht als Produkt, sondern als Notlösung für den Kernel. Der Nebeneffekt verändert den Beruf mehr als die Absicht: Wenn Verzweigen nichts mehr kostet, wird der Vorschlag zur normalen Umgangsform. Der Pull Request ist der Rückkanal aus Kapitel 6, in ein Werkzeug gegossen.
2006 vermietet Amazon Speicher und Rechenzeit. Damit verschwindet die letzte physische Hürde des Berufs — und gleichzeitig eine Abteilung: Wer den Server mietet, betreibt ihn auch. Ab 2009 hat das einen Namen, DevOps, und ab da auch eine Telefonnummer, unter der man nachts erreichbar ist.
2008 kommt mit GitHub und Stack Overflow etwas Drittes dazu: Der Beruf wird öffentlich einsehbar. Man bewirbt sich nicht mehr nur mit einem Lebenslauf, sondern mit einem Profil. Das ist Chance und Zumutung in einem.
- 2005Git und Mercurial erscheinen im selben Jahr. Verteilte Versionsverwaltung wird Normalfall.
- 2006S3 und EC2 gehen an den Start. Infrastruktur wird zu einer Zeile Konfiguration.
- 2008GitHub, Stack Overflow und der App Store im selben Jahr: Archiv, Wissensspeicher und Vertriebsweg werden öffentlich.
- 2009Die ersten devopsdays in Gent. Die Trennung von Entwicklung und Betrieb beginnt zu fallen.
- 2013 / 2014Docker und Kubernetes. Die Umgebung wird Teil der Lieferung — und der Betrieb Teil des Entwurfs.
Etwas am Tisch schreibt mit
Zum fünften Mal in diesem Report gibt der Beruf eine Tätigkeit ab, die als sein Kern galt. Diesmal ist es das Schreiben selbst.
Vom Werkzeug zum Gegenüber
Ein Werkzeug führt aus, was man ihm sagt. Ein Gegenüber schlägt etwas vor, das man prüfen muss. Der Unterschied ist die ganze Veränderung dieses Kapitels.
Im Juni 2021 erscheint GitHub Copilot als technische Vorschau, ein Jahr später allgemein verfügbar. Im November 2022 macht ChatGPT dieselbe Fähigkeit für alle sichtbar. Innerhalb von drei Jahren verschiebt sich die Frage von „Wie schreibe ich das?“ zu „Stimmt das, was hier steht?“
Das ist keine kleine Verschiebung. Schreiben und Prüfen sind verschiedene Tätigkeiten mit verschiedenen Ermüdungskurven. Wer schreibt, baut sich das Modell des Systems im Kopf nebenbei mit auf. Wer nur prüft, bekommt es nicht geschenkt — und merkt das erst, wenn etwas schiefgeht.
Die ehrliche Zwischenbilanz 2026: Der Beruf ist schneller geworden und unsicherer zugleich. Die Werkzeuge liefern Entwürfe in Sekunden; die Verantwortung für das Ergebnis ist keinen Millimeter gewandert.
-
B-1 Der Entwurf wird billigWas früher eine Stunde Tippen war, ist ein Absatz Beschreibung. Der Engpass verschiebt sich von der Erzeugung zur Auswahl.
-
B-2 Das Prüfen wird teuerFremder Code ist schwerer zu beurteilen als eigener — und maschinell erzeugter Code sieht immer plausibel aus. Plausibilität war noch nie ein Beleg.
-
B-3 Der Aufbau von Kompetenz bekommt eine LückeDie mühsamen Anfängerjahre waren nie nur Produktion — sie waren Ausbildung. Wenn die Maschine sie übernimmt, fehlt der Weg zum Urteil, das man in Kapitel 9 braucht.
Drei Szenarien statt einer Prognose
Wer den Beruf vorhersagt, hat ihn nicht verstanden. Was sich sagen lässt: welche drei Kräfte gerade ziehen — und woran man erkennt, welche gewinnt.
Alle drei Szenarien teilen eine Annahme, die dieser Report in acht Kapiteln belegt hat: Der Beruf verschwindet nicht, wenn eine Tätigkeit abgegeben wird. Er zieht um. Die Frage ist nur, wohin.
Der Dirigent
Der Beruf beschreibt Absichten, Agenten schreiben aus. Die Arbeit besteht aus Zerlegung, Spezifikation und Abnahme — und aus der Architektur, die entscheidet, welche Fehler überhaupt möglich sind. Es ist die Fortschreibung dessen, was seit 1952 fünfmal passiert ist.
Sein Preis: Wer nie selbst gebaut hat, kann nicht beurteilen, was er abnimmt.
Der Verifizierer
Wenn Code beliebig billig wird, wird Vertrauen das knappe Gut. Der Schwerpunkt wandert zu Tests, Typen, Beweisen, Bedrohungsmodellen, Nachweisführung und Haftung. Der Beruf ähnelt dann weniger dem Schreiner als dem Prüfingenieur.
Sein Preis: Die Beweislast wächst mit der Menge des Erzeugten — und die wächst gerade sehr schnell.
Der Domänen-Handwerker
Allgemeiner Code kommt aus der Maschine; wertvoll bleibt, was sie nicht wissen kann: wie eine Station wirklich arbeitet, welche Ausnahme das Gesetz meint, warum die Lieferkette am Dienstag anders läuft. Der Beruf löst sich teilweise in andere Berufe hinein auf — und wird dort unersetzlich.
Sein Preis: Der gemeinsame Berufsstand aus Kapitel 6 zerfällt in Nischen.
Alle drei, nebeneinander
Der Beruf war noch nie einer. 1975 gab es den Systemprogrammierer und den Anwendungsentwickler; 2010 den Frontend-Bauer und den Betreiber. Die drei Szenarien beschreiben keine Abzweigungen, sondern drei Spezialisierungen, die gleichzeitig entstehen — so wie es der Bogen dieses Reports jedes Mal getan hat.
Was in achtzig Jahren nie abgegeben wurde
Fünf Mal hat der Beruf eine Tätigkeit an eine Maschine abgetreten. Vier Dinge hat er jedes Mal behalten — und sie sind der Grund, warum es ihn noch gibt.
Zerlegen
Ein großes Problem in Teile schneiden, die einzeln stimmen und zusammen halten. Die Schnittstelle ist älter als jede Sprache.
Zweifeln
Die Frage „Woher weiß ich, dass das stimmt?“ stellt sich seit dem ersten Compiler unverändert. Plausibel aussehen heißt nie richtig sein.
Sich abstimmen
Brooks' Rechnung von 1975 gilt unverändert. Jede Architektur ist auch eine Aussage darüber, wer mit wem reden muss.
Geradestehen
Wer eine Maschine schreiben lässt, hat sie trotzdem gebaut. Verantwortung ist die einzige Aufgabe im ganzen Bogen, die sich nicht delegieren ließ.
Der Software-Developer war nie der Mensch, der tippt. Er war immer der Mensch, der entscheidet, was gebaut wird — und dafür einsteht, dass es hält.