Wir haben zu Hause eine Stickmaschine, mit der man Motive auf Stoff sticken kann. Es gibt endlos viele vorgefertigte Dateien mit Bildern, Mustern, Texten – frei oder kostenpflichtig. Will man aber eigene Motive sticken, wird es kompliziert. Es gibt Software dafür, teils kostenlos, teils ziemlich teuer, aber das Thema ist technisch sehr komplex, und die Tools scheinen viele Dinge zu gut machen zu wollen. Sie machen vieles irgendwie, aber selten genau das, was wir wollen: begrenzte Formate, seltsame Konvertierungsfehler, keine Kontrolle über Details. Und ganz ehrlich: Das eigentliche technische Problem dahinter ist so spannend, dass es fast schade wäre, es der Standardsoftware zu überlassen.

Also habe ich angefangen, selbst nachzudenken. Was leistet die Maschine? Sie bewegt den Stoff auf der X- und Y-Achse und setzt einen Stich an der Stelle meiner Wahl. Sie benötigt einfache X/Y-Koordinaten für jeden einzelnen Stich, und davon beliebig viele. Und zwischen zwei Stichen spannt sich der Faden.

Und wie geht das technisch? Die Maschine versteht einen G-Code-Dialekt. Und es gibt mindestens eine Library, mit der ich aus einer Liste von X/Y-Koordinaten eine Stickdatei erzeugen kann.

Und der Rest? Ist Logik, Programmierung und Kreativität. Sollte zu schaffen sein. Also los!

Meine Ausgangsbasis: eine Vektor-Grafik. Mein Ziel: eine breit gestickte Linie und eine Fläche, gefüllt mit einer Schraffur.

Also ein bisschen Mathematik: Welchen Winkel hat der Vektor an welcher Stelle? Ich berechne die Senkrechte dazu, und dann: immer ein Stich links, ein Stich rechts. Ein bisschen ausprobieren: Wie eng muss ich die Stiche setzen, damit es gut aussieht, aber der Stoff noch nicht kaputtgeht? Und dann entsteht eine Liste von verbundenen Punkten. Das lässt sich auch ohne viel Aufwand als Bild speichern, und schon habe ich eine Vorschau.

Und das Ergebnis? Ist erstaunlich gut. Für 100 Zeilen Code. Es ist nicht sonderlich benutzerfreundlich, eher die Hacker-Lösung. Aber sie funktioniert und hat mir die Möglichkeit beschert, mich mit einem spannenden technischen Problem zu beschäftigen. Einfach, weil’s Spaß macht. Weil das Tüfteln an der Lösung genauso faszinierend ist wie das fertige Ergebnis.

Meine Oma fragte mich: „Jung', womit verdienst du eigentlich dein Geld?“

„Ich bin Programmierer, Oma.“

„Programmierer? Was genau machst du denn da? Das hab ich nie verstanden…“

Ok, wie erkläre ich meiner Oma, was "Programmieren" ist. Das wird nicht einfach. Ich hab eine Weile drüber nachgedacht, und diese Metapher für Sie gebaut.

Die Metapher mit dem Amt

Stell dir vor, der Bürgermeister will ein neues Amt gründen. Dieses Amt soll Menschen helfen, wenn ihre Miete zu teuer wird. Sie können dann einen Antrag auf Miet-Unterstützung stellen und bekommen einmalig einen Zuschuss. Du bist der neue Amtsleiter und sollst dieses Amt aufbauen. Du bekommst einen Raum, drei Beamte und diese ganz grobe Beschreibung:

"Jeder Bürger, der mehr als 50% seines Einkommens für Miete ausgeben muss, bekommt einmalig eine Monatsmiete als Zuschuss."

Das ist die Aufgabe des Amtes. Und damit das funktioniert, musst Du dir als Amtsleiter jetzt einen Prozess ausdenken. Du lernst deine drei Beamten kennen und stellst fest: Sie scheinen sehr gewissenhaft und sehr fleißig zu sein. Aber leider scheinen sie nicht sonderlich schlau zu sein. Keiner von ihnen denkt viel nach.

