Technik verstehen, Lösungen gestalten – Igor Arenz.

Software-Entwicklung ist mehr als

Sourcecode Sourcecode
3d-druck

Herzlich Willkommen

Persönliches

Hallo, mein Name ist Igor Arenz.

Ich bin Software-Entwickler Lead-Developer,
Senior-Architekt,
Berater und Experte mit über 20 Jahren Erfahrung in der professionellen Softwareentwicklung.

Was mich auszeichnet? Tiefes technisches Verständnis und ein Gespür für das große Ganze: Fachlichkeit, Unternehmensziele und der Weg zu Lösungen, die mehr leisten als nur zu funktionieren.

In zwei Jahrzehnten habe ich Software nicht nur gebaut, sondern auch analysiert, wiederbelebt, am Leben gehalten und dort, wo nötig, gezielt ersetzt oder abgeschaltet. Ich kenne den gesamten Lebenszyklus von Systemen und begleite ihn mit Weitblick.

Für mich basieren gute Projekte auf Vertrauen, Klarheit und echter Zusammenarbeit. Ich arbeite als langfristiger Partner und entwickle gemeinsam mit meinen Kunden Lösungen, die auch in zehn oder zwanzig Jahren noch funktionieren.

Igor Arenz Portraitbild
Igor Arenz mit Kollegen

Zielgruppe

Ich arbeite am liebsten mit Menschen, die Verantwortung für funktionierende Systeme tragen, egal ob CTOs, Teamleiter:innen, Produktverantwortliche oder Geschäftsführer:innen. Wenn Sie einen zuverlässigen technischen Partner suchen, der nicht nur sauber programmiert, sondern mitdenkt, hinterfragt und langfristige Lösungen schafft, dann sollten wir ins Gespräch kommen.

Ich unterstütze Sie besonders gern, wenn Sie...

  • mit gewachsenen, unternehmenskritischen Systemen arbeiten
  • sich in einer kritischen Phase befinden
  • tiefergehende technische Entscheidungen treffen müssen
  • ein stabiles Gegenüber für Entwicklung, Architektur und Codequalität suchen

Ob Industrie, Mittelstand oder Startup: Ich bringe Klarheit, Struktur und Bewegung in technische Herausforderungen. Und ich bleibe auch dann, wenn es kompliziert wird.

Wert, den ich einbringe

Ich entwickle Lösungen, die den richtigen Punkt treffen, zwischen einer präzisen Abbildung der Realität und der nötigen Vereinfachung. So entstehen Architekturen, die flexibel bleiben, statt bei kleinen Änderungen aus dem Ruder zu laufen. Systeme, die sich weiterentwickeln können, ohne zur Last zu werden.

Durch Erfahrung erkenne ich schnell, wo Dinge unnötig kompliziert sind und wo sie es vielleicht bald werden. Ich sehe, was technisch funktioniert, aber fachlich nicht greift. Und ich finde Wege, wie sich Systeme mit ihrem Umfeld mitbewegen können, statt dagegen zu arbeiten.

Technologie ist dabei nur ein Werkzeug. Wichtig, aber nicht der Anfang. Oft liegt die Lösung auf einer anderen Ebene: im Vorgehen, in der Kommunikation, in der Klarheit über Ziele und Abhängigkeiten. Wenn Software der richtige Hebel ist, stelle ich die passende Lösung auf die Beine – ob Standard, Anpassung oder etwas Neues.

Igor Arenz bei der Arbeit
Igor Arenz spielt Saxophon

Privates

Ob etwas Beruf oder Berufung ist, zeigt sich oft im Privaten. Für mich ist Technik beides: Leidenschaft und Spielwiese. In meiner Freizeit beschäftige ich mich mit:

  • dem Entwickeln elektronischer Schaltungen, dem Layouten von Platinen und deren Herstellung
  • 3D-Design und dem Druck praktischer Dinge, die das Leben leichter machen
  • dem Reparieren, Tüfteln und Makern. Von der Armbanduhr bis zum Segelflugzeug
  • der Nachwuchsförderung: Ferienfreizeiten mit Programmieranteil, Workshops in Museen, Schul-AGs und überall dort, wo Kinder und Jugendliche Technik entdecken wollen
  • dem Saxophon, einem Instrument mit überraschend komplexer Mechanik

Angebote

Rund um ihren Code

Problematische Bereiche

Sie haben ein Problem, an das sich niemand rantraut? Oder Kollegen sind bereits gescheitert? Kein Grund aufzugeben! Ich habe schon einige unlösbare Probleme gelöst, und auch Ihre harte Nuss schaue ich mir gerne an. Wir knacken sie gemeinsam, strukturiert und mit der nötigen Geduld. Ob ich’s einfach löse, den Weg erkläre oder wir es zusammen angehen entscheiden Sie.

