Biografie

Als Kind hatte ich viel Freude daran die Großeinkäufe unserer Familie im Keller in die Vorratsregale einzuräumen. Eine wiederholbare Struktur habe ich dabei jedoch nicht entdeckt. Optimal war jedes Mal anders. Mit 12 Jahren malte ich ganze Nachmittage Baum-Strukturen auf Reste von Tapetenbahnen, um die Lösung für Aufgaben aus einem Buch über kreatives mathematisches Denken erschließen zu können.

Elektronik

Mit dem geschenkten Elektronik-Baukasten ließen sich aus Ohmschen Widerständen, Elektrolytkondensatoren, Dioden und Spulen interessante Anwendungen bis hin zu einem einfachen aber funktionierenden Mittelwellenempfänger (Radio) zusammenstecken. Leider bedurften die Aufbauten eine sorgfältige Arbeitsweise und ließen sich ohne Schaltplan nie nachbauen.

Bei einem Praktikum in der Entwicklungsabteilung eines Herstellers für Fleischerei- und Verpackungsmaschinen bekam ich Einblick in die Planung und Herstellung von Schaltkreisen auf Basis von Mikroelektronik. Ich half bei der Fertigung: Beim Belichten der Schaltkreise auf der Platine mit einem Fotokopierer, dem anschließenden Ätzen der Leiterbahnen in einem Säurebad und beim Auflöten der Bauteile, liebevoll Käfer genannt. Die fertigen Platinen wurden zur Steuerung in die eigenen Maschinen eingebaut, die sich sogar bis nach Japan verkauften.

Die Arbeit war für einen 14-Jährigen ziemlich mühselig und erforderte viel Aufmerksamkeit. Gelegentlich tauchte auch ein Programmierer in den Räumen der Abteilung auf und schrieb an Programmtexten, wofür auch immer.

Home Computer

Mein erstes, eigenständige Computer-Programm schrieb ich kurze Zeit später auf einem ausgedienten Home Computer meines Bruder anhand des beiliegenden Handbuches in Basic. Dazu genügten mir die Tipps aus dem gerade begonnen Informatik Unterricht in der Schule.

Der CPC 6128 verfügte über eine 8 Bit Prozessor-Architektur, war mit großzügigen 128 kB Hauptspeicher und einem flinken 3,5 Zoll Diskettenlaufwerk ausgestattet. Nach ungefähr 2 Stunden hatte ich eine Simulation auf Basis einer Turtle-Grafik programmiert, die die Olympischen Ringe in unterschiedlichen Grüntönen zentriert auf den Bildschirm malte. Ein Kommandozeilenparameter des Programms variierte die Animationsdauer.

Personal Computer

Während meines Zivildienst war ich gerne bereit die Verwaltung des Vorrats- und Getränkekeller zu übernehmen. Das Café gehörte zu einem Bildungs- und Sozialzentrum in Trägerschaft eines Vereines mit Förderung des Landes.

Meinen ersten Design- und Programmierjob erhielt ich als der Preis des Mittagstisches neu kalkuliert werden musste. Bisher erfolgte dies über eine Schätzung, die auf Papier erfasst und überschlagen wurde. Ich dagegen modulierte das Lager unter dem dateibasierten Datenbankmanagementsystem dBase, das auf einem alternden 286er PC im Hinterzimmer der Verwaltung installiert war, und berechnete nach einem eigenen mathematischen Modell den Preis aus dem Warendurchsatz pro Monat. Mein vorgeschlagenes Näherungsmodell wurde hitzig Glied für Glied diskutiert und schließlich verworfen. Nach knapp einem Jahr verabschiedete ich mich Anfang der 90er aus der hessischen Provinz in Richtung Berlin.

Unix