Ok, das heißt, damit aber alles korrekt abläuft, brauchen diese Beamten ganz klare Regeln, klare Aufgaben, keinen Interpretationsspielraum, keine Eigenverantwortung. Dann müssen Sie nicht nachdenken, sondern nur exakt das machen, was auf ihrem Ablaufplan steht. Passend dazu musst Du noch ein Formular entwerfen, damit die Bürger den Zuschuss beantragen können. Die Beamten können diese Formulare nach den Regeln bearbeiten.

Das heißt, deine Aufgabe als Amtsleiter ist:

• Teile die Aufgabe des Amtes so auf, dass sie von drei Beamten erledigt werden kann.
• Schreibe die nötigen Tätigkeiten so auf, dass jeder Beamte einen klaren Aufgaben-Ablauf-Plan bekommt
• Entwerfe ein Formular, wo alle Informationen eingetragen werden können, die für die Zuschuss-Bewilligung, die Zuschuss-Auszahlung und die internen Abläufe gebraucht werden.

Also startest Du, die Aufgaben für die Beamten aufzuschreiben. Vielleicht so:

Die Aufgaben der Beamten

Beamter 1 – Der Eingangsprüfer

1. Morgens holt er neue Anträge aus dem Briefkasten.
2. Zwischendurch nimmt er Anträge entgegen von Leuten, die persönlich vorbeikommen.
3. Er prüft jeden Antrag:
   • Ist der Antrag vollständig ausgefüllt? Sind alle Felder lesbar?
   • Wenn ja, macht er ein Häkchen: „Form OK“
4. Dann legt er den Antrag auf den Schreibtisch des zweiten Beamten.

Beamter 2 – Der Förder-Prüfer

1. Er schaut sich den Antrag auf seinem Tisch an.
2. Dann prüft die Angaben: Er rechnet aus, ob die Miete und das Einkommen im Formular dazu berechtigen, dass der Antragsteller die Unterstützung bekommt.
3. Wenn das passt, schaut er nach, ob die Person schon mal Unterstützung bekommen hat. Dazu sucht er in den Aktenordnern mit den bewilligten Anträgen nach dem Namen.
4. Wenn beides passt macht er ein Häkchen: „Auszahlung bewilligt“
5. Und dann legt er den Antrag auf den Schreibtisch vom Auszahlungs-Beamten.

Beamter 3 – Der Auszahler

Der ist einfach gestrickt.

1. Er nimmt einen Antrag von seinem Tisch.
2. Wenn da das Häkchen „Auszahlung bewilligt“ gesetzt ist, zahlt er Geld aus.
3. Dann heftet er den Antrag in die Aktenordner mit den bewilligten Anträgen.

Damit müsste die Aufgabe erfüllt sein, und die Arbeit einigermaßen gerecht auf die drei Beamten verteilt sein. Und weil alles so klar aufgeschrieben ist, kann man auch einen der Beamten einfach vertreten, wenn mal jemand krank sein sollte. Du als Amtsleiter gehst den Ablauf für alle drei Beamten einige Male im Kopf durch und entscheidest dann: Das ist gut so, so können wir starten. Dann gibst Du jedem Beamten seinen Aufgaben-Plan und lässt die Dinge erstmal laufen.

Die ersten Fehler

Nach drei Tagen gehst Du zu den Beamten, und guckst wie es läuft.

„Und Oma, jetzt stell dir vor, plötzlich stapeln sich beim Auszahlungs-Beamten meterhohe Papierberge!“

„Ach du meine Güte, was für ein Chaos!“, sagt Oma lachend.

Du fragst ihn, was mit den Formularen ist, warum er sie nicht bearbeitet.

Er sagt: "Die sind bearbeitet."

