Kategorien
computerarcheologie software engineering

Als die Blase platzte

Wir schreiben das Jahr 2002, der Autor dieser Zeilen ist bei der deutschen Vertriebsorganisation der Software AG (SAG) als Berater angestellt. Die SAG hatte viele Jahrzehnte bewährte Datenbank- und Anwendungsentwicklungs-Software (ADABAS und NATURAL) auf bewährten Großrechnern (IBM S/390) und Mini-Computern (VAX, BS2000, Unices) hergestellt und verkauft und es damit zum (nach SAP) zum zweitgrößten deutschen Software-Konzern geschafft.

Aber ach, die Zeichen der Zeit waren bunt und klickbar, Windows erorberte die Arbeitswelt, Großrechner waren out, Irgendwas-mit-Internet ein Muss. Die Gründer-Generation hatte das Zepter abgegeben, der neue Chef, Erwin Königs, steuerte einen entschiedenen Innovationskurs, legte mit Bolero und Tamino zwei Produkte in den beiden Kernmärkten des Unternehmens vor.

Tamino ist eine XML-Datenbank, und XML war damals um die Jahrtausendwende ein genauso heißer Sch***, wie es JSON, Docker, Kubernetes dann Jahre später auf ihren Gebieten sein würden. Über einen Achtungserfolg kam Tamino (Transaction Manager for Internet Objects, vermutlich ein Backronym) nicht hinaus. Zu schnell zogen die Branchengrößen IBM und Oracle XML-Extensions in ihre Flaggschiffe ein.

Bolero war (als Spezifikation) die Essenz aller Erkenntnisse, die Business-Programmierer im Laufe ihrer Karriere so gewinnen müssen: eingebaute Persistenz-Engine, null-safe, Code immer im Repository, Generatoren für die Integration mit Systemen wie SAP, super!

Die ganzen Goodies machten das Ding zur damals™ größten Java-Anwendung der Welt … was einem hätte zu denken geben können, denn damals war Java bei weitem nicht so schnell wie heute. Auch auf sehr gut ausgestatteten Laptops war der Arbeitsfluss eher ein Arbeitströpfeln, und durch den geführten Ansatz (für alles und jedes ein Fensterchen, ein Assistent, ein Dialog, nur den Code bekam man fast nicht zu Gesicht) fühlten die jungen, wilden Coder sich doch sehr gegängelt.

Beide Produkte, auf denen doch die Zukunft des Konzerns ruhen sollte, zündeten also im Markt nicht. Was zusammen mit dem Platzen der DotCom-Blase dazu führte, dass der Konzern in seine erste veritable Krise geriet und zum ersten Mal im größeren Umfang Stellen abbauen musste. Die Mitarbeiter, die gedacht hatten, es sich bei einem soliden Mittelständler gut eingerichtet zu haben, waren shell shocked. Schon der Börsengang der schon-immer-AG 1999 war ein Kulturschock, und nun das!

Um den Laden über Wasser zu halten, wurden die Vertriebsgesellschaften umgekrempelt. Der neue Manager für die konzern-weit wichtigste deutsche Landesgesellschaft wurde von HP abgeworben und brachte seine amerikanisierten Vorstellungen von Motivationserzeugung mit – ein weiterer Kulturschock. Das jährliche Vertriebs-Kickoff war ganz amerikanisch ausgelegt, mit FastFood und Football, und ging mit seinem Hurra-Patriotismus seiner Hurra-Salesmanship und „Wir schaffen das! Tschakka!„-Rhetorik als eine der schlimmsten Veranstaltungen in die Erinnerung vieler meiner Kollegen ein.

Warum ich das alles erzähle? Beim Aufräumen des Kellers ist die oben abgebildete, auf eben diesem Kick-Off als Goodie verteilte Basecap wieder aufgetaucht. Sie scheint mir heute in ihrer Realitätsverweigerung wie ein Vorläufer der infamen MAGA-Hüte.

Kategorien
digital musik software engineering

Tabs of Yesteryear

Brian Eno, Top-Produzent von Musik für Flughäfen und Aufzüge1, hat ein Kästchen mit Kärtchen. Auf jedem Kärtchen ein Ratschlag, um aus einem kreativen Loch, einer Uninspiriertheit herauszufinden. Hat erstmal nichts mit Musik zu tun, ist einen Blick wert, wenn man feststeckt. Digital unter Oblique Strategie, mit so zufällig ausgespielten Perlen wie:

  • Take away the elements in order of apparent non-importance
  • You don’t have to be ashamed of using your own ideas
  • State the problem in words as clearly as possible
  • u.v.a.m.

1 Okay, außerdem auch noch von U2, David Bowie, Talking Heads, … f*ck! there’s an own Wikipedia category for this!

Die Configuration Complexity Clock fasst ein (vielleicht/vermutlich) nur für Programmierer nachvollziehbares Vorgehen zusammen: Eine gewisse Abneigung gegen einfache Lösungen verbunden mit dem Wunsch „es richtig zu machen“ (im Gegensatz zu „das Richtige, vom Kunden bezahlte“ zu machen). Man beginnt damit, dass ein Programm eine gewisse Konfiguration benötigt, im Beispiel einen änderbaren Umsatzsteuer-Satz. Dazu braucht man eine Konfigurationsdatei und das könnte das Ende vom Lied sein.

Tatsächlich endet es aber öfter als einem lieb ist damit, dass die Konfiguration zu einem Programm in einer selbst-erfundenen Sprache ausartet. Und da es nun ein Programm ist, braucht es bestimmt die ein oder andere Einstellung in einer Konfigurationsdatei. Die Complexity-Clock schlägt Zwölf, das Spiel beginnt von neuem. Details im verlinkten Artikel.

Two Hard Things in Computer Science ist eine Sammlung von Martin Fowler, die ein paar meiner Lieblingsweisheiten zur IT enthält, darunter diese hier:

Kris Köhntopp in einem Twitter-Thread über den Alltag von uns Software-Entwickler:innen:

There are always existing systems that do not fit exactly, but which you are dependent on.

There is always an existing system your code has to fit into.

Hi, I am Kris. I have been working with computers since I am 14 years old, and I am over 50 now.

Die meisten von uns arbeiten nicht an Betriebssystemen und Compilern. Sondern an dem System, mit dem die Firma seit 15 Jahren ihr Geld verdient und an dem schon fünfzig Leute vor uns gearbeitet haben. Nix Drei-Wünsche-Fee. Software-Archäologie.