Während meines Studium der Physik vertiefte ich meine Computer-Kenntnisse und erweiterte meine Programmierfähigkeiten im Nebenfach Informatik als Teil des Grundstudium und in der zweiteiligen Vorlesung Computation and Physics als Teil des Hauptstudiums. Die Vorlesung bot einfach schöne Programmier-Aufgaben zur Berechnung physikalischer Modelle. Alle kamen und gingen mit einem Lächeln zu den Vorlesungen. Die Lösungen der Aufgaben programmierten wir zunächst in C, bis wir feststellten, dass sich die Datenstrukturen der Verwendeten Modelle in der interaktiven Eingabe von Mathematica viel einfacher erstellen und berechnen ließen. Im Rahmen der Vorlesung hielt ich mit zwei Kommilitonen einen Vortrag über die Berechnung der Hystereseschleife eines ferromagnetischen Clusters mithilfe von Monte Carlo Algorithmen.

Der Fachbereich Physik verfügte über ein heterogenes Netzwerk aus vorwiegend Dec Alpha Workstations unter UNIX. Im Computerraum mit ca. 15 Arbeitsplätzen traf man sich, um die Programmieraufgaben zu implementieren. Zu Hause experimentierten einige Kommilitonen bereits mit Linux, nachdem sich 1993 rumgesprochen hatte, dass es UNIX jetzt auch für den PC gibt. Die Arbeit mit Computern war zeitraubend brachte aber auch Früchte ein.

Auf einer geophysikalischen Exkursion in den Bayerischen Wald an die Grenze zwischen Moldanubikum und Teplabarrandium massen wir in der stark graphitisierten Störzone am Berg Hängend zahlreiche Profile mit Eigenpotential-Messungen aus. Die anschließenden Semesterferien verbrachte ich mit meinem Partner vollständig im Computersaal der Geophysik, um die Messpunkte in eine digitale Karte unter dem ständig crashenden Mathcad für Profis zu übertragen und die Messreihen mittels Dipolmodell als Geobatterien im Untergrund zu modulieren. Immerhin die Resultate der Exkursion wurden in einer Fachzeitschrift veröffentlicht und damit wissenschaftlich gewürdigt.

Linux

Auch für die Verarbeitung der Messdaten meiner Diplom-Arbeit zu einem Thema aus der Oberflächen-Physik erwies sich C als eher ungeeignet. Mit der gerade aufkommenden, dynamisch getypten Script-Sprache Perl 5 ließen sich dagegen die Messdaten im Handumdrehen extrahieren, zusammenfassen und normieren. Den Rest der Nachmittage füllten Fit-Analysen der gemessenen Photo-Emissions-Spektren In situ Präparierter Metallfilme.

Den Text der Abschlussarbeit schrieb ich zu Hause auf einem Pentium II PC unter Debian in dem LaTeX Wyswig-Editor LyX. Die beteiligten Dateinen synchronisierte ich mit FTP zwischen dem Uni-Netzwerk und zu Hause. Den Netzzugang ermöglichte ein 56k-Modem.

Nach Abgabe meiner Diplomarbeit mit dem Titel Physikalische und Chemische Eigenschaften stickstoff- und sauerstoffbedeckter Lanthanid-Metalloberflächen und dem erfolgreichem Abschluss meiner Diplomprüfungen im Sommer 2000 experimentierte ich eifrig in meiner Bude mit verschiedenen Linux-Distributionen und Hinweisen aus dem Linux-Magazin, bis ich eines Tages auf Linux from Scratch stieß. Es kostet mich einen ganzen Winter ein eigenes Linux zu bauen bis es eines Tages bootete um anschließend sofort wieder vergessen zu werden.

Big Ball of Mud

Mit meiner Perl-Erfahrung und Linux-Kenntnissen fand ich zu Zeiten der Dotcom-Blase zu Beginn der Nuller-Jahre schnell einen Job gerade noch rechtzeitig bevor meine letzten Ersparnisse aus Studententagen aufgebraucht waren. Zusätzliche Kenntnisse der Perl-Module CGI und DBI qualifizierten mich für eine Anstellung als Softwareentwickler in einem Startup.