Archeologie

Gerne helfe ich Ihnen dabei, verwaiste und ungepflegte Software wieder zum Leben zu Erwecken. "Legacy Code" ist nicht jedermenschs Liebling. Ich habe intensive Erfahrung mit schwer wartbarem Code, zu dem keine Knowhow-Träger mehr verfügbar sind. Und oft ist es sinnvoll, alte (erprobte, gereifte) Dinge am Leben zu erhalten anstatt sie wegzuschmeißen.

Sicherer Code

Als ehemaliger "Certified Ethical Hacker" habe ich einen geschulten Blick für Sicherheitslücken, im Code und in der Architektur. Ich erkenne typische Schwachstellen, unsaubere Schnittstellen und gefährliche Annahmen frühzeitig. Gerne helfe ich Ihnen, Ihre Systeme sicherer zu machen, durch Reviews, klare Prinzipien und pragmatische Maßnahmen, die wirklich wirken.

Was ich nicht mache

Wenn Sie jemanden suchen, der Tickets abarbeitet oder ein Standardprojekt „nach Vorgabe“ umsetzt, dann bin ich wahrscheinlich nicht der Richtige. Ich arbeite nicht nach Schema F, sondern dort, wo es komplex wird, Entscheidungen gebraucht werden und echtes Mitdenken gefragt ist. Mein Mehrwert entsteht dort, wo Technik, Strategie und Verantwortung zusammenkommen.

Rund um Entwickler

Coaching

Ich begleite angehende Entwickler:innen praxisnah und mit technischem Tiefgang. Komplexe Themen vermittle ich klar und anwendungsorientiert. Mein Fokus liegt auf echtem Verständnis statt bloßer Theorie. Wer sich weiterentwickeln will – fachlich oder methodisch – findet in mir einen strukturierten, ehrlichen und engagierten Sparringspartner.

Schulungen

Ich biete praxisnahe Schulungen für erfahrene Entwickler:innen, z. B. zu Clean Code, Secure Coding oder Architekturprinzipien im Alltag. Statt reiner Theorie geht es um konkrete Ansätze, die im echten Projektkontext funktionieren., mit vielen Beispielen, Raum für Fragen und direktem Praxisbezug.

Pairprogramming

Ich arbeite als Pair-Programming-Partner in kritischen Situationen, wenn es hakt, wenn Unsicherheit herrscht oder wenn es auf technische Qualität ankommt. Ob zur Einarbeitung, beim Refactoring oder zur Lösung komplexer Probleme: Ich bringe Ruhe, Struktur und Erfahrung direkt in den Code.

Technisches Sparring

Ich bin Sparringspartner für Entwickler:innen, die wachsen wollen, fachlich, methodisch oder in ihrer Rolle. Gemeinsam analysieren wir Code, diskutieren Architekturideen oder reflektieren Entscheidungen, auf Augenhöhe, ohne Druck, mit Tiefgang.

Hands on

Systemanalyse

Ich analysiere Ihre Systeme, wenn sie nicht rund laufen. Ich lese Logs, grabe mich in Stacktraces ein und finde die Ursachen, nicht nur die Symptome. Technische Störungen, unerklärliche Effekte oder Performance-Probleme? Genau mein Ding.

Legacy verstehen

Ich arbeite mich auch in gewachsene Systeme ohne Doku ein, Schritt für Schritt, mit Geduld und technischem Spürsinn. Ob uralter Code, selbstgeschriebene Tools oder halb vergessene Konfigurationen: Ich finde heraus, wie es funktioniert, und wie sich daraus eine sinnvolle Modernisierung ableiten lässt.

Einsatzbereit

Ich mache mir auch an laufenden Systemen die Finger schmutzig, dann, wenn es eben geht. Wenn Analysen nur am Wochenende möglich sind, weil unter der Woche produziert wird: kein Problem. Ich richte mich nach dem System und nicht umgekehrt.

Sicherheit ist Alltag

Ich bewege mich sicher in produktionsnahen und sensiblen Bereichen, ob im Labor, in der Halle oder im Rechenzentrum. Sicherheitsschuhe gehören für mich zum Standard, genauso wie Respekt vor Umgebung, Anlagen und Abläufen.

Softwareentwicklung ist für mich

...eine kreative Herausforderung.

...die perfekte Mischung aus Logik und Kreativität.

...wie ein riesiges Puzzle, das gelöst werden will.

...ein ständiger Lernprozess.

...eine Möglichkeit, Probleme effizient zu lösen.

...eine Kunst, die mit Struktur und Logik arbeitet.