Du nimmst dir ein paar davon und schaust Sie dir an. Sie sind alle abgelehnt. Du rechnest einige davon nach, und stellst fest: Die sind zurecht abgelehnt. "Warum liegen die noch hier", fragst Du den Beamten. Er zuckt nur mit den Schultern. Du liest dir seine Aufgabenbeschreibung durch und stellst fest: Da steht nicht, was er mit abgelehnten Anträgen machen soll. Also hat er nichts mit ihnen getan, und sie liegen lassen. Ok, dein Prozess hat also Lücken, Du solltest ihn nachbessern. Soll er abgelehnte Anträge wegschmeißen, oder in einen "Abgelehnt"-Ordner heften? Das musst Du entscheiden.

Nach einigen Wochen läuft alles einigermaßen rund. Deine Beamten wissen jetzt sogar, was sie machen sollen wenn ein Aktenordner voll ist, und wie man Anträge nach Alphabet abheftet über mehrere Aktenordner hinweg.

Und genau das ist Programmieren: Du entwirfst Regeln, für eine Maschine, die nicht nachdenkt, nicht mitdenkt, kein Vorwissen hat und keine Annahmen trifft. Dann überprüfst Du sie auf Lücken („Bugs“), schließt sie und verbesserst deinen Ablauf immer wieder. Denn jede Schwachstelle, die du übersiehst, nutzt irgendwann jemand aus.“

Der erste Hacker

Und dann passiert etwas, womit Du nicht gerechnet hast. Es kommt ein sehr schlauer Antragsteller, der eigentlich zu viel verdient, um einen Mietzuschuss zu bekommen.

Er weiß:

• Beamter 2 prüft einen Antrag ganz genau, in zwei Schritten.
• Aber er macht nur ein einziges Häkchen, wenn beide Prüfungen bestanden sind.
• Die zweite Prüfung dauert länger, und dafür lässt er den Antrag auf seinem Tisch liegen.

Er schmiedet einen Plan, und der geht so:

1. Antrag A einreichen, mit gefälschten Daten. Förderbar, aber gelogen
2. Beamter 1 prüft: Form OK und legt Antrag A auf den Tisch von Beamter 2.
3. Beamter 2 nimmt Antrag A, prüft: Förderbar? Ja.
4. Dann wälzt er die Aktenordner, um die Historie zu prüfen.
5. Während er den richtigen Aktenordner sucht, kommt der Antragsteller nochmal persönlich vorbei, und reicht Antrag B ein. Mit seinen echten Daten – nicht förderwürdig.
6. Beamter 1 prüft: Form OK → legt Antrag B auch auf den Tisch von Beamter 2.
7. Beamter 2 kommt von der Historie-Prüfung zurück.
8. Jetzt liegt auf seinem Tisch Antrag B ganz oben. Der Name stimmt überein mit dem, was er gerade prüft, also denkt er: „Alles geprüft. Alles passt. Jetzt nur noch Häkchen setzen.“
9. Und zack: er setzt das Häkchen bei „Auszahlung bewilligt“ auf Antrag B. Den Antrag, den er gar nicht geprüft hat.

Und das Ergebnis: Beamter 3 sieht das Häkchen und zahlt aus.

Antrag B wird ausgezahlt. Obwohl Antrag B nicht förderwürdig war. Weil Beamter 2 dachte, er hätte ihn geprüft – aber er hat nur Antrag A geprüft.

Es war einfach ein kleiner Trick – ein Moment, in dem das System blind war.

Ist der Antragsteller jetzt ein Betrüger? Ja und Nein. Sicher hat er das System ausgetrickst, aber er hat nichts verbotenes getan. Es war der Fehler des Amtes, den Antrag zu bewilligen, obwohl die korrekten Daten darin es verboten hätten.

Hat einer der Beamten falsch gearbeitet? Nein, jeder hat genau seine Aufgaben gemacht.

Das Problem ist, Du hast einen Fehler in deinem ausgedachten Prozess. Eine Lücke, oder ein "Bug" in der Programmierer-Sprache. In der Informatik nennt man das eine ‚Race Condition‘, also einen Fehler, der auftritt, weil zwei Dinge gleichzeitig passieren und sich dabei gegenseitig stören.

Probleme über Probleme