Das Projekt, für das ich ab 2001 arbeitete, betrieb die Weiterentwicklung eines proprietären, australischen, webbasierten Learning Managment System. Der Hauptkunde, ein weiteres Startup aus dem gleichen Konzerngeflecht, war eine Internet Akademie mit eigener, studienbegleitender Buchreihe, Online-Tutoren und einem bundesweiten Angebot von Präsenzprüfungscentern. Der angestrebte Zahl von 30.000 aktiven Studenten wurde nie erreicht. Das Learning Management System wurde nur an einen weiteren Kunden verkauft.

Die Software unterstützte eine Vielzahl Relationaler Datenbanksysteme, genutzt wurde aber nur Oracle 8. Die Programmtexte umfassten bis zu 4500 Zeilen Perl-Code im prozedural Stil und mischten Anwendungslogik, dynamische SQL-Befehle, HTML, CSS mit Javascript zu schwer zu wartenden Code-Klumpen. Der Downspin dieses mustergültigen Big Ball of Mud betraf nicht nur die Maintainability, Testability und Extensibility sondern versteifte im Laufe der Zeit alle Bereiche der Akademie und trug damit zum Scheitern des 20 Millionen Euro Projektes bei.

Da das Management die Neuimplementierung der Software nicht wünschte, schrieb ich Erweiterungen, wie einen TCP/IP basierten Chat-Server, setzte Schnittstellen um, implementierte Teile erneut, managte und deployte Releases. Zudem agierte ich nach Einführung eines nach ISO 9001 zertifizierten Qualitätsmanagementsystem als KVP-Manager. Als das Projekte endete, wurde ich aber nicht entlassen sondern in die Planung des Folgeprojekts eingebunden, das durch einen Management Buy Out zu stande kam.

Layered Architecture

Für das Folgeprojekt, einen mit der Akademie zuvor verschmolzenen und nun wieder eigenständigen Verlag, habe ich ab 2005 meine ersten beiden eigen Software-Systeme entwickelt. Dazu migrierte ich zunächst Teile des einstmals australischen Learning Managment Systems nach PostgreSQL.

Drumherum baute ich eine modulare, monolithische Web-Anwendung mit PHP, um die Lerninhalte der Akademie und die neuen Titel des Verlages werbefinanziert als Lern-Kurse ins Internet zu bringen und die inhaltsgleichen Medien Buch, Epub, Lernprogramm (CBT) und SCORM Package zu bewerben und über das Shop-Modul zu verkaufen.

Die meisten Webseiten wurden aus Performance Gründen auf dem Webserver als statische HTML-Seiten mit Javascript- und PHP-Einschlüssen vorerstellt. Um die Persistierung von Daten zu beschleunigen adaptierte das System das Active Record Pattern, das auch das zeitgleich hypende Webframework Ruby on Rails verwendete.

Pipeline Architecture

Um die werbefinanzierten Webseiten unter HTML, Druckvorlagen unter PDF, Lernprogramme als interaktive HTML-Anwendung mit Javascript auf CD, dwonloadbare ePubs und Lernmodule für SCORM-fähige Lernplattformen zu erzeugen, schuf ich ein Build-System, das automatisch Single Source Publishing über den von den Autoren bereitgestellten Medien betrieb.

Die Buchtexte, Multiple-Choice-Fragen und Text-Aufgaben wurden in Docbook XML-Dokumenten aufgezeichnet. Graphiken und Bilder als PNG oder JPEG, Videos im einem Flash-Format. Die Produkt-Angaben inklusive der Preise, die auf der Webseite, in Einbänden, Meldungen an den Börsenverein des Deutschen Buchhandels oder Barsortimenter verwendet wurden speicherte eine eigene XML-Datei, deren Grammtik unter RelaxNG gehalten war.

Als autorenseitige Schnittstelle diente eine Instanz des Revisionskontrollsystem Subversion. Das System suchte alle 5 Minuten per GNU Make nach Änderungen, um die Verlagsprodukte erneut zu erstellen. XML-Dokumente wurden mittels XSLT nach HTML oder XSL:FO umgeformt. XSL:FO nach PDF. Bilder wurden skaliert. Die Ausgabe erfolgte über ein Build Verzeichnis, das auch die Fehlermeldungen in einer Log-Datei speicherte. Die Distribution der erzeugten Produkte und Meldungen erfolgte skriptbasiert. Die SCORM-Pakete wollten händisch mit einer veralteten Testsuite verifiziert werden.