...ein Feld, in dem ich mich kontinuierlich verbessern kann.

...eine Möglichkeit, komplexe Ideen greifbar zu machen.

...eine Leidenschaft, die mich antreibt.

...wie das Komponieren eines Musikstücks – mit Code statt Noten.

...eine Herausforderung, die nie langweilig wird.

...der Weg, um Maschinen intelligenter zu machen.

...eine ständige Suche nach der optimalen Lösung.

...ein Abenteuer, das nie endet.

...ein Werkzeug, um meine Ideen umzusetzen.

...eine Quelle endloser Möglichkeiten.

...die beste Art, meine analytischen Fähigkeiten zu nutzen.

...ein Beruf, der mich erfüllt.

...der perfekte Weg, um Technologie und Mathematik zu verbinden.

...eine Reise in die Welt der Algorithmen.

...ein Spielplatz für meine Neugier.

...ein Handwerk, das ständig weiterentwickelt werden muss.

...wie ein Schachspiel gegen Probleme.

...die Essenz moderner Innovation.

...ein Bereich, in dem ich meine Kreativität voll ausleben kann.

...ein Feld, in dem jede Lösung neue Fragen aufwirft.

...eine Methode, um Abläufe zu optimieren.

...eine Kunstform, die logisches Denken voraussetzt.

...eine Wissenschaft, die sich mit Struktur und Effizienz beschäftigt.

...der Weg zur Automatisierung von Prozessen.

...ein Puzzle, das ich immer wieder gerne zusammensetze.

...eine Disziplin, die sowohl Struktur als auch Chaos erfordert.

...eine ständige Balance zwischen Perfektionismus und Pragmatismus.

...der perfekte Ort für technologische Innovation.

...die Möglichkeit, aus kleinen Ideen große Lösungen zu bauen.

...eine Sprache, die Maschinen verstehen.

...der Schlüssel zur digitalen Welt.

...der Motor der modernen Gesellschaft.

...ein Feld, das technisches Wissen mit menschlichem Verständnis verbindet.

...eine ständige Herausforderung, die mich antreibt.

...eine Reise in die Zukunft.

...ein Experimentierfeld für neue Technologien.

...eine Gelegenheit, mein Wissen praktisch anzuwenden.

...die Kunst, Chaos in Struktur zu verwandeln.

...ein Handwerk, das genauso viel Erfahrung wie Talent erfordert.

...die Fähigkeit, aus Code echten Nutzen zu generieren.

...eine Möglichkeit, Effizienz in den Alltag zu bringen.

...die Magie, mit der Maschinen „denken“ können.

...eine Welt, die ständig im Wandel ist.

...eine meiner größten Leidenschaften.

Nicht alles, was zählt, passt in einen Lebenslauf.

In diesen Einblicken geht es um Erfahrungen, die mich geprägt haben. Situationen, an denen ich gewachsen bin. Und um das, was man über meine Arbeit nur versteht, wenn man die Geschichten dahinter kennt.
Von Vektoren zu Stichen: Programmieren für die Stickmaschine
Technik trifft Kreativität: Wie ich aus einer Vektor-Grafik eine eigene Stickdatei gebaut habe, mit Logik, Mathematik und Neugier.
Stickmaschine

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.

Die Nadel der Stick-Maschine Sourcecode des SVG2DST-Python-Scripts Stickdatei-Vorschau Das fertige Stick-Bild
Programmieren erklärt. Mit Beamten, Formularen und echten Fehlern
Wie erkläre ich meiner Oma, was Programmieren wirklich bedeutet? Eine Geschichte über Regeln, Prozesse und clevere Tricks.
Stickmaschine

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
Er hat eine etwas größere Aufgabe:
  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!

Oma Veronika
Legacy Code: Expedition in die Tiefen vergessener Software
Was als kleine Portierung begann, wurde zur archäologischen Reise durch alten Java-Code. Voller versteckter Schätze und harter Lektionen.
Pakete aus der Vergangenheit

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.

Pakete aus der Vergangenheit / EJB 2.1
Programmieren lernen: Abenteuer, Fehler, und jede Menge leuchtende Augen
Wenn aus wilder Kreativität echter Code wird: Wie Kinder beim Programmieren lernen, wachsen und warum Fehler dabei Gold wert sind.
Lagerfeuer im Camp

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.

Laptops im Camp Code im Camp Lagerfeuer Camp ist Gut

FAQ

Hier finden Sie Antworten auf typische Fragen zu meiner Arbeitsweise, Einstiegsmöglichkeiten, Technik und Zusammenarbeit.

Wie können wir starten?

Typische erste Einsätze