Ok, also musst Du den Prozess wohl nochmal nachschärfen...

Und Du wirst ihn auch danach noch einige Male nachschärfen müssen. Zum Beispiel für den fiesen Bürger, der zwei Anträge direkt hintereinander stellt.

Warum das ein Problem ist?

Weil zu viel Zeit vergeht zwischen "Check ob schonmal gefördert wurde" und "Ablage, dass gefördert wurde". Mit zwei förderfähigen Anträgen direkt hintereinander kann jemand doppelt gefördert werden, obwohl die Förderbedingungen das verbieten. Auch das ist eine Lücke im System.

Deshalb ist Programmieren vor allem eins, Oma: Sich vorher genau überlegen, was passieren könnte, und Regeln so aufzuschreiben, dass nichts schiefgehen kann. Leider gelingt das nicht immer beim ersten Mal. Deshalb arbeiten Programmierer ständig daran, Fehler aufzuspüren und ihre Programme zu verbessern.

Das ist mein Job, und ich mache ihn gerne!

Alte Java-Software. So richtig alt. Java 1.4. Das Zeitalter der XML-Parser, Servlet-Container, und EJB 2.1. Der Code: gewachsen, durchlebt, durchlitten. Und jetzt sollte ich ihn modernisieren. Nicht neu schreiben. Nur “mit einem aktuellen Java neu compilieren“. Klingt harmlos. War es nicht.

Der Code

Der Code war ein lebendes Archiv. Entwickler:innen hatten hier ihre ersten Schritte mit Java gemacht. Und man spürte es. Da war alles drin: Begeisterung, Lernkurven, Spuren nächtelanger Debug-Sessions. Und ein Architekt hatte sich ausgetobt – mit Hingabe. Jedes SQL-Statement wanderte durch mindestens drei Schichten: Model, Factory, und-noch-irgendwas-Klasse. Die Factories-Parent-Klassen waren so generisch, dass der einzige Hinweis auf den Inhalt einen Tabellennamen-String im Konstruktor war. Maximale Entkopplung von allem. Sogar das Datenbank-Connection-Pooling war selbst implementiert, und das in Zeiten von EJB2.1. Dafür aber alles streng nach Pattern. Viele Schichten Zwiebelmodell verstecken seitenweise handgeschriebenes SQL.

Die Fachlogik steckte in EJB-Beans. Viele davon. Sehr viele. Ihre Namen? SBM0001 bis SBM0430. Ein durchnummeriertes Rätselraten, aber mit Lücken. Angeblich gab es mal eine Excel-Liste, die Nummern und fachliche Funktionen verband, aber die war verloren gegangen. Vielleicht bei einem Festplattencrash. Vielleicht in der Kantine. Vielleicht nie wirklich existent. SBM0002 stellte sich irgendwann als Benutzerverwaltung heraus. SBM0037 hatte mit Konfiguration zu tun. Und dann wurde es kryptisch. Es ging um Pharmazie, wissenschaftliche Analyse-Daten, Molekülformate, Strukturbeschreibungen. Tiefes Wissen, verpackt in alte Klassen. Ich habe dann eine neue Excel-Liste begonnen...

Meine Aufgabe

Meine Aufgabe war, das Ganze für eine moderne Java-Version fit machen. Kein Rewrite, kein Big Bang. Sanfte Evolution, minimal-invasiv. Hauptsache, es kompiliert. Natürlich blieb es nicht dabei. Sobald das Projekt sichtbar lief, kamen andere Themen auf den Tisch: Da war noch diese Liste mit Bugs, die man nie lösen konnte, weil das Projekt gar nicht mehr baubar war. Plötzlich ging es nicht nur um Portierung, sondern um Reparatur, Verständnis, Forschung. Und dann – irgendwo zwischen SBM0098 und SBM0112 – stieß ich auf einen JNI-Import. Eine native C++-Komponente wurde angebunden. Ein uraltes .so-File wurde referenziert. Nach Freitext-Suche habe ich einen Hinweis in einem Build-Script gefunden. Aber Sourcecode? Fehlanzeige! E-Mail-Archive gekündigter Mitarbeiter wurde durchforstet. Backups alter Server wurden ausgegraben und hochgefahren... zum Glück wurde der Code gefunden. C++ Code mit Spaghetti-Geschmack. Und nicht compilierfähig. Ich kann C++ für den Hausgebrauch, aber nicht für sowas. Also meinen Experten-Kumpel angerufen... eine Nacht gemeinsam durchgehackt, und das Ding compiliert wieder. Puh, Glück gehabt. War spannend, dem Meister über die Schulter zu schauen.