Prozedurale Hölle

Nach ca. 4 Jahren war die Arbeit an dem Verlagssystem im großen und ganzen abgeschlossen, es stellten sich mir aber Fragen bezüglich Software-Design, -Architektur und Programmiertechnik, die ich bei meiner täglichen Arbeit nicht beantworten konnte. Nach meinem Projektaustritt begann eine Phase der Neuorientierung. Klar war: Tägliche Routinen führen in einen starren Fluss, der es nicht ermöglichte sich im gewünschten Maße weiterzuentwickeln.

Die Arbeit in einem Großraumbüro eines Berliner Startups aus Match-Marketing-Branche bestätigte meine Eindrücke. Bezahlt wurde hier das Abarbeiten. Fragen wurden mit der Erteilung von Workitems beantwortet. Die Enge und Nähe zu 250 Kollegen verlangte eine erhöhte Anpassungsbereitschaft. Das Ringen um Souveränität war allen beteiligten anzumerken.

Mit meinen Kollegen programmierte ich Datenbank-Routinen in PL/pgSQL für die Frontend Entwickler des Projektes, sowie Algorithmen zum Matchen von Paaren. Es gab weder Softwaretests noch hilfreiche Tools zur Analyse des Datenbankschemas. Nach dem ich mit einem Kollegen eine Prozedur erweiterte, kam es zu einem Ausfall im Bezahldienst woraufhin ich ein Tool schrieb, um alle von einer Routine abhängenden Routinen in Baumform darzustellen. Aber das Team zeigte nur wenig Interesse an meiner Arbeit.

Open Source

Glücklicherweise verließ ich diesen Kontext wieder schnell und suchte meine Antworten als Schreiber und Autor von Open-Source-Software zu finden. Die ersten Schritte ging ich auf der Finca einer Freundin in Mallorca. Ich begann über meine Arbeit zu schreiben. Meine Texte überzeugten und ich fand schnell einen Verlag und wurde als Redner auf die deutsche PostgreSQL -Konferenz 2011 eingeladen.

Für das Linux-Magazin schrieb ich in den folgenden Jahren hauptsächlich über Javascript-Frameworks. Die Artikel waren eine sehr gute Schreibübung und ich bekam früh Einblicke in Angular, React, Nodejs, Typescript oder Webstandards wie WebRTC. Ein inhaltlicher, roter Faden meiner Tätigkeit bildete die Suche nach dem Tool zur Erstellung der universellen App.

Leider sind Artikel zu kurz um daraus einen tieferen Nutzen ziehen zu können, aber wenigstens beflügelt die Tätigkeit des Schreibens Geist und Sprachwitz. In dieser Phase begann ich auch nach Andalusien zu Reisen, um das Spielen der Flamenco-Gitarre in Andalusien im Süden Spaniens zu erlernen. Auf die Idee brachte mich mein erster Gitarren Lehrer Mitte der 80 Jahre. Jetzt wandelte ich meinerseits auf seinen Spuren zum Fuente (der Quelle) der Wahrheit und Klarheit, Olé.

Test Driven Development

Parallel zum Schreiben suchte ich nach meinen Antworten in eigenen Open-Source-Projekten unter PHP, Javascript oder Pyhton, was ich mir in der Zwischenzeit angeignet hatte. Diese Projekte lehrten mich Software aus dem Blickwinkel eines anderen Entwicklers zu sehen. Es lief darauf hinaus die versprochenen Features durch Software-Tests abzusichern, wie im Falle meines XML-Formatters. Die versprochenen Formatierungen hätten sich ohne Unit-Tests praktisch nicht garantieren lassen.