Mein Einstieg beginnt oft klein, mit einem konkreten Problem oder einer Frage, für die intern niemand Zeit, Erfahrung oder den passenden Blick hat. Oder einer Stelle, an der man seit Wochen nicht weiterkommt. Genau da komme ich ins Spiel.

Typische erste Einsätze sehen zum Beispiel so aus:

Ein mysteriöser Bug, den mal jemand sauber auseinandernehmen muss.

Ein Stück Legacy-Code, das dringend angepasst werden muss, aber niemand traut sich ran.

Ein Architektur-Review, weil sich die Komplexität langsam selbst im Weg steht.

Ein Konzept oder Prototyp, bei dem noch unklar ist, ob das überhaupt funktionieren kann.

Ein Entwicklerteam, das bei einem kniffligen Thema Input, Coaching oder Sparring braucht.

Wir starten ganz unkompliziert, zum Beispiel mit ein paar Tagen oder Wochen. Was sich daraus entwickelt, ergibt sich oft ganz natürlich: Wenn es passt, wenn Vertrauen entsteht, wenn man merkt, dass es funktioniert dann wird daraus meist eine langfristige Zusammenarbeit.

Ich bin keiner, der kurz reinspringt und dann verschwindet. Ich bleibe dran, denke mit, übernehme Verantwortung. Vom ersten Schritt an.

Sind Sie ein Consultant?

Kommt ganz darauf an, was Sie unter „Consultant“ verstehen

Wenn Sie unter einem Consultant jemanden verstehen, der analytisch denkt, Fachwissen und Erfahrung mitbringt, und Ihnen dabei hilft, echte Probleme nachhaltig zu lösen, dann ja, das bin ich.

Wenn Sie jemanden suchen, der mit etwas Distanz von außen auf Ihre Situation schaut, die richtigen Fragen stellt und Zusammenhänge klarer macht, als sie auf den ersten Blick erscheinen, ebenfalls ja.

Wenn Sie allerdings einen klassischen „PowerPoint-Consultant“ meinen, der ohne echtes Problemverständnis theoretisch gute Ideen formuliert, allgemeine Empfehlungen abgibt und dann schnell zum nächsten Projekt wechselt, dann nein. Das ist nicht mein Stil.

Ich begleite viele meiner Kunden über Jahre hinweg, manchmal kontinuierlich, manchmal mit Unterbrechungen und späteren Wiedereinsätzen. Ich bleibe dran, bis ich selbst überzeugt bin, dass die Lösung funktioniert. Und ich komme auch nach längerer Zeit gern wieder zurück, wenn neue Herausforderungen entstehen.

Was sich daraus ergibt, ist oft mehr als klassische Beratung: eine vertrauensvolle, langfristige Partnerschaft, auf Augenhöhe und mit gemeinsamem Blick aufs Ganze.

Freelancer gehen, wenn es kompliziert wird.

Ich komme, wenn es kompliziert wird.

Komplexe Probleme, gewachsene Systeme, unübersichtliche Codebasen oder unerklärliche Probleme, genau da fängt meine Arbeit erst an. Ich mag die Situationen, in denen andere aussteigen. Weil ich weiß, dass dort oft der größte Hebel für echte Verbesserung liegt.

Während andere „wegrefaktorisieren“ wollen, versuche ich zu verstehen: Warum ist es so geworden, wie es ist? Welche Abhängigkeiten, welche Zwänge, welche Geschichte steckt dahinter? Und wie können wir daraus eine tragfähige Zukunft bauen?

Ich gehe nicht, wenn es unübersichtlich wird. Ich bleibe. Und ich bringe Struktur mit. Klarheit. Und Geduld. Denn genau das braucht es, wenn man aus Komplexität wieder Handlungsfähigkeit machen will.

Oder kurz gesagt: Ich komme, wenn andere sagen: „Das wird nichts mehr.“

In welchen Branchen haben Sie Erfahrung?

Erfahrung aus vielen Welten

Ich habe in den letzten Jahren Projekte in ganz unterschiedlichen Branchen begleitet, vom Mittelstand bis zum internationalen Konzern, vom regulierten Umfeld bis zum Startup-Tempo. Dazu gehören unter anderem:

  • Anwaltskanzleien und das juristische Umfeld
  • Finanzumfeld und Versicherungen
  • Logistik – sowohl Konzern als auch mittelständische Unternehmen
  • Öffentlicher Dienst
  • Pharmaindustrie (national und international)
  • Spezialisierter Einzelhandel
  • Telekommunikation

Viele technische Herausforderungen ähneln sich branchenübergreifend, aber jedes Umfeld hat eigene Besonderheiten. Genau diese Kombination aus Erfahrung und frischem Blick bringe ich mit.