Das Ergebnis

Es läuft! Mit einem aktuellen Java, auf 64 Bit, inklusive der angebundenen C++-Bibliothek und des Swing Fat (XXL) Clients. Ich war stolz!

Mein Learning

Was habe ich dabei mitgenommen? Was habe ich gelernt?

Es mag komisch klingen, aber am hilfreichsten war für mich die Architektur.

Der Architekt hat ganze Arbeit geleistet. Ja, die Architektur ist over-engineered, aber dafür absolut konsequent durchgezogen. Es hat etwas gedauert, die Schichten zu verstehen. Aber dann waren sie in jedem der kryptischen Module gleich. Und das war Gold wert!

Ich habe gelernt: Wenn etwas nicht ideal ist, und ich es erweitern muss, dann bleibe ich bei dem nicht idealen Ansatz. Denn Homogenität ist wertvoller, als eine Ecke etwas glänzender zu haben. Wenn das nicht Ideale so schlimm ist, dass man es umstellen kann, dann kann man alles auf einmal umstellen, und muss nicht jede Ecke einzeln betrachten.

Mein Fazit

Für mich persönlich war es spannend, nervig, zum Heulen und hatte Anteile von Indiana-Jones. Ein simples 32-zu-64-Bit-Projekt ist komplett aus dem Ruder gelaufen. Eine einfache Portierung wurde zur archäologischen Expedition. Gut, dass ich mich geweigert hatte, eine Zeitschätzung abzugeben. Legacy-Projekte folgen ihren eigenen Regeln.

Und trotzdem, oder gerade deshalb, war es großartig. Denn jeder Stolperstein war ein Fenster in die Vergangenheit. Ich habe nicht nur Code gelesen, ich habe Geschichten gelesen. Entscheidungen verstanden. Tricks bewundert. Und Respekt entwickelt. Ich mache so etwas wahnsinnig gerne!

Legacy Code ist kein Müll. Es ist ein Zeitdokument. Wer ihn verstehen will, braucht Geduld. Und wer ihn pflegt, wird belohnt mit echtem Verständnis, mit gewachsener Software und mit Geschichten, die kein Greenfield-Projekt je schreiben könnte.

Heute

Die Software ist seit Jahren offiziell "End-of-Life". Es wird keine Patches mehr geben. Meine Modernisierung wird das letzte gewesen sein, was diese Software erlebt hat. Das ist lange her. Und trotzdem sind heute immer noch einige Pharma-Konzerne damit beschäftigt, diese Software abzulösen. Keine aktuelle Standardsoftware bietet alle diese Funktionen. Und alle scheuen sich (zu Recht) vor einer Eigen-Implementierung. Einige haben das alte Ding abgelöst, unter schmerzhaftem Verzicht auf Funktionen.

Unterm Strich bleibt die Erkenntnis: Es ist alt, es ist nicht gut gepflegt, aber es hat alle Reifungsphasen hinter sich gebracht und ist extrem stabil getestet. Und es hat unglaublich viele Funktionen.

Die alte Software ist nicht schlecht. Man ist nur nicht gut mit ihr umgegangen. Hätte man sie in den letzten 20 Jahren behutsam modernisiert, wäre sie jetzt marktbeherrschend. Aber Manager hatten andere Prioritäten, oder haben diese Chance vielleicht nicht mal wahrgenommen.

Aus meiner Entwickler-Perspektive blutet mir das Herz.