Ich hatte bereits bei meinen ersten Bemühungen unter Linux über das omnipräsente make test von Regressionstest erfahren und ihren Aufbau später an Perl-Modulen weiter studiert. Die Notwendigkeit der Regressions-Tests schien mir zunächst aber nur optional zu sein. Das änderte sich aber im Verlauf dieses Projektes. Anfänglich begnügte ich mich damit Unit-Tests der Programmierung nachzuführen. Als ich einige Unit-Tests erstellt hatte, fand ich es schnell sehr praktisch erst die Unit-Tests zu erweitern und dann den Code des Formatieres zu schreiben. Allerdings dauerte es noch einige Zeit und Bücher diesen Arbeitsstiel in meiner Projektarbeit zu aktivieren. Trotzdem hatte ich die erste Antwort gefunden: Ohne Einbeziehung von Tests erbringt die Software-Entwicklung keinen dauerhaften Wert.

Die Idee zu dem XML-Formatter ergab sich noch aus meiner Arbeit im Verlag. Buchtexte in Form von Word-Dokumenten, die wir mit Hilfe von Open-Office nach Docbook XML exportierten, um sie anschließend mit einem XSL-Formatter nach PDF umzuwandeln wiesen aufgrund vieler falsch gesetzter Leerzeichen einen gestörten Textfluss auf. Aus den folgenden, langwierigen Reparaturarbeiten an den Docbook XML Dokumenten ergaben sich die Formatierungsregeln für einen noch zu erstellenden Formatter.

Anti Patterns

Als frischgebackener Freiberufler begab ich mich auf die Suche nach Projekt-Aufgaben und lernte dabei zunächst mehr über das Scheitern als über das Gelingen - leider alles an vielversprechenden Projekten.

Das erste Projekt entwickelte eine webbasierte Software für Schweizer Stiftungen. Das Ziel war es unter hohem Druck schnell viele Kunden zu gewinnen und endlich wieder richtig Kohle zu verdienen. Schon dem ersten Kunden wurde alles mögliche versprochen und die Arbeiten uferten aus. Der CTO programmierte die Anwendung in 60-80 Stunden Wochen selber. In Ermangelung von Architektur und Design kamen Frameworks mit flachen Lernkurven zum Einsatz, die ständig angepasst werden mussten.

Die Software des zweiten Projektes existiert womöglich bis heute auf Papier, in Form eines UML-Diagramms. Die Projektleiterin verkündete: Das Programmieren fang ich mir nicht mehr an. Nachdem ich ein Datenbankschema zur Buchung für Tauchtouren gemäß der Vorgaben der Leiterin implementiert hatte und die Erstellung einer Webanwendung angehen wollte, war die Projektleiterin für mich nicht mehr erreichbar.

Das dritte Projekt wollte Patentstreitigkeiten in den USA dadurch vereinfachen, die beteiligten Dokumente zu digitalisieren, untereinander zu verlinken und unter den Parteien sowie dem Gericht zu teilen. Das Projekt wurde wöchentlich nach Ansicht des Entwicklungsstandes umgeplant. Die Erlangung der Marktreife war bei meinem Projektaustritt nicht absehbar.

Microkernel Architecture

Das System bestand aus einer monolithischen Anwendung mit Weboberfläche und zentraler Datenbank unter SQL-Server. Zum damaligen Zeitpunkt gab es noch keine Registry zur Einbindung von Plugins, wie mein Tool zum Im- und Export von Anwendungsdaten unter Python. Es basierte auf einem graphbasierten und plangetriebenen Datenmapper, der die Datensätze eines Patentstreites auf eine JSON-Grammatik abbildete, vice versa.

Als erstes lernte ich bei diesem Projekt: Relationale Datenbanken sind nur manchmal Bäume. Im allgemeinem sind sie Graphen und enthalten zudem Designfehler und Tabellen mit gebrochenen Normalformen. Neben all diesen Fehlern erfanden die Entwickler der Datenbank das Konzept des NULL-Wertes zum zweiten Mal.

Mein Konzept zur Planerstellung: Die gesuchten Daten bilden einen Teilbaum in der Datenbank. Der Teilbaum kann bei Angabe einer Kopftabelle über das Information Schema der Datenbank konstruiert werden.