Wir wollen unsere Stelle langfristig besetzen

Langfristigkeit ist genau mein Stil

Ich verstehe den Wunsch nach Stabilität, und genau dafür stehe ich. Viele meiner Kunden arbeite ich über viele Jahre hinweg. Fünf bis acht Jahre Zusammenarbeit sind für mich keine Ausnahme, sondern eher die Regel.

Manchmal begleite ich Projekte über längere Zeiträume hinweg kontinuierlich, manchmal mit Phasen dazwischen, in denen kein akuter Bedarf besteht. Und wenn später wieder neue Herausforderungen entstehen, bin ich oft wieder an Bord, mit dem nötigen Kontext und dem gewachsenen Vertrauen.

Ich sehe mich nicht als "Projekt-Hopper", sondern als langfristigen Partner, der bleibt, wenn es komplex wird – und wiederkommt, wenn er gebraucht wird.

Wie lange dauern deine Projekteinsätze üblicherweise?

So lange wie sinnvoll – und so flexibel wie nötig.

Ich begleite immer mindestens ein langfristiges Projekt, das sich über mehrere Jahre erstreckt, oft über viele Phasen hinweg. Parallel dazu übernehme ich regelmäßig kürzere Einsätze: für Analysen, Reviews, technische Unterstützung oder schnelle Problemlösungen.

Ob unsere Zusammenarbeit eher kurz oder lang wird, steht zu Beginn selten fest, und das ist auch völlig in Ordnung. Ich bin offen für beides: Ich springe ein, wenn’s schnell gehen muss, und bleibe, wenn sich eine langfristige Partnerschaft ergibt.

Von meiner Seite gibt es keine Mindestvertragslaufzeiten, kein Stundenkontingent, das zwingend abgenommen werden muss. Wir gestalten das gemeinsam, flexibel, praxisnah und so, wie es für Ihre Situation am besten passt.

Können Sie sich in bestehende Teams integrieren?

Ja – in jeder Form, die Sinn ergibt.

Ich bin es gewohnt, mich schnell und unkompliziert in bestehende Teams einzufügen, ob remote oder vor Ort, ob als temporäre Verstärkung, technischer Sparringspartner oder aktives Mitglied mit längerem Atem.

Ich arbeite gerne mit internen Projekt-Teams zusammen, fachlich, menschlich und auf Augenhöhe. Externe und interne Kolleg:innen unterscheide ich nicht nach Vertragsart, sondern nach Engagement und Zielorientierung. Wir ziehen am selben Strang.

Ob als technischer Experte für spezielle Anforderungen, als Pair-Programming-Partner oder sogar als externer Teamleiter eines internen Entwicklerteams, all das habe ich bereits erfolgreich und über Jahre hinweg praktiziert.

Ich höre zu, bevor ich rede. Ich respektiere gewachsene Strukturen, bringe aber auch neue Perspektiven mit. Integration ist für mich keine Hürde, sondern eine meiner Stärken.

Wir haben nichts, das man extern abgeben kann.

Dann machen wir es gemeinsam möglich.

Das höre ich oft und verstehe es gut. In gewachsenen Strukturen ist vieles miteinander verwoben, und es scheint unmöglich, eine klar abgegrenzte Aufgabe nach außen zu geben.

Aber gerade in solchen Situationen kann externe Unterstützung besonders wertvoll sein: Ich bringe nicht nur technisches Know-how mit, sondern auch Erfahrung im **Einarbeiten in komplexe Umgebungen**. Ich finde gemeinsam mit Ihnen eine sinnvolle Schnittstelle, an der ich helfen kann, ohne dass Sie dafür erst alles entflechten müssen.

Ob als Sparringspartner für technische Entscheidungen, als jemand, der sich Stück für Stück einarbeitet, oder als verlängerter Arm Ihres Teams: Es geht nicht darum, eine künstliche Grenze zu ziehen, sondern darum, pragmatisch und effektiv zusammenzuarbeiten.

Ist unser Firmen-Knowhow bei dir sicher?

Mindestens so sicher wie bei Festangestellten

Ihr Firmen-Knowhow ist bei mir in sicheren Händen. Vertraulichkeit ist für mich selbstverständlich, nicht nur aus Professionalität, sondern auch aus Überzeugung.

Ich unterzeichne auf Wunsch gerne eine NDA (Geheimhaltungsvereinbarung), die auch über das Projektende hinaus Verschwiegenheit garantiert. Solche Vereinbarungen sind gängige Praxis und gehören für mich zum Standard in der Zusammenarbeit mit Unternehmen.