30 Kinder und Jugendliche, eine Woche Ferienfreizeit im Schullandheim. Tagsüber Programmieren und Natur erleben, abends Lagerfeuer, Spiele und später eine Nachtwanderung. Ausgelassene Stimmung, fernab der Eltern und mittendrin: ein Haufen alter Laptops mit Minecraft.

Das Ziel

Erste Berührung mit Programmierung.

Der Plan

Die Motivation und Begeisterung für Minecraft nutzen, um über „Plugin-Programmierung“ den Einstieg ins Programmieren zu ermöglichen.

Höchste Priorität

Die Kinder in die Lage versetzen, möglichst schnell ihre eigenen Ideen umzusetzen. Und fantasievolle Ideen haben sie mehr als genug.

Los geht's

Die Kinder sind voller Tatendrang. Sie wollen jede freie Minute an den Laptops verbringen, um sich auszuprobieren, zu tüfteln, zu hacken. Da ist kein Platz für Theorie, Grundlagen, saubere Strukturen oder Best Practices. Es geht darum, die Begeisterung zu nutzen und schnell produktiv zu werden.

Die Kinder stellen mehr Fragen, als ich beantworten kann. Zwischen „Guck mal, wie cool!“ und „Verdammt, wo ist das Problem?“ ist alles dabei. Kreativität auf allen Ebenen, auch im Code. Was da entsteht, spottet jeder „Clean Code“-Checkliste:

• Funktionen in Funktionen in Funktionen
• Keine Trennung von Logik und Darstellung
• Variablennamen wie bla, ding, michael3
• Dateinamen wie Monster-neu-neu-copy(3)

Aber es läuft. Und die Augen leuchten, wenn die eigenen Ideen plötzlich im Lieblingsspiel lebendig werden. Wenn das erste selbst gestaltete Monster im Spiel auftaucht, ist die Begeisterung riesig, auch wenn es auf dem Kopf steht. Anfängerfehler! Egal. Gehört dazu!

Pragmatismus pur!

Ob etwas gut oder schlecht ist, entscheidet hier nur ein Kriterium: Funktioniert es? Dann ist es gut!

Innerlich dreht sich mir manchmal der Magen bei den wilden Spaghetti-Konstrukten. Gegen jede eigene Erfahrung, gegen jede Intuition und garantiert gegen jedes Lehrbuch. Aber der Autor kann genau erklären, warum er’s so gemacht hat. Was funktioniert hat und was nicht. Und vor allem was er als Nächstes probieren will.

Und genau das ist der Punkt.

Best Practices sind wichtig aber nur dann, wenn das Umfeld sie braucht. Wenn ich Software baue, die zehn Jahre überleben soll, von anderen gepflegt wird oder sicherheitskritisch ist: Klar, dann zählen Wartbarkeit, Lesbarkeit, Struktur.

Aber wenn’s um die ersten Schritte geht? Um die Erfahrung, dass mein Code etwas zum Blinken bringt, sich bewegt, lebt?

So ist aller Anfang

In diesem Umfeld gilt: Jeder Fehler ist erlaubt. Jeder Hack ist ein Schatz.

Weil man daran wächst. Weil man ausprobiert, versteht, umdenkt. Und weil nichts mehr motiviert als ein schneller Erfolg, selbst wenn der Weg dahin dreckig war.

Ich erinnere mich gern an meine ersten Programmiererfahrungen, bei denen ich heute auch die Hände über dem Kopf zusammenschlagen würde. Ich habe genau dieselben Fehler gemacht, und ohne sie wäre ich heute nicht da, wo ich bin.

Ich freue mich über jedes Kind, das in diesen Workshops Fehler macht und daraus lernt. Egal, ob sie später mal beruflich etwas mit Code machen oder nicht: Sie alle haben erfahren, wie es ist, durch eigenes Tun zu lernen. Und das hilft! Nicht nur beim Programmieren, sondern im ganzen Leben.

Ich bin dankbar, den Kindern diese Erfahrung mit auf den Weg zu geben.