Der Planner erhielt für seine Arbeit Direktiven aus einer Profil-Datei: Hier konnten fehlende Fremdschlüssel-Beziehungen ergänzt werden. Bisweilen musste der Baum um Tabellen außerhalb des Baumes erweitert werden. Dies ließ sich durch Umkehr von Fremdschlüssel-Beziehungen erreichen. Zyklische Referenzen wurden dagegen durch den Planner automatisch aufgelöst.

Service Based Architecture

Für ein Paar Jahre begleitete ich das Startup meiner Nachbarn im Stile eines Mentors. Sie entwickelten eine App auf Basis eines holistischen Programmes zur Verbesserung des Self Care. Ihr mühsam zusammengetragenes Kapital investierten sie in eine iOS-App um Investoren aus dem Silicon Valley zu gewinnen. Der Launch der App fiel leider in die Zeiten der Corona Pandemie, wo niemand daran dachte das Haus zu verlassen. Nach dem das Budget aufgebraucht war starteten sie ein Web3-Projekt im NFT-Markt, um Aufmerksamkeit und Spenden zu gewinnen.

Die Idee: Der Kunde kauft über einen Smart Contract in der Ethereum Blockchain ein ihm zunächst unbekanntes, computergeneriertes Kunstwerk (Bild) in Form eines Tokens. Sind die Token ausverkauft, werden alle Karten auf einen Schlag umgedreht und die Käufer sehen ihre Kunstwerke. Nun kann der Handel an den NFT-Marktplätzen beginnen. Den Weiterverkauf wickelt ebenfalls der Contract gegen eine Transaktionsgebühr ab.

Bei der Umsetzung half ich ihnen und implementierte eine Reihe Tools und Dienste für das Green Field Projekt in einer allen beteiligten unbekannten Domain. Im ganzen entstand eine verteilte Anwendung, die wir iterativ vervollständigten. Irgendwann verstand ich den Unterschied zwischen Pre und Public Sale. Durch Zufall entdeckte ich den Nutzen eines Provenance Hashs. Die Verwendung eines Merkle Trees zur Identifikation von Whitelist-Käufern hätte ich bei der Erstellung des Contracts in Solidity fast übersehen. Zu guter Letzt brauchte es noch einen Service, der es dem Besitzer des Token erlaubte ein hochauflösende, printfähige Version seines NFTs herunterzuladen.

Die verfügbaren Hardware-Kapazitäten reichten gerade aus, um die NFTs zum gewünschten Zeitpunkt zu generieren. Die Anspannung war riesig als der Smart Contract in die Blockchain deployt wurde. Minuten vergangen bis der Contract plötzlich tatsächlich unter Etherscan gelistet und ca. 260 $ für die Transaktion verbrannt waren. Wir waren drin, leider aber vergebens, da die unreife Minting-App fehlerhafte Transaktion auslöste und diese von den Käufern in der Transaktions-Historie des Contracts angezeigt wurden.

Domain Driven Design

Ungefähr zu selben Zeit fand ich ein weiteres, eher pragmatisches Projekt. Diese lernende Firma setzte nicht alles auf eine Karte, sondern verbessert sich selber iterativ. Positiv für mich: Anforderungen und Rahmenbedingungen ließen sich mitgestalten.

Dies ermöglichte mir auch einen längeren Studienaufenthalt im Süden Spaniens, um meine Fertigkeiten auf der Flamenco-Gitarre voranzubringen. Dabei verband ich Arbeiten und Lernen an einen anderen Ort in einer anderen Kultur. Die Erfahrungen und Überlegungen aus der geänderten Perspektive vertieften meine Einblicke in die gelingenden Aspekte der Software-Entwicklung: Architektur und Design und Programmiertechnik. Ein direkter Konsequenz war die Umformung des Backends nach Prinzipien des Domain Driven Design, um die wachsende Zahl von Diensten verständlich auszudrücken zu können.

In der Zeit unserer Zusammenarbeit begann die Firma zu wachsen und sich in ihrer Domain zu professionalisieren und durch Synergien und Methodiken voranzukommen.