Ob intern oder extern: Der verantwortungsvolle Umgang mit sensiblen Informationen ist eine Frage der Haltung, nicht der Vertragsform.

Warum sind Sie verfügbar?

Ich suche genau einen neuen Kunden

Eine meiner langjährigen Partnerschaften läuft weiterhin, aber der akute Bedarf ist dort zurückgegangen. Das Projekt ist in einer ruhigen Phase, in der nur noch gelegentlich punktuelle Unterstützung nötig ist.

Deshalb habe ich wieder Kapazität für eine neue Aufgabe, idealerweise etwas Langfristiges, bei dem ich mein technisches Know-how, meine Erfahrung und meinen Blick für nachhaltige Lösungen einbringen kann.

Ich arbeite nicht projektweise im klassischen Sinn, sondern als Partner, der sich einarbeitet, mitdenkt und bleibt, wenn’s kompliziert wird. Wenn Sie genau das suchen, dann sollten wir ins Gespräch kommen.

Sind sie an einer Festanstellung interessiert?

Nein – aus Überzeugung und Verantwortung.

Ich stehe nicht für eine Festanstellung zur Verfügung. Der Grund ist einfach: Ich habe langjährige Bestandskunden, denen ich zugesagt habe, auch künftig verfügbar zu bleiben; zuverlässig, flexibel und genau dann, wenn es darauf ankommt.

Außerdem ist mir wichtig, Zeit für ehrenamtliches Engagement einzuplanen, hauptsächlich in der Nachwuchsförderung und technischen Bildungsarbeit. Beides lässt sich mit einer Festanstellung nicht gut vereinbaren. Beides ist mir wichtig.

Wenn Sie jedoch jemanden suchen, der Verantwortung übernimmt, sich tief einarbeitet und langfristig verfügbar bleibt - nur eben nicht im Angestelltenverhältnis –, dann sollten wir sprechen.

Warum haben Sie eine Webseite in plain-html?

Weil das für diesen Zweck genau das richtige ist!

Sie ist einfach zu pflegen, noch einfacher zu betreiben, bietet keine unnötige Angriffsfläche für IT-Sec-Problematiken und erfüllt genau ihren Zweck.
Warum hat ihre Webseite kein Cookie-Banner?

Kein Cookie – kein Banner!

Diese Webseite speichert keine Cookies.

Haben Sie die Webseite mit ChatGPT gemacht?

Ja – aber nicht nur.

Ich habe die Webseite komplett selbst entwickelt, in HTML, CSS und ein bisschen JavaScript, ganz bewusst ohne Baukasten oder CMS. Das passt besser zu meinem Stil: schlank, wartbar, ohne unnötige Abhängigkeiten.

Aber ja, ich habe an einigen Stellen ChatGPT zur Unterstützung genutzt, zum Beispiel für Textformulierungen, um Ideen zu schärfen oder für kleine Impulse bei der Struktur. Nicht, weil ich’s nicht selbst könnte, sondern weil man mit dem richtigen Werkzeug schneller ans Ziel kommt.

Ich sehe KI-Tools wie ChatGPT genauso wie jeden guten Editor, Compiler oder Debugger: Sie nehmen einem nicht das Denken ab, aber sie machen das Arbeiten effizienter.

Machen Sie auch Architekturentscheidungen mit?

Unbedingt – nachdem ich den Kontext verstanden habe

Softwarearchitektur ist einer meiner Schwerpunkte. Ich helfe gerne dabei, tragfähige Entscheidungen zu treffen, fundiert, nachvollziehbar und zukunftssicher. Dabei geht es nicht nur um Technik, sondern auch um Abwägungen, Teamfähigkeit und Wartbarkeit.

Ich treffe keine Architekturentscheidungen „aus dem Bauch heraus“. Ich höre zu, stelle Fragen und entwickle Lösungen, die zu Ihrem System und Ihrem Team passen. Und ich übernehme Verantwortung, auch für Entscheidungen, die langfristig tragen müssen.

Mit welchen Technologien arbeiten Sie?

Java, Python, Datenbanken – und alles, was zur Lösung passt

Mein technischer Schwerpunkt liegt bei Java, Python und relationalen Datenbanken. In diesen Bereichen habe ich viele Jahre Praxiserfahrung gesammelt, in unterschiedlichsten Projekten, Branchen und Systemlandschaften.

Darüber hinaus habe ich im Lauf der Zeit mit einer Vielzahl weiterer Technologien gearbeitet: C++, moderne Web-Stacks, Datenbank-Systeme, Embedded-Plattformen, Machine Learning Frameworks, um nur einige zu nennen.

Ich bin dabei kein "Java-Entwickler" oder "Python-Spezialist" im engen Sinne. Ich bin vor allem: Problemlöser. Für mich steht nicht das Tool im Vordergrund, sondern die Aufgabe, die gelöst werden soll. Die passende Technologie ergibt sich daraus, und nicht umgekehrt.

Die Liste der Technologien, mit denen ich bereits gearbeitet habe, ist lang. Aber die eigentliche Stärke liegt nicht im Sammeln von Tool-Namen, sondern im Verständnis der Prinzipien dahinter. Oder anders gesagt: Ich habe das Wasser verstanden, mit dem sie alle kochen. Manche kochen etwas heißer, manche etwas umständlicher, aber am Ende geht es um dieselben Grundideen.

Und genau deshalb kann ich mich schnell und sicher in neue Technologien einarbeiten. Wenn Sie also ein Problem in einem Stack haben, den „eigentlich niemand kennt“, lassen Sie uns reden. Danach haben Sie ein Problem weniger, und ich eine Erfahrung mehr.

Wie ist Ihr Standardvorgehen?

Verstehen, was wirklich los ist – und dann lösungsorientiert handeln

Mein Einstieg beginnt fast immer mit Zuhören: Wo drückt der Schuh? Was funktioniert nicht, oder nicht mehr? Und was soll eigentlich anders werden?

Ich verschaffe mir einen Überblick über den Ist-Zustand. Dann schaue ich genauer hin: Ist der spürbare Schmerz wirklich das Problem, oder nur ein Symptom? Ich suche nach den Ursachen hinter den Effekten, nicht nur nach Pflastern für akute Wunden.

Ich schreibe dabei keine seitenlangen Ist-Analyse-Dokumente, aber ich muss sicher sein, dass wir das eigentliche Problem erkannt haben, bevor wir an die Lösung gehen. Nur dann lohnt sich der nächste Schritt.

Wenn wir das geklärt haben, definieren wir gemeinsam Ziele: Was wollen wir erreichen? Was wäre besser als heute? Und wie kommen wir dorthin, Schritt für Schritt, klar und nachvollziehbar?

Ich bin kein Fan von Aktionismus. Aber wenn der Weg klar ist, gehe ich ihn entschlossen mit. Immer praxisnah, mit technischem Tiefgang, und ohne den Blick fürs Ganze zu verlieren.

Kann ich Sie auch „nur“ für ein Review buchen?

Sehr gern – das ist oft ein guter Einstieg.

Ein Review ist ein sinnvoller, klar begrenzter erster Schritt. Ob Code-Review, Architektur-Check oder Analyse eines kniffligen Bereichs: Ich bringe eine neutrale Sicht von außen, technisches Tiefenverständnis und ehrliches Feedback mit.

Manche Kunden starten so, und aus einem einmaligen Review wird dann eine langfristige Zusammenarbeit. Muss aber nicht. Auch einmalige Analysen sind völlig okay.

Warum spezialisieren Sie sich auf Legacy-Code?

Weil dort oft der größte Wert liegt.

Ich weiß, dass es viele Entwickler:innen gibt, denen es bei Legacy-Code kalt den Rücken runterläuft. Für mich ist es genau andersherum. Ich mache das gern, und zwar aus mehreren Gründen:

1. Die technische Herausforderung

Ich mag es, mich in gewachsene Systeme einzuarbeiten. Strukturen zu verstehen, Gedanken nachzuvollziehen, Probleme von früher zu rekonstruieren, das ist wie technisches Storytelling. Legacy-Code liest sich wie ein Tagebuch alter Entscheidungen, und ich liebe es, zwischen den Zeilen zu lesen.

2. Nachhaltigkeit statt Wegwerfen

Vieles wird heute zu schnell ersetzt. Oft ist die neue Lösung nicht wirklich besser, manchmal sogar schlechter. Ich glaube, dass Systeme, die sich bewährt haben, es verdienen, erhalten und weiterentwickelt zu werden. Wer immer nur neu baut, wirft viel Gutes weg.

3. Wertschätzung für das, was war

Legacy-Code ist kein Müll. Er ist ein Zeitdokument. Oft steckt darin die Arbeit vieler kluger Köpfe. Ich gehe mit Respekt an solche Systeme heran, und mit dem Anspruch, sie nicht nur am Leben zu halten, sondern sinnvoll weiterzubringen.

Fazit: Ich bin gern dort, wo es knarzt, nicht aus Nostalgie, sondern weil ich genau da den größten Hebel für Stabilität, Verständnis und echten Fortschritt sehe.

Wie dokumentieren Sie Ihre Arbeit?

So viel wie nötig, so klar wie möglich.

Ich dokumentiere so, dass andere verstehen, was ich gemacht habe, auch Monate später. Das kann technische Dokumentation im Code sein, Architekturentscheidungen als ADRs, oder einfache Notizen im Wiki.

Ich richte mich dabei nach Ihren Standards, oder helfe, sinnvolle Strukturen einzuführen, falls es noch keine gibt. Mein Ziel: Die Dokumentation hilft dem Team, und wird nicht bloß fürs Protokoll geschrieben.

Arbeiten Sie auch vor Ort oder nur remote?

Beides ist möglich – je nach Bedarf.

Ich arbeite überwiegend remote, weil es effizient, flexibel und oft einfach praktikabler ist. Aber wenn es sinnvoll ist, komme ich auch gern vor Ort: für einen Projektstart, Workshops, ein Architektur-Review oder wenn das Team physische Nähe braucht.

Vor Ort bin ich am einfachsten im Raum Köln/Bonn einsetzbar, da bin ich schnell, flexibel und ohne großen Aufwand verfügbar.

Mir ist wichtig, was für das Projekt am besten funktioniert und nicht, was für mich am bequemsten ist.

Was genau verkaufen Sie hier?

Meine Zeit und Erfahrung

Ich biete ausschließlich meine eigene Arbeitskraft und Expertise an. Ich gebe keine Arbeit an Mitarbeiter oder Subunternehmer weiter.

Ich bin Recruiter, darf ich mich trotzdem melden?

Klar – wenn's passt, reden wir gern.

Ich weiß gute Vermittlungsarbeit zu schätzen – besonders dann, wenn sie auf Augenhöhe passiert, mit echtem Interesse am Projekt und einem klaren Bild davon, was gebraucht wird.

Wenn Sie ein konkretes Projekt vermitteln, das zu meinem Profil passt: sehr gerne melden. Ich arbeite bevorzugt direkt mit Kunden zusammen, aber ich bin offen für Gespräche, wenn Sie ein seriöses, langfristig angelegtes Vorhaben betreuen.

Was für mich nicht infrage kommt: Massenaussendungen, unpassende Vorschläge oder Angebote für Festanstellungen. Das spart uns beiden Zeit.

Wenn Sie aber den Eindruck haben, dass ich genau der Richtige für Ihr Projekt bin, dann freue ich mich auf eine Nachricht.

Darf ich Ihren CV für unsere Datenbank haben?

Wenn Sie das nicht nur tun, um "möglichst viele" Freelancer in der DB zu haben.

Melden Sie sich gerne über das Kontaktformular. Ich melde mich zeitnah zurück, schicke den CV zu und fülle bei Bedarf auch Ihr DSGVO-Formular aus.

Sie haben dabei die Wahl:

  • Human-readable – lesbar, mit Persönlichkeit und nicht länger als drei Seiten.
  • KI-parsbar – strukturiert, sachlich, vollumfänglich, optimiert für Ihre Datenbank.

Sagen Sie einfach kurz dazu, was Sie brauchen. Ich liefere in der Form, die Ihnen weiterhilft.

Warum ist auf ihrer Webseite alles gelb?

Weil Grau genug andere machen.

Gelb ist meine Lieblingsfarbe. Genauer gesagt: Mango. Oder Sonnenblumengelb. Oder irgendwas dazwischen, Hauptsache, warm, freundlich und mit ein bisschen Strahlen.

Ich mag Farben, die gute Laune machen. Die leuchten, ohne zu schreien. Und die ein bisschen so wirken, wie ich arbeite: klar, lebendig, und nicht ganz Standard.

Und mal ehrlich: wer braucht schon noch eine Entwicklerseite in Blau-Grau mit Stockfotos von Serverracks?

Kontakt

Igor Arenz telefoniert

Schreiben Sie mir eine Nachricht, ich melde mich bei Ihnen.





Mit dem Absenden stimmen Sie der Verarbeitung Ihrer Angaben zur Bearbeitung Ihrer Anfrage zu.

LinkedIn

Auch auf LinkedIn bin ich erreichbar, für den ersten Kontakt, ein fachliches Gespräch oder einfach, um in Verbindung zu bleiben. Wenn Sie sehen möchten, woran ich aktuell arbeite oder was mich fachlich umtreibt, schauen Sie gern vorbei.

Mein LinkedIn-Profil

Telefonisch erreichbar, wenn ich gerade keinen Bug verfolge

📞 02236 - 480 40 40

Versuchen Sie es gern – ich bemühe mich wirklich, erreichbar zu sein. Aber manchmal führt die Fehlersuche tief ins System... und dann klingelt das Telefon länger als mir lieb ist.

Der Anrufbeantworter springt zuverlässig ein, und mein Rückruf ist Ihnen sicher.

Versprochen.