Computer Vintage
oder:
Wenn Produktions- und Entwicklungsketten zu komplex werden, dann könnten sie ja auch mal (zer-)reißen

Die Gedanken zu diesem Artikel entstanden im Rahmen einer kurzen Diskussion, inwieweit unsere entwickelte Gesellschaft technologisch wieder in das prä-elektrische Zeitalter zurückfallen könnte. Mein Gesprächspartner meinte, das wäre unmöglich. Dieser feste Glaube hat mich zum Nachdenken gebracht.

Ein kleiner Bruder und ein ganz kleines Brüderchen der von mir beschriebenen Flach-Baugruppe. Das Telefon soll die Größe der kleinen Teile klar machen 🙂

Anfang der 70iger Jahre studierte ich an der TUM Mathematik mit Nebenfach Informatik und war schon bald bei Siemens als Werkstudent tätig. Weil es da tolle Rechner (Computer) gab und man als Student für damalige Verhältnisse gut verdient hat.

Ich war damals in den Baracken der „Koppstrasse“ tätig. Getestet haben wir im „Feurich-Bau“ – im Zentralgelände der Siemens AG an der Hofmann-Straße. Das Leben in den Baracken war toll, es war eine richtige F&E-Atmosphäre, so wie man es sich heute bei einem guten Start-up vorstellt.

Mein erstes Projekt habe ich hier in IF-Blog beschrieben. Es ging damals um das Berechnen von möglichst großen Mersenne-Primzahlen. Das war eine Aufgabe eher für einen Einzelkämpfer.

Dann wurde ich immer mehr Teil der Teams und fast berauscht von denn Herausforderungen unserer Aufgabe. Wir arbeiteten gemeinsam mit weiteren Kollegen an der Entwicklung der PALOG-A- und PALOG-B-Systeme.

PALOG stand für „PrüfAutomat für LOGik. Die Aufgabe eines PALOG-A-Gerätes war der Funktionstest von in kleinen Serien gebauten „Maxi-Flachbaugruppen“, die in Groß-Rechnern unterschiedliche Funktionen realisierten. Die Funktionalität und die Richtigkeit der zu realisierenden Logik waren schon getestet.

Es ging „nur noch“ um das Prüfen, ob die Serien-Produktion fehlerfrei erfolgt war und die gefertigten Komponenten zuverlässig die gewünschten Ergebnisse lieferten. Die erweiterte Funktion des PALOG-B erläutere ich im weiteren Teil des Textes.

So eine Maxi-Flachbaugruppe war ein großes Brett (Board), ziemlich breit und tief aber von geringer Höhe. Die auf den Bildern abgebildeten Boards stammen aus späterer Zeit und waren viel kleiner.

Eine Maxi-Flachbaugruppe hatte auf einer Seite eine Steckleiste mit 128 Stiften, die in die Rückwand des Großrechners eingesteckt wurden. Dieser speiste das Board mit digitalen Mustern entsprechend der Anzahl der Stifte, bekam vom Board ein Ergebnis zurück und verarbeitete dieses weiter. (Vielleicht täusche ich mich und es waren nur 64 Stifte, aber ich erinnere mich deutlich an 128.)

Das Board war auf der Oberfläche voll mit Elektronik-Bauteilen, die ein paar Füße oder mehrere Füßchen hatten. Diese wurden in die vorbereiteten Löcher des Brettes gesteckt. Das ganze wurde dann von unten entsprechend verlötet, bei Serienproduktion in einem Lötbad.

Die Bauelemente auf dem Board waren zum Teil von Siemens selber entwickelt und produziert. Einiges musste zugekauft werden. Ich habe da besondere Chips von Motorola in Erinnerung, die im Einkauf auch mal um die 1.000 DM kosteten.

Wenn ich mich hier nicht korrekt ausdrücke habe, dann bitte ich dies zu entschuldigen. Ich habe nie Hardware gemacht, sondern mich schon damals ausschließlich auf die Entwicklung der Software beschränkt.

Der Prozess der Bestückung und Verlötung war alles andere als trivial.  So war es durchaus möglich – und kam auch häufig vor – dass diese Maxi-Flachbaugruppen nach der Fertigung keine oder falsche Ergebnisse lieferten. Manchmal kam es auch vor, dass die zu gelieferten Einzelteile defekt waren.

Aber wie findet man das raus? Wie testet man so eine Maxi-Flachbaugruppe?

Unsere Methode war einfach. In das zu prüfende Objekt wurden Bitmuster gesendet und dann geprüft, ob die Antwort die richtige (erwartete) ist. Einen solchen Test kann man aus Effizienzgründen natürlich nicht mit allen möglichen Eingabe-Mustern durchführen. Die Aufgabe unserer Software war es, relevante Muster zu generieren, mit denen man in möglichst wenigen Testschritten beweisen konnte, dass die Logik der Maxi-Flachbaugruppe richtig funktioniert.

Noch mal die kleineren und jüngeren Brüder der Maxi-Flachbaugruppe.

Dazu wurde diese in den PALOG-A Automaten eingespannt und dort mit den ihrer Funktionalität entsprechenden Binär-Mustern über die 128 Stifte beschickt. Die Antworten wurden mit den Soll-Ergebnissen verglichen. Wenn IST und SOLL bei allen Testmustern übereingestimmt hatte, war validiert, dass die Maxi-Flachbaugruppe einwandfrei funktioniert.

Die Suchen und Finden der relevanten Testmuster war alles andere als einfach und wurde ziemlich „mathematisch“ aus der jeweiligen Funktionalität heraus entwickelt. Die Programmierung erfolgte „cross“ auf BS1000 und dann bald auch auf BS2000.

Die Muster selber und die richtigen Antworten wurden auf Prozessrechnern der Serie 300 generiert. Die hatten übrigens einen 6-Bit-Assembler mit zwei Akkumulatoren und dem schönen Namen PROSA. Die „Dreihunderter“ galten als ungeheuer schnelle Rechner.

Das Spitzenmodell war die 306. Aber auch diese in der damaligen Zeit absolut schnellste Maschine von Siemens brauchte gut und gerne auch mal eine Woche oder mehr für die Berechnung der benötigten Muster.

Ein Rechner lief damals selten eine Woche ohne Ausfall. Meistens stürzte er in so einem langen Zeitraum schon ein paar mal ab. Deswegen hatte die Software neben der algorithmischen Herausforderung noch weitere wie die Wiederaufsetzbarkeit des Programms bei einem Systemabsturz. Dies war damals alles andere als eine Selbstverständlichkeit.

Soweit so gut. Immerhin konnten wir mit PALOG-A zuverlässig validieren, ob eine Maxi-Flachbaugruppe fehlerfrei war oder nicht. Allerdings gab es ziemlich häufig mangelhafte Produkte. Was macht man mit diesen? Allein aufgrund der teuren eingesetzten Bauelemente wollte man die natürlich nicht vernichten oder zurück bauen, denn damit wäre auch nicht viel gewonnen worden. Man wollte also möglichst alle wenn irgendwie möglich reparieren.

Wenn ich einen Fehler in einer komplizierten Logik einer Flachbaugruppe beheben will, muss ich aber zuerst einmal herausfinden, wo er sich auf dem Board befindet. In unserem Fall geht das natürlich nicht durch logisches Überlegen oder „Code Reading“ wie bei einem Programm. Auch einen eingebauten Debugger hatter wir nicht. Die Frage ist ja, welches Bauteil falsch sein könnte, welche Lötstelle nicht funktioniert oder ähnliches …

Da kam unser System PALOG-B ins Spiel. Wenn eine Maxiflachbaugruppe von PALOG-A als fehlerhaft erkannt wurde kam sie ins PALOG-B-System. Dort wurde sie einer (von uns so genannten) PFAD-Methode unterworfen und mit ganz anderen Testmustern bearbeitet. Diese ermöglichten an Hand der zurück kommenden Daten den Fehler auf dem Board einzukreisen. So war es möglich durch mehrfaches Einkreisen die möglichen Fehler zu beheben. Dann wurde das Board wieder mit PALOG-A getestet, und wenn es dann funktioniert hat wurde gejubelt.

Warum das Vorgehen „PFAD-Methode“ hieß, kann man sich gut vorstellen. Man sich nur überlegen, dass verschiedene Eingabemuster verschiedene „Pfade“ auf der Flachbaugruppe durchlaufen. Und wenn man fest stellen kann, welche der vielen möglichen verschiedenen Pfade nicht funktioniert, ist man dem Fehler schon deutlich näher.

Ich habe versucht, das alles möglichst einfach und gut verständlich zu beschreiben. In Wirklichkeit war das Ganze aber sehr kompliziert und wurde von einem über sehr viele Jahre erarbeiteten und weitergegebenen Know-How getragen.

Unsere Software war nur ein kleiner Teil der für die effiziente Entwicklung und Produktion von IT-Systemen notwendigen Design- und Konstruktionssoftware. Da ging es bei Siemens damals mit großen Fortschritten weiter. Ein paar Jahre später hatte die Siemens AG eine umfassende Workbench aus vielen SW-Systemen für die Entwicklung ihrer Chips, die wahrscheinlich allen Konkurrenz-Systemen deutlich überlegen war.

Leider habe ich Abkürzung dafür vergessen, weiß aber noch, dass diese Anwendung als die komplizierteste SW-Lösung der Welt galt und die meisten „Lines of Code“ aller bekannten Programmsysteme gehabt haben soll.

Und dann ging es abwärts mit dem Bereich Datenverarbeitung und all das Know-How verschwand.

😉 Aber was interessiert den Juden und auch uns „die Freud von gestern“?
Vorbei ist vorbei!

Ich kann mir vorstellen, dass das Know-How und die Werkzeugkette, die gebraucht werden um einen Intel-Prozessor oder einen IBM Power zu entwickeln und zu produzieren mittlerweile eine ungleich höhere Herausforderung darstellt als damals die doch noch überschaubaren Flachbaugruppen.

Und es könnte sein, dass nicht nur so ein High-Tech-Prozessor sondern auch der „einfache“ elektrische Motor oder Stromgenerator heute ohne einer ähnlich komplexen „Maschinerie“ so ganz einfach nicht mehr hergestellt werden können. Und wenn die zerbricht – warum auch immer – was dann?

Damit habe ich den Kreis geschlossen und komme zur Eröffnung meines Artikels. Genau wegen der Durchdringung solcher Werkzeug- und Produktionsketten in allen Technologien und Sparten – ob Chemie, Energie, Landwirtschaft, Mechanik, Pharmazie, Physik … könnte ich mir gut vorstellen, dass unser System kippen kann und wir dann wieder bei NULL anfangen müssen. Und das das dann sehr schwierig sein könnte.

RMD

P.S.
Ich schreibe die technischen Erinnerungen aus dem Kopf heraus und völlig ohne Unterlagen auf. Leider ist Wikipedia bei solchen spannenden Themen der Informatik gar nicht so recht hilfreich. Ich finde es schade, dass in Wikipedia ausgerechnet die Technik, die Wikipedia erst ermöglicht hat, kaum und meistens sehr ungenügend  beschrieben ist.

Insofern bitte ich zu entschuldigen, wenn ich die eine oder andere Abkürzung falsch in Erinnerung habe oder ähnliche Fehler mache. Ich konnte nirgends nachschauen und so meinen Erinnerungen auf die Sprünge helfen. Umso mehr bin ich für Korrekturen und Hinweise zur von mir berichteten Technik dankbar.

Von Stand-by-Jobs, Facilitation und Fahrerlosen U-Bahnen. Und vom Uli.

Vor kurzem habe ich Ulrich Sendler kennen gelernt. Uli ist „Unabhängiger Technologieanalyst“ und Musiker. Er schreibt Bücher (die sogar ins chinesische übersetzt werden und dort hohe Auflagen haben), hält Vorträge (so wie ich ihn erlebt hatte dürften die sehr kompetent aber auch unterhaltsam sein) und ist als Berater und Moderator unterwegs. Bei unserem Treffen hat er mir erzählt, dass er demnächst in Gütersloh eine „keynote“ zum Thema „Automated Society“ halten wird. Irgendwie erscheint das mir die logische Entwicklung unserer „Self-Service-Society“. Ich bestelle den Dienst im Internet und die Lieferung erfolgt oder Dienstleistung erfolgt dann automatisch.

„Automated Society“ und „Self-Service-Society“ sind für mich auch „buzz words“, die gerne als Merkmale unserer „neuen digitalisierten Gesellschaft“ in unserem „post-faktischen Alltag“ genannt werden.

Sie haben bei mir gleich ein paar Assoziationen und Gedanken ausgelöst:

Technologie hat das Ziel, dem Menschen Leben und Arbeit einfacher zu machen. Dafür gibt es auch ein schönes und heute oft verwendete buzz word:
Facilitation!
Im englischen Wikipedia wird das Wort zurzeit so definiert:
Facilitation is any activity that makes tasks for others easy, or tasks that are assisted.

Im alltäglichen Leben hat das dazu geführt, dass die Arbeit von uns Menschen durch viele technologisch Errungenschaften erleichtert wird. Das kann auch dazu führen, dass wir gar nichts mehr zu tun haben.

Denken wir an einen Piloten der Lufthansa. Die sind zurzeit wegen ihrer Streikleidenschaft öfters in der Presse. Der arme Pilot darf auf einem Langstreckenflug wie in die Karibik wohl nur noch 10 Minuten – beim Einleiten und Durchführen von Start und Landung. Den Rest schaut er zu, wie der Flieger so vor sich hin fliegt. Der arme Pilot darf seine Langweile auch nicht mit Computer-Spielen vertreiben. Alkohol wird ihm auch verboten sein wie bestimmt auch der Damenbesuch im Cockpitz.B. durch eine Stewardess. Was übrige bleibt ist dann Langeweile.

Wecker1Ich nenne solche Berufe „Stand-by-Jobs“. Da ich als Programmierer tätig war ist das für mich, wie wenn ich dem Computer 8 Stunden beim Programmieren zu schauen muss und dann in fünf Minuten kurz überprüfe, ob das entstandene Programm den Vorgaben entspricht. Ich stelle mir so einen Job eher grausam vor. Kann gut sein, dass so ein Stand-by-Job depressiv macht.

Vor ein paar Jahrzehnten hatte ich nach einem Job-Wechsel beim neuen Arbeitgeber gut zwei Wochen nichts zu tun. Von Morgens bis Abends saß ich im Büro, langweilte mich und versuchte verzweifelt mich sinnvoll zu beschäftigen. Und die Zeiger der Uhr schienen so richtig dahin zu schleichen.

So unglücklich wie damals war ich nie in meinem Arbeitsleben.

Münchner U-Bahnhof Dietlindenstraße (U6) - Urheber: FloSch - Eigenes Werk unter CC BY 2.5 (2005)

Münchner U-Bahnhof Dietlindenstraße (U6) – Eigenes Werk von FloSch, unter CC BY  2.5 veröffentlicht in Wikipedia (2005)

Die Stadtwerke München (SWM) betreiben unter anderem das Münchner U-Bahn-System. Die SWM sind intelligente Arbeitgeber, die wissen, dass Menschen „Stand-by-Arbeit“ nicht mögen. U-Bahnfahrer ist auch zum „Stand-by-Job“ geworden. Die Stadtwerke wollen glückliche U-Bahnfahrer haben, die ihren Job motiviert erfüllen. Vor kurzem habe ich gelernt, dass ein U-Bahnfahrer an jeder Haltestelle aussteigen muss um die Befüllung des Zuges zu kontrollieren und dann wenn diese erfolgreich erfolgt, die Abfahrt frei geben darf. Das ist seine wesentliche Aufgabe.

Die Maßnahme dient der Sicherheit am Bahnsteig. Vor allem aber dient sie dem Fahrer, denn so wird sein Job wieder verantwortungsvoller, abwechslungsreicher und er hat sogar ein wenig Bewegung. Das tut Seele und Körper gut.

Nur, die U-Bahnen in Nürnberg fahren seit Jahren ohne Zugführer. Und die in Lyon schon seit Jahrzehnten. Und in beiden Fällen scheint das System sehr gut zu funktionieren, sogar besser als mit Fahrer.

Die Schlussfolgerungen überlasse ich meinen Lesern.

RMD

P.S.
Gestern bin im mit dem Bus 210 des MVG von Neuperlach Bahnhof nach Ottobrunn, Haltestelle Jahnstr. gefahren. Der Fahrer saß ziemlich abgegrenzt vorne in seinem dunklen Kabäuschen. Der Kontakt vom Fahrzeug zu den Menschen war automatisiert, die Anzeige und die Ansage der Haltestellen. Der Fahrer ist nur noch der Lenker, er hält an, wenn er Menschen an der Haltestelle sieht oder ein Fahrgast auf den Knopf drückt. An diesem Abend hatte ich Glück, der Fahrer ist sehr vernünftig gefahren und hat auf starkes Beschleunigen und heftiges Bremsen verzichtet. Das war mir angenehm. Es gibt aber auch Fahrer, bei denen geht es so richtig rund. Dann hat so ein selbstfahrender Bus schon auch seinen Vorteil… Technisch sollte es ja heutzutage möglich sein.

 

Bundesverkehrsminister Alexander Dobrindt hat dem Auftrag des Bundeskabinetts und seiner Kanzlerin folgend eine Ethik-Kommission einberufen. Sie soll unter anderem klären, wer für Unfälle haftet, die von autonomen Fahrzeugen verursacht werden – der Fahrer oder der Hersteller.

🙂 Könnte doch sein, dass so ein durchgeknallter autonomer Computer einen Unfall aufgrund von Raserei verursacht. Wer bekommt dann das Bußgeld – oder die Strafanzeige?

Die Ethik-Kommission soll aber wohl auch untersuchen, ob es ethische Normen gibt, denen das autonome Fahrzeug in Konflikt-Situationen folgen muss. Der ehemalige Bundesverfassungsrichter Udo di Fabio wird die Leitung dieser Kommission übernehmen. Der Wirtschaftswoche hat der Minister dazu auch ein Interview gegeben.

11348857_10206989802848252_348583267_oDas Thema Ethik beschäftigt mich seit meinem ersten Seminar bei Rupert Lay Anfang der 80iger Jahre wesentlich. Nach meinem Verständnis beschäftigt sich Ethik unter anderem auch mit moralischen Dilemmas. Ein grundlegendes Beispiel für so etwas ist das Trolley-Problem.

Ich zitiere dazu aus dem entsprechenden Artikel in Wikipedia:

Ein Güterzug droht wegen falscher Weichenstellung auf einen vollbesetzten stehenden Personenzug aufzufahren. Ein Weichensteller erkennt die Gefahr und leitet den Güterzug auf ein Nebengleis um, so dass dieser in eine Gruppe von Gleisarbeitern rast, die alle zu Tode kommen. Wie ist die Strafbarkeit des Weichenstellers zu beurteilen?

Diese Frage ist wohl von Welzel 1951 gestellt worden. In den Folgejahren bis heute wurden viele „Gedanken-Experimente“ dieser und ähnlicher Art formuliert. Eines der schärfsten, das mich zumindest meisten beeindruckt hat, ist folgendes:

Ein Arzt hat zehn Patienten in seiner Praxis. Jeder davon ist dem schnellen Tode geweiht, denn eines seiner Organe (bei jedem ein anderes) ist komplett zerstört. Um gesund zu werden braucht jeder innerhalb kürzester Zeit „sein“ Spenderorgan.  Es besteht aber keine Aussicht, dass diese verfügbar sind.

Zufällig kommt ein gesunder Mann in die Praxis. Der enthält genau all die Organe, die der Arzt zur Rettung sämtlicher seiner Patienten bräuchte. Soll der Arzt den Mann (den Menschen) töten, um die anderen (10 Menschen) zu retten?

Hier wird das Thema auf die Spitze getrieben. Obwohl es ethisch durchaus überlegenswert scheint, einen Mensch zu töten um zehn Menschen zu retten, wird diese Lösung von den meisten Menschen komplett ausgeschlossen. Warum? Ich vermute, weil dann sich niemand mehr „zum Arzt gehen“ trauen würde.

Das scheint mir der wirkliche Zweck von Moral zu sein: Wir wollen Dinge unmöglich machen, vor denen wir für uns Angst haben. Und die uns selber auf keinen Fall passieren dürfen. Deshalb soll für all das gelten: Das tut man nicht! Und schon der Gedanke wird zum Tabu.

Das macht dieses „Gedanken-Experiment“ für mich so wertvoll, weil es vielleicht lehrt, was hinter der Moral (Das tut man nicht!) stecken könnte.

Auch das öffentliche Fernsehen handelt jetzt mit Ethik. So hat die ARD am 17. Oktober 2016 das TV-Experiment „Terror – Ihr Urteil“ gezeigt. Und dann die Zuschauer abstimmen lassen, wie der Film ausgehen soll (Verurteilung oder Freispruch für den Piloten im ethischen Dilemma). Die Kritiken, die ich gelesen habe, waren aber von diesem Experiment nicht so begeistert.

Das Arzt-Beispiel erscheint mir übrigens sehr viel sinnvoller als das vom Trolley. Ärzte kann, so kann ich es mir vorstellen, stehen schon eher mal von einem ähnlichen Dilemma, zum Beispiel wenn sie bei einer Katastrophe wie dem Zugunglück in Bad Aibling entscheiden müssen, um welchen Patienten sie sich zuerst kümmern müssen. Wobei auch dieser Vergleich sehr hinkt.

Aber zurück zu den vielen Gedankenexperimenten mit Trolleys, Straßenbahnen, Güterzügen usw. All das ist spannend für eine intellektuelle Diskussion. Nur für die praktische Anwendung erscheint mir das alles völlig sinnlos.

All diese Konstrukte stammen aus dem Beispielraum des an Schienen gebundenen Verkehrs. Dort ist mir aber kein belegbares Ereignis bekannt, wo so etwas in der Realität passiert wäre. Das heißt, das wohl auf der ganzen Welt kein einziger Fahrdienstleister vor so einer Entscheidung gestanden hätte. Wir diskutieren und arbeiten uns also intellektuell-ethisch an reinen Kopfgeburten ab.

In der Wochenendausgabe der SZ finden wir einen gut gemachte „digitale“ Reportage zum Zugunfall nahe Bad Aibling. Da gab es am Morgen des 9. Februar zwölf Tote und 89 Verletzte. Die digitale Reportage hat den Titel Chronologie eines vermeidbaren Unglücks. Ich empfehle, diese Reportage unbedingt anzuschauen und auf den Link zu gehen.

Da wird gezeigt, dass die Realität ganz anders ausschaut. Besonders wenn es zu Unfällen kommt. Wir lernen, dass

  • in elektronischen Stellwerken, die technisch auf dem aktuellen DB-Stand sind, der Fahrdienstleiter deutlicher auf seine erste Freigabe hingewiesen worden wäre: Zumindest durch einen dicken, roten und leuchtenden Pfeil. Im Bad Aiblinger Stellwerk aber fehlt eine solche Anzeige, da die Technik älter war. Da war  ein Sicherheitsrisiko, das der Deutschen Bahn seit langem bekannt war. Eine interne Richtlinie würde seit den 80er-Jahren empfehlen, die alten Relaisstellwerke entsprechend nach zu rüsten. Bei einer „Digitalisierung des Stellwerkes“ auf den „aktuellen technischen Stand“ hätte es eine gute Chance gegeben, dass der Unfall nicht passiert wäre, bei einer kompletten Digitalisierung wäre er wohl nicht möglich gewesen. Ob so etwas ethisch ist, das wäre nach meiner Meinung durchaus diskussionswürdig.

Was erfahren wir noch?

  • Schichtarbeit ist nicht gut!
    Dienstbeginn für den Fahrdienstleister war 5 Uhr. Eine dreiviertel Stunde dauert die Fahrt von dem Bauernhof, auf dem er mit seiner Familie lebt, bis zu seinem Arbeitsplatz am Bahnhof von Bad Aibling, zehn Kilometer westlich von Rosenheim. Wegen eines vom Deutschen Wetterdienst noch in der Nacht angekündigten Sturms hat sich der Fahrdienstleister an diesem Tage wohl früher als sonst auf den Weg in die Arbeit gemacht. Daraus schließe ich, dass bei ihm irgendwann nach 3:00 der Wecker geklingelt. Da kann die Nacht nicht lange gewesen sein.
    Schichtarbeit ist generell ein Problem. Sie ist schädigt die Gesundheit. Dafür gibt es viele Belege. Und immer wenn ich morgens (damit meine ich aber eher vor 6:00) in der S-Bahn sitze, sehe ich nur graue Gesichter (außer die aufgekratzten Mädels und Jungs, die am Ostbahnhof vom Kunstpark Ost kommend zusteigen). Und so richtig fit ist der Mensch halt dann auch nicht. Zumindest ich bin es nicht. Hier aber gute Nachricht:
    Computern (digitalen Systemen) macht Nachtschicht nichts aus!

Weiter lernen wir, dass man am Arbeitsplatz nicht spielen soll.

  • Computerspiele sind gefährlich!
    Um 5:11 startet der Fahrdienstleiter auf seinem Smartphone das Videospiel „Dungeon Hunter 5“. In dem Fantasie-Rollenspiel jagt er als Kopfgeldjäger Monster und Schurken. In den Dienstvorschriften der Bahn steht: Fahrdienstleiter dürfen ihre privaten Smartphones bei der Arbeit nutzen, wenn es für ihre Tätigkeit erforderlich ist. Spiele sind ausdrücklich verboten. Und jeder wird sagen, natürlich darf man während der Arbeit nicht auf dem Computer spielen.
    Aber, ist das realistisch? Nur, wer hält sich daran?  Denn wir bekommen immer mehr Standby-Arbeitsplätze. Das beste Beispiel ist die hoch bezahlte Berufsgruppe der Piloten. Das sind Spitzenverdiener und Leute mit einem harten Job. Wechselnde Arbeitszeiten, Nachtdienste, Klima-Wechsel usw.
    Nur hat man mir berichtet, dass der Pilot auf einem Langstreckenflugzeug von z.B. 8 Stunden nur zwei mal 5 Minuten etwas zu tun hat. Was macht man in solcher einer grausamen Situation? Saufen? Das darf man auch nicht. Also bleibt nur Spielen.
    Ich erinnere mich auch gerne an Messen, auf denen das gelangweilte Standpersonal auf allen neuen PC’s Solitär spielte – und ich gestehe hier, dass ich auch mal Solitär-süchtig war. Nicht wegen der Spielesucht, das kann jedem passieren. Sondern weil dieses Spiel wahrscheinlich erst Windows zum großen Durchbruch verholfen hat. Die gute Nachricht ist wieder:
    Computer (digitale System ) spielen nicht! Sondern konzentrieren sich auf ihre Arbeit!

Insofern sollten wir zuerst mal die Digitalisierung richtig machen, um das Leben gesünder und sicherer zu machen.

Nur – die Autos der Zukunft sollen sich jetzt mit solchen Problemen beschäftigen und sie per Programm lösen – zumindest in Gedanken einer Ethik-Kommission. Und zum BEispiel entscheiden, welchen Radfahrer sie überfahren sollen, wenn sie situativ (Gedankenexperiment!) keine andere Wahl haben als einen von beiden zu überfahren. Wir nehmen mal an: Der/die eine Radler*In ist ein Mann und trägt keinen Helm. Die andere ist eine Frau, die brav einen Helm trägt. Soll das System jetzt entscheiden, die Frau zu überfahren, weil sie – mit Helm – die besseren Überlebenschancen hat? Oder den Mann, zur Strafe weil er keinen Helm trägt? Oder aufs Geschlecht oder Alter schauen. Oder auf die soziale Verantwortung, die die beiden haben …

Ich halte das für Unsinn. So halte ich von der Dobrindt’schen Ethik-Kommission nichts. Wahrscheinlich ist sie eh nur ein kleines Mosaik-Steinchen im Wahlkampf zur nächsten Bundestags-Wahl, mit dem die große Koalition zeigen will, welche wichtige Themen sie – weltweit als einzige Administration wie wohl auch beim Datenschutz – so mutig und umsichtig angeht und so eine besonders verantwortungsvolle Position im Rahmen der Digitalisierung einnimmt. Auch wenn diese Position den Realitäten der Zeit beliebig fern ist.

Wie hat mal einer gesagt: Alle Politiker sprechen vom digitalen Wandel und werfen mit Begriffen wie block chain und big data um sich. Sie wissen aber nicht, was das ist! Wie sie auch Reformen wollen, aber keine Veränderung (Reform ist gewaltfreie Veränderung). Und Innovation wird gefordert, aber bloß keine Zerstörung. Nur: Innovation ist halt kreative Zerstörung. Ich habe immer den Verdacht, dass wenn Politiker die Geschichten von Bloggern und Blogs hören, sie heimlich an den Blockwart, der aufpasst, dass nichts passiert.

Wenn, dann würde ich mir eine Ethik-Kommision im Ministerium von Frau van der Leyen wünschen, die mal bewertet, wie ethisch vertretbar der Einsatz von Kampf-Drohnen und –Robotern zum Beispiel zum freien Töten von Menschen ist. Auch das Problem, dass im Internet wohl das Motto gilt „The winner takes it all“ und ob es sein darf, dass irgendwann mal Konzerne wie Google das Alphabet der Welt bestimmen werden könnte mal eine Ethik-Kommission beschäftigen, gerne im Wirtschafts- und Sozialministerium.

RMD

P1070216Wir leben ja im Zeitalter des unverantworteten Geschwätzes. Das erlebe ich besonders intensiv, wenn ich höre, was selbst ernannte Propheten zum Thema Digitalisierung so alles herum spekulieren. Wie viel Unsinn da dabei ist. Dann muss ich auch noch feststellen, wie viele auf den Zug aufspringen und das Gehörte oder Gelesene unkritisch nach plärren. Und so Ängste an falschen Stellen schüren, die von den wahren Bedrohungen nur ablenken. Und erstaunlich wer da alles immer so dabei ist.

Ich persönlich betrachte den „digitalen Wandel“ nur als schlichte Fortsetzung der durch Technik bedingten Veränderung im Zeitalter der kompletten Elektrifizierung des Planeten (oder so). Da ich ihn erlebt und selber mit gemacht habe, versuche ich dem oft von einzelnen geäußerten und von vielen nachgeplapperten Blödsinn entgegen zu treten.

Zum Beispiel ist für mich ein „fahrerloses“ Fahrzeug, sei es ein LKW, Bus oder Auto z.B. nichts anderes als technologischer Fortschritt, bei dem Eisen durch IT ersetzt wird. Die neuen Fahrzeuge brauchen halt keine Schienen mehr, sondern nutzen IT um auch ohne Fahrer an ihr jetzt variables Ziel zu finden. Das ist kein Hexenwerk sondern nur schlichte Ingenieursarbeit.

Ein harmloses Beispiel für Panikmache ist in meiner Bewertung auch die so viel zitierte „Filterblase“. Immer mehr Leute behaupten in Sonntagsreden, dass hier eine große Gefahr droht und wir „von Algorithmen“ manipuliert werden. Ich mache es mir einfach und kopiere einen Text aus dem dazugehörigen <a href=“http://if-blog.de/wp-content/uploads/2015/06/P1070216.jpg“><img class=“alignleft size-medium wp-image-52015″ src=“http://if-blog.de/wp-content/uploads/2015/06/P1070216-300×208.jpg“ alt=“P1070216″ width=“300″ height=“208″ /></a> in Wikipedia (Stand heute – 27. Oktober 2016).


Die Filterblase (englisch filter bubble) oder Informationsblase (englisch informational bubble) ist ein Begriff, der vom Internetaktivisten Eli Pariser in seinem gleichnamigen Buch[1] verwendet wird. Laut Pariser entstehe die Filterblase, weil Webseiten versuchen, algorithmisch vorauszusagen, welche Informationen der Benutzer auffinden möchte – dies basierend auf den verfügbaren Informationen über den Benutzer (beispielsweise Standort des Benutzers, Suchhistorie und Klickverhalten). Daraus resultiere eine Isolation gegenüber Informationen, die nicht dem Standpunkt des Benutzers entsprechen.


Nur – das ist doch nichts Neues!

So habe ich von Kindes an in meiner „Filterblase“ gelebt. Kaum konnte ich lesen, habe ich (zuerst in der katholischen Pfarr- und später in der öffentlichen) Bücherei mir genau die Bücher ausgewählt, die nach kurzer Leseprobe meinem WEIB (Eselsbrücke für Werte, Erwartungen, Interessen und Bedürfnisse) entsprochen haben.

Als Zeitungsleser habe ich schnell die SZ dem Münchner Merkur bevorzugt. Später habe ich gelernt, dass die Zeitungen versuchen genau das zu schreiben, was ihre Leser lesen wollen …

Als Jugendlicher ging ich zu den Treffen der „republikanischen Clubs“ und nicht zur jungen Union und zu den Burschenschaften.

Aufgrund meiner Beschränktheit habe ich mich so selber in meine „Blase“ rein gebracht. Damals hat mich das Radio aus dieser raus geholt. Da kam zum Beispiel an Silvester die Lach&Schieß und hat mich auf völlig neue Gedanken und Meinungen gebracht.

Aus dem Radio als „öffentlichem Rundfunk“ ist das Internet geworden. Ich kommuniziere mit anderen Menschen, lese deren Blogs und höre ab und zu sogar deren PodCasts. Ich bin da ein wenig altmodisch und lese noch, weil  ich nicht immer nur mit Kopfhörern herumlaufen mag. Aber auch mein Verhalten wird die Zukunft nicht beeinflussen. So wird „Audio“ im Wissenstransfer und Meinungsaustauch sicher gegen die „Verschriftung von Information“ gewinnen.

So erlebe ich viel Neues und Neuartiges im Netz. Denn das Internet besteht eben nicht nur aus Google und Facebook sondern vor allem aus den Menschen, die ihre Bewertungen und ihr Leben bloggen und podcasten und mich mit vielen Gedanken versorgen, die in der Tat häufig meine Vorurteile widerlegen und mich zu Toleranz ermahnen. Und so lerne ich, Respekt und Wertschätzung für Meinungen und Menschen zu gewinnen, die ich früher einfach so abgelehnt hätte.

Meine Freunde machen es genauso. In dieser „Bubble“ fühle ich ich sehr wohl. Auf die Algorithmen scheiße ich. Und sehe da auch nicht die große Gefahr. Oft habe ich den Eindruck, dass das Internet als neuer „Buhmann“ von der massiven Manipulation durch Werbung und Lobbyismus ablenken soll. Weil es tatsächlich freier und autonomer macht und so den herrschenden Strukturen und Systemen gefährlich wird. Deshalb wird auch von diesen die Freiheit des Internets nicht so gerne gesehen und so die Einschränkung von Freiheit im Netz mit allen Argumenten begründet – und mögen sie auch noch so dümmlich sein.

RMD

Hans Bonfigt
Freitag, der 7. Oktober 2016

DAMIT ICH MICH BESSER FRESSEN KANN

Ein Computergigant kannibalisiert sich selbst und wirft dabei so ganz nebenher die führende Rechnerarchitektur auf den Komposthaufen der „Community“.

Das ist das, was sich als Zusammenfassung vom „Linux on Power Anwendertag 2016“ aus dem IBM – Labor in Böblingen mitgenommen habe.

Ach ja, und Menschen „50+“ sind in der „IT“ deplaziert.
Wurde mir mehrfach klar gesagt.
Vielleicht, weil sie wissen, was sie tun?   Und vor allem: Was sie besser seinlassen?

Dies ist jetzt wieder einmal ein unsachlicher, fachlich sehr spezieller Bericht, er wird bestimmt lang und von geringem allgemeinen Interesse sein. Wer nicht weiß, für was AIX, AS/400 oder MVS stehen: Jetzt wäre es Zeit, hier mit dem Lesen aufzuhören.

Seit 1996 stagniert die INTEL – Welt, nicht, weil die Prozessoren schlecht wären, sondern weil die Architektur buchstäblich an ihrer eigenen Kleingeistigkeit erstickt.

Denn – wie hat das eigentlich angefangen?

Begeben wir uns einmal in die Zeit, als es in der Informationstechnik nur IBM gab und den „BUNCH“, Borroughs, Univac, NCR, Control Data und Honeywell. Der glücklose IBM – CEO sah verschnupft den Erfolg der „Äppel-Computer“, die sich den Anschein gaben, als könnten auch ganz normale Menschen damit umgehen. „Wo ist mein Äppel????“. Sehr eilig baute man im eigenen Hause etwas zusammen, den „Datamaster“.

Dazu vielleicht ein autobiographischer Einschub: Eine Laune des Schicksals hat dazu geführt, daß ich einige Zeit mit der Konstruktion von Scherenhebebühnen befaßt war. Im Zuge dieser Arbeiten wurde ich zu einem Konstruktionsseminar verdonnert. Es wurden dort Teams gebildet, die sich nach Sympathie ergeben hatten. Meines bestand aus Hubtisch- und Kranbauern. Ärgerlicherweise lautete die Aufgabe an uns nicht, „Baut ein Schwerlasthebezeug für einen Güterwaggon“, ein Job, den wir mit Bravour gelöst hätten, sondern, Gipfel der Infamie:
„Baut einen Kinderwagen“.

Was soll ich sagen, wir haben den teuersten, schwersten und unbrauchbarsten Entwurf abgeliefert. Und den scheußlichsten, denn er sah aus wie eine Hebebühne.

So wie diesen mißratenen Kinderwagen muß man sich den IBM „Datamaster“ vorstellen. Wenn Mainframe-Bauer PCs bauen sollen, dann kommt ein kleiner Mainframe dabei heraus, aber kein PC.

So kam es, daß der „Datamaster“ desaströs floppte und Akers tobte.

IBM – Mitarbeiter Don Estridge erklärte Akers:
Wenn Sie einen Computer für die Ahnungslosen bauen wollen, dann müssen Sie ihn von Leuten bauen lassen, die garantiert keine Ahnung von Computern haben„.

Das war sein Verhängnis: Mit 11 weiteren Flaschen, die in der Entwicklung entbehrlich waren, wurde er buchstäblich in die Wüste geschickt, wo er den „Personal Computer“ bauen sollte.

Der IBM – PC. Er war so erbärmlich, wie er aussah.

Dieses jenseits jeder Schamgrenze zusammengefrickelte Stück Sondermüll fackelte schon bei der internen Präsentation ab – nicht umsonst nannte man dessen Macher IBM – intern „Das dreckige Dutzend“. Aber warum auch immer:

IBM brachte das Mistding auf den Markt und weil alles, was IBM vorgab, zu jener Zeit sofort zum „Industriestandard“ avancierte, war eine Seuche geboren, die schlimmer war als AIDS, Ebola und Islamismus zusammen.

Aber auch Akers hatte sich selbst keinen Gefallen damit getan, denn die unbeabsichtigte Etablierung eines „Standards“ etablierte vor allem eines: Konkurrenz. Infolge einer fatalen Verkettung unglücklichster Umstände (ein IBM – Berater wollte am Wochenende in Ruhe angeln gehen, anstatt in Armonk eine wüste Folienschlacht über sich ergehen zu lassen) wurden Paul Allen und William H. Gates mit der Aufgabe betraut, ein Betriebssystem für diese Krätze zu bauen.

Das hatten sie nicht — aber warum auch, wenn man eines klauen konnte?

So wurde aus CP/M im Magenumdrehen „MS-DOS“, welches in seiner unausgegorenen Primitivität und desaströser Konzeptlosigkeit perfekt zur elenden Hardware paßte.

Die Folgen sind bekannt:

Bei Landfahrzeugen besteht aus gutem Grund eine starke Diversifizierung: Wir sehen täglich Bagger, Tieflader, Sattelschlepper, Motorräder, Cabriolets, Reisebusse, Fahrräder, Lokomotiven und Rennwagen. Kein Mensch käme auf die Idee, mit dem Möbelwagen in die Stadt zum Eisessen zu fahren oder mit dem Motorrad einen Umzug zu unternehmen.

Wirklich kein Mensch?

Der gemeine PC-Trendlemming war so dämlich. Und ist es heute noch. Selbst aktuelle Intel-„Server“ booten noch mit „DOS“. Und wer das nicht glaubt, der werfe eine Suchmaschine seiner Wahl an und finde heraus, wie PXE funktioniert, was ein „C/H/S-Interface“ ist und ein „A20-Gate“.

Jedermann kann nachvollziehen: Aus einem „Trabant“ macht man keinen Sportwagen und keinen LKW.

In der Informationstechnologie jedoch ist dies „Best Practice“.

Es gibt heute nur noch den vielfältig aufgebohrten „IBM PC“ in unterschiedlichen Metastasierungen.

DEC, SUN, HP und IBM hoben sich lange Zeit ab von dem billigen Tand und bauten tolle Prozessoren, SUN die „SPARC“, HP sein PA-RISC, DEC seinen legendären „Alpha“ und IBM unter anderem POWER.

Und diese Firmen hatten für ihre Kunden auch ernstzunehmende Betriebssysteme entwickelt, MVS, Solaris, VMS, AIX, OS/400…

Betriebssysteme, Prozessoren, Hauptspeicher und externer Speicher wurden individuell und nach Anforderung im Rahmen einer qualifizierten Ingenieursarbeit zu einem System zusammengestellt.

PCs und leider auch sogenannte „Intel-Server“ dagegen wurden und werden völlig sinnfrei von gegelten Trieftollen-Salesguys zusammengestellt. Einzige, dafür aber zwingende Anforderung an das Flachpersonal: Garantierte Ungetrübtheit von jeder Art Bildung oder gar technischem Sachverstand.

Mir war diese Entwicklung zunächst gar nicht so unrecht:

Ich fand es gut, daß sich „meine“ Server von den Billigbüchsen unterschieden, die Stabilität und die durchdachten Details der Betriebssysteme gefielen mir, mein Beruf war angesehen.

Bezahlt wurde auch recht gut.
Der Name IBM stand für Zuverlässigkeit, Qualität und Leistungsfähigkeit.

Irgendwann wollte oder mußte IBM Kosten senken.
Und da hatte man tolle Ideen:

  • Die für etwa 20 Milliarden entwickelte „Next Generation Platform“ wickelte man über eine Beerdigungsfirma ab, denn „eigene Hardware ist zu teuer“.
  • Die eigene Chipfertigung wurde verkauft.
  • Das für die eigenen, professionellen Systeme optimierte AIX, seit gut 25 Jahren stabil, robust, sicher, skalierbar und leistungsfähig, soll durch „Linux“ ersetzt werden, einen billigen Unix-Abklatsch: Technologie von gestern mit den Konzepten von vorgestern. Aber alle finden es ja soooooo toll.
  • Und auch die kommerziellen Systeme sollen durch Linux ersetzt werden: „One Size Fits All“.

Mir ist es ja egal, was IBM verzapft (wenn’s ‚mal so wäre…), es wird, solange ich lebe, immer Kunden geben, die meine Arbeit zu schätzen wissen – den Massenmarkt habe ich nie bedient.

Aber dennoch packt mich das blanke Entsetzen, wenn ich dann doch einmal an einer IBM – Konferenz teilnehme — und damit sind wir gnadenlos in der Gegenwart.

„Sie wollen eine gute Jazztrompete? Hier, nehmen Sie doch unsere neue Kirmeströte“

SAP läuft seit Jahren stabil und hochverfügbar auf „großen Eisen“.
Nun bietet IBM an:

„SAP hat jetzt seine eigene Datenbank, ‚HANA‘. Die laßt Ihr, in einer Wirrtualisierungsinstanz, auf unseren Servern laufen. Und zwar nicht unter AIX, das könnte ja unter Umständen die Performanceeinbuße durch die Wirrtualisierung kompensieren, sondern nehmt ein LINUX, und zwar nicht irgendeines, sondern das scheußlichste, war wir auftreiben konnten: ‚SuSE‘, von Experten gern und mit guten Gründen als ‚Nürnberger Windows‘ bezeichnet“.

Blöd bloß: Die Wirrtualisierungsinstanz heißt „Power VM“ und ist nichts anderes als ein „erweitertes“ AIX 6.1, und die Applikationsserver selbst laufen ebenfalls unter AIX.

Da müßte ich ja schön blöd sein, einem Kunden ein solches Kuckucksei ins Nest zu setzen. Zumal bekannt ist: IBM ist nicht gerade sattelfest im Thema „Linux“:

„Crisis? What Crisis?“

In einem leider viel zu kurz geratenen Vortrag erläutert ein Universitätsprofessor, welcher am „Hasso Flachmann – Institut“ lehrt, daß IBMs Linux – Implementation noch lange nicht „fertig“ ist:

  • die „Hardware Management Console“ ist nicht nur ein elender Stromfresser und Produktivitätskiller, sondern „optimiert“ auch ungewollt den Prozessor/Storage – Pool kaputt.
  • Gut, das weiß man als IBMer und kennt auch Methoden, dieses Schandmal zu meiden.
  • Gerade bei vielen Nodes ist die NUMA sehr schlecht implementiert.
  • Ab und zu bleibt auch schon mal das Gesamtsystem unmotiviert stehen.
  • Der „gcc“-Compiler mit dem ppc-backend erzeugt alles andere als optimalen Code. Hier hätte IBM die Chance gehabt, einmal richtig zu helfen. Stattdessen pinselten sie in San Francisco überall „Love, Peace & Linux“ auf die Bürgersteige. Die Stadt war ’not amused‘ und IBM mußte die häßlichen Pinguine wieder entfernen.   Wer’s nicht glaubt:

Der Professor unterdessen wollte gnädig sein und hat auf Benchmarks, die beispielsweise einen prolligen „Dell“ und einen teuren „IBM POWER Server“ unter Linux miteinander vergleichen, verzichtet.

Freimütig konstatierte er jedoch, daß unter AIX sowohl NUMA als auch Compiler und überhaupt das Gesamtsystem aus Scheduler, Device Drivern und Libs perfekt aufeinander abgestimmt seien.

Das entspricht auch meiner „Hands-on Experience“ (es wurde durchweg ‚denglisch‘ gesprochen, einer degenerativen Variante des ‚modern Esperanto‘):
Bei gleichem Workload und vergleichbarer Maschinenleistung erzielt man mit „Linux auf Intel“ 100 %, mit „Linux auf Power“ 75 % und mit „AIX auf Power“ 200 %.

Aber: Der Prof führt sinngemäß aus, „Ja, in den Neunzigern konnte AIX seine Überlegenheit voll ausspielen, aber heute kennt es nur die Generation „50+“. Und außerdem hat es nicht diese vielen tollen „Tools“ aus der „Community“.

An der Pforte hatte ich in der Frühe meinen Morgenstern, das Wurfmesserset sowie die Tüte mit faulen Eiern abgeben müssen, wirklich wirksame Argumente standen mir daher nicht zur Verfügung.

Aber einen Zwischenruf mußte ich dann doch loswerden, „mit den Linux-Tools löst man dann die Probleme, die man unter AIX gar nicht hätte – weil es einfach läuft“.

Denn: Ein Betriebssystem ist für mich eine Infrastruktur – und kein Spielzeug. Mein Job ist es, Ideen auf dieser Plattform umzusetzen – und nicht, daran herumzubasteln.

Aber der Prof und die IBMer befinden:
„Die Welt spricht nun einmal Linux“.

Im Gleichschritt marsch …

Die Krönung setzt ein junger Mann von der „Sedativ GmbH“ auf, der, anstatt für einen Neppshop ein AIX mit einer ordentlichen Datenbank einzusetzen, PostgrSQL unter Linux verwendet. Er erzählt, „wir mußten POWER8 nehmen, denn die kann man auf ‚little endian‘ umstellen.

Auf meine Frage, „Warum nicht ‚big endian‘ , so daß die Lösung auch auf den (massiv im Einsatz befindlichen und immer noch verkauften) POWER7 – Modellen zum Einsatz kommen könnte“, meinte er, „wir wollten das Debian (die Linux-Distribution) nicht neu kompilieren“. Auf meinen Einwand, „die gibt es seit Jahren fix und fertig in der aktuellen Version zum Download“, ließ er dann doch die Katze aus dem Sack:

„Das, was Sie vorschlagen, ist halt ‚the road less taken'“.

Da weiß ich dann nicht, ob ich lachen, laut aufschreien oder heulen soll. Esst Scheiße — zehn Millionen Fliegen können sich nicht irren, oder, in Anlehnung an Robert Long:

Die Server krachen überall
und bald kommt es zum großen Knall,
man müßte schleunigst etwas unternehmen,
sonst werden wir erdrückt von den Problemen.
Doch statt daß die Vernunft regiert
wird fleißig weiter missioniert,
man watschelt gern mit Tux und Gott
zum Abgrund hin im Gänsetrott.
Linus führt, Linus führt,
dahin, wo man selig wird,
Linus führt, Linus führt,
den, dem es gebührt …
Es ist nun einmal, wie es ist,
der Mensch glaubt gerne jeden Mist,
Wer vorher blöd genug für Win,
der macht jetzt „profihaft“ in Lin.

Da nimmt es dann nicht wunder, daß die „Sedativ GmbH“ sich auch beim „Design“ der verkorksten Linux-Lösung für die Stadt München vom Prinzip der ‚road more taken‘ offensichtlich hat leiten lassen — mit dem bekannten Ergebnis.

Das Nachbauen von Microsoft – Strukturen zieht halt Microsoft – Probleme nach sich — damit konnte wirklich niemand rechnen!

Und — zum Thema „Welcher Weg ist meiner?“ hatte Robert Frost eine andere Vorstellung, und zwar schon in den 50er Jahren:

„The Road Not Taken

Two roads diverged in a yellow wood, and I,
I took the one less traveled by,
and that made all the difference.“

Zwischendurch zur Klarstellung:

Niemand will die bahnbrechende Leistung der IBM bei der Entwicklung der POWER – Architektur schmälern, ganz im Gegenteil!
Bloß, um beim Beispiel mit der guten Jazztrompete zu bleiben:
Wenn nur der ‚dumme August‘ hineinbläst, dann kann man auch bei der Kirmeströte aus Plastik bleiben.

Braucht jemand also eine Linux-Serverfarm, dann bestelle er sich ein Rack voller Dell-Pizzaschachteln. Die passen dann auch vom billigen Aussehen her perfekt zu Linux.

In der Welt der Verschwörer

Nun referiert ein Mitarbeiter der Firma Klo Lab.
Was mir gefällt: Die nehmen nicht den bestehenden Systemen die Workloads weg, sondern portieren Anwendungen weg von Windows, und das ist grundsätzlich begrüßenswert.

Aber: Das Produkt ist in Zusammenarbeit mit dem „BSI“ entwickelt worden. Das, was ich von dort mitbekommen mußte, taugte nie etwas.
Dann der Hinweis auf den eingebauten Mailserver der Firma „cyrix“: Den habe ich nicht in stabilster Erinnerung.
Dennoch: Es ist dringend notwendig, die grottenschlechten „Exchange“-„Server“ nachhaltig zu vernichten. Einschließlich des „Office“ – Sondermülls. Da gewinnt ein solches Produkt auf der POWER – Plattform gehörig an Relevanz.

Der Referent ist gut, aber so einige Behauptungen sind lustig:
Bei Intel-Prozessoren gebe es Extra-Instruktionen für „Google“ und die Asozialen-Schlammsuhle „facebook“. Das wäre ja einmal etwas: Wenn, wegen des fehlenden Spezial-Opcodes von INTEL, ich mit einem Power – Rechner nie wieder ein Bild der Visage des Herrn Zuckerberg zu Gesicht bekäme, dann wäre das ein ungeheurer Vorteil.
Auch, wenn der Referent sich alle Mühe gibt, tiefergehende Sachkenntnis zu verbergen: Einen Assembler – Programmierer erkenne ich, wenn ich ihn sehe. Da wäre ganz klar mehr gegangen.
Aber IBM hat für das komplexe Thema gerade einmal 20 (!) Minuten Zeit eingeplant. Ich wollte bei dem gedrängten Programm nicht schon wieder durch Zwischenrufe und Fragen auffällig werden, aber es juckte mir schon in den Fingern, einmal zu fragen, wieso für den Referenten die POWER – Architektur erst jetzt an Relevanz gewinnt. Daß der „x86“ so ziemlich die hinterletzte Küchenschabe ist, wurde von keinem sachkundigen Menschen jemals auch nur diskutiert. Man vergleiche 8080 mit 6502, 80286 mit 68000 und so weiter, und so fort. Im Vergleich zur POWER – Architektur geriert sich Intel wie die elektronische Multimedia-Orgel eines schmierigen Alleinunterhalters neben einem ausgewachsenen Bösendorfer – Flügel. Das muß doch einem denkenden, neugierigen Menschen, der eine schweizerische Hochschule besucht hat, ins Bewußtsein springen?

Im Rahmen des Ultrakurzvortrags habe ich ungefähr 127 Mal die Phrase von der „Freien Software“ gehört, das geht mir seit Jahren auf den Senkel, weil es etwas hat von „Wir sind die Guten“.
„Proprietäre Software“ heißt doch zunächst einmal nichts anderes, daß sich jemand darum kümmert! „Ökosysteme“ sind mir nicht erst seit Claudia Roth verhaßt. Es muß nicht jeder überall dran ‚rumfummeln, ich sage nur „Ralf Seggelmann“, „Telekom“ und „Heartbleed“. Oder darf ich noch auf das desolate Xorg hinweisen?  Früher hatte man gewitzelt, „Ah, it compiles! Let’s ship it!“.
Ein Xorg zerlegt sich schon beim imake.

Trotz aller Meckerei: Mit einer Alternative zur gängigen Kollabierungsware von Microsoft wird man sich auseinandersetzen müssen.

Danach stellen zwei Referenten eine weitere „Lösung“ vor, „Skalix“.

Hier zeigte sich:  Man kann auch noch einen 20-Minuten – Vortrag noch verkürzen, indem man 10 davon mit substanzlosen Unternehmensdarstellungen verplempert.  Da wäre mir ein „gespielter Witz“ lieber gewesen.
Außerdem benutzt das Produkt „JAVA“ und „MySQL“.  Wenn dann noch „PHP“ oder ähnlicher Müll dazukommt, dann muß man aufpassen, daß nicht eine „kritische Masse“ erreicht wird, die dann irgendwann als schmutzige Bombe explodiert.

Der Kracher fehlt …

… und sitzt doch im Plenum. Denn, und da sieht die „Komjunity“ vor lauter „Ökosystem“ die Bäume nicht, ein Computer ist kein Daddelspielzeug, sondern ein Werkzeug, mit dem Menschen ihre Fähigkeiten multiplizieren können.

Anstatt krampfhaft zu versuchen, „Schwerlastverkehr“ mit einem Klapproller zu realisieren, könnte man ja zur Abwechslung ja etwas Produktives tun:
Einen Computer als Anwendungsserver verwenden.
Und dazu bietet „Linux on Power“ ganz hervorragende Möglichkeiten:

Auf einem oder mehreren Servern weden Anwendungen installiert, die dann von hunderten oder tausenden von Anwendern über schlanke, energiesparende „Thin Clients“ genutzt werden können — in atemberaubender Geschwindigkeit.

Gleichzeitig gibt es keinen Streß durch zentrales Updatemanagement und man erreicht hohe Sicherheit — denn der typische Viren-Schadcode ist für die INTEL-Amateurcomputer konzipiert und läuft schlicht nicht auf einer POWER-Architektur.

Tja, und nach dieser Methode hätte man in München die Informationstechnologie auf Vordermann bringen können — anstatt jedem Mitarbeiter so einen lächerlichen PC hinzustellen — der heute buchstäblich zum alten Eisen zählt.

Das alles bekommt man mit „X2go“ hin, aber das Thema schien wohl nicht so interessant zu sein. Am Ende nimmt man dem lieben Wettbewerber HP noch ein paar Großkunden ab. Da richten wir doch lieber unser Kerngeschäft zugrunde und vergraulen unsere Stammkunden mit unausgegorenen Produkten.

Potentiale muß man erkennen …

… insbesondere wenn es um die eigenen geht.

Nachdem die Technologie ja angeblich zur Verfügung steht:

Ersetzt das IBM-Management durch „WATSON“ !

-hb

Hans Bonfigt
Samstag, der 27. August 2016

Am Beispiel eines Pioniers

Heinz Sebiger ist diese Woche verstorben.

1966 gründete er mit vier Kollegen ein genossenschaftlich organisiertes Unternehmen.

Als er nach ziemlich genau 30 Jahren die Leitung der DATEV abgab, war diese das größte gewerbliche Rechenzentrum Europas. Kraft der Gnade der frühen Geburt kann ich aus eigener Erfahrung hinzufügen: Der Erfolg der DATEV gründete sich fast ausschließlich auf der Qualität und Zuverlässigkeit ihrer Leistung.

Die „Frankfurter Allgemeine“ verstieg sich zu der Behauptung, Sebiger habe das „Cloud Computing“ erfunden und markiert damit einen vorläufigen Tiefststand journalistischen Niveaus. Warum plappern junge Leute immer so einen irrelevanten Blödsinn? Und plötzlich wird mir klar:

Sie kennen die Computergeschichte nicht. Ist doch auch nach vollziehbar: Computer wurden seinerzeit als „Arbeitstiere“ genutzt, quasi wie Bagger. Sündhaft teuer, wartungsintensiv, mit wenig Attraktivität für die moderne Bespaßtwerdengesellschaft. Im Gegensatz zum „Porsche“: Vom Konzept her billig, vom Lärm her prollig – und ein absolutes Objekt der Begierde. Die heutigen, peinlichen Daddelkisten sind so sinnvoll wie ein Porsche, die damaligen Computer waren so sinnvoll wie ein Bagger.

Wie jeder Pionier war Heinz Sebiger kein „Innovator“, sondern hat vorhandener Technologie den Weg geebnet.  Denn Fortschritt und Innovation sind heutzutage meist Gegensätze.

Rechenzentren gab es nämlich Mitte der sechziger Jahre viele, hier ein Link zu einem Beitrag über das ZBL-Rechenzentrum in Schwerte:  http://www.lokalkompass.de/schwerte/leute/revolutionaer-der-lochkarte-horst-haake-feiert-heute-seinen-90-geburtstag-d496803.html

Sowohl den Herrn Haake von ZBL als auch Herrn Sebiger kenne ich persönlich — und für beide Unternehmen habe ich Datenerfassungsprogramme und Schnittstellen entwickelt. Vor diesem Hintergrund möge der Leser mir abnehmen: Die Produkte waren ähnlich, die Verfahren waren ähnlich. Horst Haake mußte sein Unternehmen Mitte der achtziger Jahre schließen, während die DATEV den Zenit ihres Erfolges genießen konnte.

Was hatte Sebiger anders gemacht ?

Sebiger war Steuerberater. Als Berufsträger wußte er, worauf es bei Finanzbuchhaltung, Anlagenbuchhaltung und Lohn- und Gehaltsabrechnungen ankommt.  Und er wußte, was die Endkunden, seine Mandanten, von ihm haben wollten.

Er schränkte sein Angebot also sinnvoll auf das für Steuerberater notwendige Portfolio ein und organisierte die DATEV als Genossenschaft. Jeder, der ihre Angebote nutzen wollte, mußte seinen Genossenschaftsanteil leisten – und Berufsträger sein. Ein geniales Konzept, qualifizierte Kunden sorgen für qualifiziertes Feedback. Qualifizierte Kunden aber konnten vor allem die Leistung des Rechenzentrums „an den Mann“, also den Endkunden, bringen. Damit konnte die DATEV die Qualität der Gesamtleistung sicherstellen.

Die heutige „EDV“ ist ja auch deshalb so schlecht beleumundet, weil jeder Einfaltspinsel auch die komplexesten, schlechtesten und wartungsintensivsten Produkte „vertreiben“, installieren und pflegen darf. Über neunzig Prozent derjenigen, die Datenbanken installieren oder warten, wissen nicht, was das ist. Man mache sich einmal den Spaß und frage einen heutigen „Spezialisten“ nach ACID. Sebiger hat, mit seinen vier Gründungsmitgliedern, dafür gesorgt, daß, anstelle von aufgeblasenem „Qualitätsmanagement“, eine Qualitätskette entstand.

Das EVA – Prinzip

Mir liegt das FAZ-Geschwafel vom „Erfinder des Cloud-Computing“ noch gewaltig im Magen, vielleicht sollte ich das Paradigma von Datenverarbeitung beleuchten, wie es in den 60ern verstanden und umgesetzt wurde:  „Erfassung — Verarbeitung — Ausgabe“.  Nehmen wir einmal eine Lohnabrechnung:

Die Sachbearbeiterin sammelte und sortierte die Aufzeichnungen zur Arbeitszeit, typischerweise Stempelkarten, Krankmeldungen usw. usf..  Nun ging sie zu einem Erfassungsgerät, typischerweise einem erweiterten Fernschreiber mit Lochstreifenstanzer, gab einen „Vorlauf“ ein, in dem codiert stand, „Für den Juni 1968 bei der Krummes & Schwarz OHG sind nachfolgende Arbeitszeiten angefallen“, und dann, Zeile für Zeile, Personalnummer, Lohnart und Stundenzahl. Das war die Erfassung.

Die Rolle mit den Daten wurde im DATEV-Rechenzentrum zunächst eingelesen und auf einer Platte geparkt. Denn: Auf den großen IBM/360 lief nur genau ein Programm zur gleichen Zeit (für Fachkundige: Solche Dinge wie TSO lasse ich jetzt einmal weg). Das war wesentlich effizienter, als es in die hohlen Birnen heutiger Informatiker geht. Zwei Programme A und B laufen hintereinander deutlich schneller ab als gleichzeitig. Man baute also Stapel (einen „Batch“) mit Steuerkarten, „Starte das Lohnprogramm, lese den passenden Lochstreifenspool und arbeite jeden Vorlauf ab“. Anhand der Informationen aus dem Vorlauf wurden die korrespondieren Daten von lokalen Platten geholt, die Berechnung und die Druckaufbereitung konnte beginnen. Bereits zu einem sehr frühen Zeitpunkt erfolgte ab hier auch schon eine automatische Übermittlung der Daten an die Kranken Kassen – Kraken in elektronischer Form.

Das Resultat der Verarbeitung war die Ausgabe unter anderem in Form fertiger Lohnabrechnungen, Überweisungsträger für die Banken, Lohnjournale etc.. Die wurden zugeschickt.

Das war „EVA“.  EVA war ein langsames Geschäft, aber:  Sebiger machte wirklich „den Weg frei“: Er trat der Bundespost richtig in den Arsch.

Denn für den Transport der Lochstreifenrollen und den Versand der Auswertungen brauchte die heruntergekommene Schneckenpost gerne auch einmal eine Woche. Und die DATEV organisierte ihren eigenen Kurierdienst und so sparte man effektiv sechs nutzlose Tage pro Lauf ein.

Natürlich: Die Bundesrepublik Deutschland wäre nicht die Bundesrepublik Deutschland, wenn nicht sofort ein Gerichtsverfahren gegen die DATEV losgetreten worden wäre, eines, welches sich über mindestens 5 Jahre hinzog.

Heinz Sebiger aber blieb nicht stehen.

Und während Bundespostminister Kurt Dummle alles tat, um Unternehmenskunden immer weiter finanziell auszubluten und die Nation technisch immer weiter zu isolieren, stellte Sebiger kurzerhand auf Datenfernverarbeitung um.

Einem Verfahren, daß es kraft der Bemühungen der Bundespost eigentlich gar nicht geben konnte. Denn so, wie Hartmut Mehdorn die Bahninfrastruktur systematisch verwahrlost hat, so ließ seinerzeit die Bundespost das Telephonnetz herunterkommen. Sebiger hatte die Lösung und baute bundesweit ein Netz von „DFV-Konzentratoren“ auf.   Der typische Steuerberater verfügte mittlerweile über ein elektronisches Erfassungsterminal, welches die Nutzdaten auf einer Magnetbandkassette speicherte. Die konnte einfach verschickt werden, war vergleichsweise robust und man konnte sie auch einigermaßen schnell einlesen. Die Übertragung ins Nürnberger Rechenzentrum erfolgte über den nächstgelegenen „DFV-Konzentrator“. Dadurch fielen nur Nahbereichstarife an, vor allem aber „packte“ die regionale Verbindung wenigstens noch echte 1.200 Baud, in etwa also 145 Zeichen pro Sekunde.  Statt heute gängigem „DSL 50.000“ gab es damals also „Analog 1,2“.  Aber das Datenformat war intelligent organisiert, verschwuchtelte „XML“-Pappnasen gab es glücklicherweise nicht – und so dauerte ein umfangreicher Datenaustausch etwa eine halbe Stunde. In der Nacht erfolgte die Rückübertragung der Druckdaten – und der Steuerberater, welcher morgens seine Daten eingeschickt hatte, konnte am nächsten Tag seine Auswertungen im eigenen Hause drucken.

Sebiger hatte seine eigene Infrastruktur geschaffen.

Ganz wichtig dabei: Hätte Sebigers DATEV der Politik nicht gezeigt, was alles möglich ist, dann wären wir womöglich technologisch noch mehr Entwicklungsland als jetzt.  Es war nach meinem Empfinden die DATEV, welche den Begriff „Computer“ erst populär machte.

Paradigmenwechsel …

Bereits in den späten Siebzigerjahren erkannte die DATEV, „Die Batchverarbeitung und EVA sind am Ende ihrer Leistungsfähigkeit angelangt“.  Und wieder war es die DATEV, die, zaghaft zwar, über die neuen Möglichkeiten der Datenfernverarbeitung echte Dialoganwendungen anbot.  Als wirkliche Sensation wäre da die „Steuerrechtsdatenbank“ zu nennen, welche eine Volltextsuche in sämtlichen steuerrechtlichen Urteilen, inclusive derer des „Reichsfinanzhofs“, ermöglichte – und damit dem Steuerberater eine wirksame Waffe gegen die umfassenden Bibliotheken des feindlichen Finanzamts in die Hände gab. Wenn ich das persönlich bemerken darf: 1976 saß ich vor einem Terminal dieser Bauart und empfand es, gerade einmal 16jährig, als unvorstellbaren Triumph der Technik, als einer von vielen quasi gleichzeitig mit einem Großrechner zu „sprechen“, welcher im 500 Km entfernten Nürnberg stand.

Der Niedergang

Aus den USENET-Archiven habe ich gerade einen Artikel hervorgekramt, welchen ich vor ziemlich genau 16 Jahren verfaßt habe.  Warum eigentlich kein Vollzitat ?

Die Metastasen des DATEV-Elends
[...] 
So musste ich fruehzeitig Daten erfassen, und zwar zuerst an einer
Olivetti 1731 "Telebanda", einem, vom Antriebsmotor einmal abgesehen,
rein mechanischen Datenerfassungsgeraet. Die Ausgabe erfolgte auf ei-
nem modernen 8-Kanal - Lochstreifen, was gegenueber der Fernschreib-
norm einen gehoerigen Fortschritt darstellte.  Selbst Kleinschreibung
war damals schon moeglich.

Das Datenformat konnte natuerlich vom Rechenzentrum nicht so ohne wei-
teres geaendert werden, weil eine 'Programmaenderung' zwar nicht ge-
rade unmoeglich, aber doch recht aufwendig war.  Deswegen blieben so-
wohl Datenformat als auch die Logik der Erfassungsprogramme bis weit
in die 80er Jahre erhalten, denn so lange akzeptierte die DATEV Loch-
streifen.
Ab 1975 jedoch kamen die elektronischen Geraete in Mode, mein erstes
war eine Olivetti A5, mit Magnetkartenleser, acht freiprogrammier-
baren Lampen zur komfortablen, kontextsensitiven Bedienerfuehrung,
Kugelkopfdrucker und, Revolution, Magnetbandkassette nach ECMA 34 -
Standard.  Zwei KB Hauptspeicher, der Wahnsinn !
Die Aufzeichnungsnorm aenderte sich nie, die Erfassungslogik auch
nicht.  Denn diese Geraete wurden auch mit Lochstreifenstanzer an-
geboten.
1977 bekamen wir unsere KIENZLE 9027-40, mit Magnetbandkassette,
Datenfernuebertragungseinrichtung (BSC), Plasmabildschirm (12 Zeilen
zu je 40 Zeichen), Nadeldrucker sowie zwei 8-Zoll-Diskettenlauf-
werken. Mit seinem 8080 Prozessor und seinen 56 KB RAM war das Ge-
raet enorm leistungsfaehig.  Bis heute hat ein Kunde (Bauunterneh-
men in Oberhausen) dieses Geraet im Einsatz, weil ihm keine andere
Software so viel Komfort beim Verarbeiten seiner 'bergbauspezifi-
schen' Aufmasse biete, angeblich.  Ich sage aber jetzt nicht, wer
die SW geschrieben hat.  Und wieviele Kisten 'Koepi' hierfuer er-
forderlich waren.  Obwohl bereits diese Geraete weitaus leistungs-
faehiger waren als es ein PC jemals faktisch sein wuerde, blieb die
DATEV bei den sehr restriktiven Vorschriften fuer die Erfassungspro-
gramme.  Hintergrund war der, dass nicht einzelne Genossenschafts-
mitglieder wegen ihrer Hardware bevor- oder benachteiligt wuerden.
Immerhin kostete ein solches Geraet damals gut DM 50.000,--, was
heute leicht dem dreifachen entsprechen wuerde. Man wollte halt
nicht seine Mitglieder faktisch zwingen, jedes Jahr einen neuen Ap-
parat kaufen zu muessen.

Ein sehr vernuenftiger, sozialer Gedanke uebrigens, der auch einst
im Internet gepflegt wurde, bis die widerlichen PCPisser mit ihren
Shockflaschdreck dort einfielen wie die Schmeissfliegen.

Irgendwann einmal wurde es unserem lieben Gott zu bunt, und er woll-
te die Menschheit ausrotten.  Nachdem Sintflut und Pest eine Pleite
waren und auch das Aufkommen von Banken und Leasinggesellschaften
nicht das gewuenschte Ergebnis gezeitigt hatte, inspirierte der lie-
be Gott den PC, die uebelste aller Seuchen, die Perversion jeglichen
Ingenieursgeistes, die Brutstaette fuer Hirnfaeule.  Das perfideste
an diesen Apparaten war, dass sie die Hirne junger, unvernuenftiger,
modebewusster, karrieregeiler Jungspunde uebernahmen.

Und so kam es, dass der PC in die Steuerkanzleien einzog, zu ueber-
teuerten Preisen von einigen wenigen Herstellern angeboten, mit ei-
ner Software, die von DATEV angeboten wurde.
Weil die Vollidioten, die diese "Software" zusammenschmierten, keine
Erfahrung hatten und ausserdem nichts als pure Lust am Herumspielen,
sparte man sich ein sinnvolles Konzept und emulierte im Prinzip die
alten, proprietaeteren Erfassungsterminals und damit letzlich die
alten OLIVETTI - Lochstreifenstanzer.

Waehrend man aber mit einer alten Olivetti zuegig arbeiten konnte,
war die Arbeit am komfortablen PC umstaendlich, unergonomisch und
langsam.  Ja, das kann ich beurteilen, denn ich habe an allen bis-
her beschriebenen Systemen produktiv gearbeitet.

Wenn neuere PCs herauskamen, beispielsweise der hirnverbrannte 286er,
so gab es im Magenumdrehen eine neue Software, die den Performance-
gewinn ueberkompensierte.

Dabei wurde nach der "An- und Zubaumethode" gearbeitet:  Ein Pfeif-
chen hier, ein Klingelchen dort.  Vor allen Dingen wurde nie ein al-
ter Zopf abgeschnitten.

Viele Steuerberater wollten irgendwann einmal mehrere Arbeitsplaet-
ze haben, weil die Software so langsam geworden und so umstaendlich
zu bedienen war, dass mindestens drei notwendig wurden:  Zwei, um
das Buchungsvolumen zu bewaeltigen, und einer, an dem 'Spezialisten'
irgendetwas einstellten oder aufspielten.
Und so bot DATEV mit grossem Trara eine "Netzwerkversion" seiner
Weichhirnware an und waehlte, hierzu passend, das schlechteste al-
ler Netzwerkbetruebssysteme aus, das am Markt erhaeltlich war:
NOVELL.  Das sorgte dafuer, dass zwei Dinge regelrecht explodierten:
Zum einen die Anzahl der DATEV - PCs und zum anderen der Software-
umfang, den keiner mehr unter Kontrolle hatte.  Binnen kuerzester
Zeit war ein "486er" conditio sine qua non.

Dann kamen, Metastasen gleich, "Windows" und "Windows for playgroups".
Natuerlich gab es auch hierzu die passende DATEV - Software, denn wo
ein dicker Scheisshaufen liegt, da kackt auch alsbald ein anderer hin.
Weil aber die "Software" mittlerweile derart verbaut war, konnte ei-
ne Umstellung nur fehlschlagen.  So wurde den Genossenschaftsmitglie-
dern bis 1997 fuer teures Geld eine "Windows-Version" angeboten, die
in Wirklichkeit in der MSDOS-Kompatibilitaetsbox lief.  Und, selbst-
verstaendlich, wiederum alle bestehenden PCs zu Sondermuell machte.

Denn jetzt musste es ein schneller "Penzium" sein mit mindestens
64 MB Hauptspeicher.  Und wieder setzte die DATEV auf das mieseste
Trio infernal, was die Menschheit je hervorgebracht hat und auf das
nachfolgende Generationen spucken werden:  SINNLOS 95 als Arbeits-
platz, SINNLOS NT als Netzwerkserver und die PC - Architektur als
gemeinsame Basis.

Ja, so war das.  Und wie es heute ist, das hat Sven E. Lenz ja be-
reits aus seiner taeglichen Praxis beschrieben, ich zitiere noch
einmal:

> Was aber noch viel schlimmer als der Speicherplatz ist, ist die
> Laufzeit. Das ist wirklich unverschämt, was die Datev für den Preis
> abzieht.

Ueber die Zuverlaessigkeit und Administrierbarkeit hat sich Sven
innerhalb dieses Threads ebenfalls geaeussert.

Und meine Prognose ist:  Es wird immer schliemmer werden.  Bis sich
irgendwann einmal jemand durchsetzen kann, den ganzen Dreck in die
Tonne tritt und die PC-Abteilung ausraeuchert.

In Indien sollten ja jetzt Ausbildungsplaetze vakant werden.

Nun gut, es war ein sicherlich nicht immer sachlicher Artikel. Doch in der Rückschau sehe ich zweierlei: Zum einen entspricht die Darstellung in etwa der Wahrheit. Zum anderen habe ich mich geirrt in Bezug darauf, wie schlimm es einmal werden könnte.

Denn seit 1996 war der Lotse Sebiger im mehr als verdienten Ruhestand. Und wer auch immer den Fehler begangen hat: Es wurde ein ehemaliger Mitarbeiter des „Beratungshauses“ Ernst & Young zum Geschäftsführer „berufen“.

Zurück in die Steinzeit – ganz modern

Weil nämlich die DATEV – PC – Ware so grottenschlecht war (erfahrene DATEV-Anwender sehnen sich auch heute noch die alte, „schnelle“ Erfassungssoftware zurück), überlegte man sich „innovativ“:

„Nun haben wir ein erstklassiges Rechenzentrum und eine lausige PC-Abteilung.  Laßt uns mehr Leistung auf die lokalen Arbeitsplätze verlagern, dann brauchen wir das Rechenzentrum nicht mehr.

Dann nämlich hätten wir ein unternehmenseinheitliches Mittelmaß !

Onlinetransaktionen  – wer braucht das schon, wenn der PC alles selber kann ?“

Und man lagerte nicht nur die gesamte Datenverarbeitung, sondern auch deren Speicherung und Archivierung auf die sichere PC-Plattform aus.

Tja – das waren die „neuen Visionäre“, die die Renaissance der „lokalen Intelligenz“ am Arbeitsplatz begrüßten. Vernetzung? Wer braucht das schon. Und ja, es waren die gleichen Junggreise und Trendlemminge, die uns heute glauben machen wollen, man könne nicht mehr ohne LTE-„Handy“ aus dem Haus gehen.

Wie bekloppt dies wirklich ist, fällt eigentlich erst heutzutage auf. Warum muß ich aufwendigst eine komplette Großrechnersoftware auf jeden einzelnen verdammten PC installieren, obwohl eine moderne Rechenanlage leicht 100.000 Lohnabrechnungen pro Sekunde anfertigen kann?

Die DATEV war so blöd. Und selbstverständlich gab es Nachahmer, die noch inkompetenter waren: Das Bundesfinanzministerium mit seinem unsäglich peinlichen ‚ELSTER‘ – Programm zum Beispiel. Es soll auch Firmen geben, die spezielle „APPs“ programmieren, mit der ein armer Student der TU München nachgucken kann, was es in dieser Woche in der Mensa zu essen gibt. Vorausgesetzt natürlich, er besitzt so ein geschmackloses „Eifon“ oder einen häßlichen „Eifon-Klon“ der Machart „Android“.  Alle anderen werden sterben.

Intelligente, vorausschauende Menschen wie Heinz Sebiger haben die menschliche Lebenszeit als hohes Gut geachtet. Denn unsere Lebenszeit ist die einzige Ressource, die uns nicht unendlich zur Verfügung steht. Deswegen hat Sebiger eine Möglichkeit geschaffen, standardisierte Verfahren einmal sauber zu implementieren und Zehntausenden zur Verfügung zu stellen. Das ist ein sozialer Gedanke, der die Arbeitszeit des Menschen und damit den Menschen selbst achtet.

Werden Menschen gezwungen, für nichts und wieder nichts immer neue Programme zu installieren und zu pflegen, wird ihnen diese Lebenszeit abgezogen (ich denke gerade an die ‚grauen Herren‘ von Michael Ende).

Besonders fatal wirkte sich die „Heirat“ der DATEV mit dem schlechtesten, ungeeignetsten und unsicherstem Betriebssystem aus, welches man sich denken kann: „Microsoft Windows“. Es gibt keinen größeren Lebenszeitvernichter als „Microsoft Windows“. Dieser zusammengeschusterte Sondermüll hat weltweit schon bis jetzt mehr Lebenszeit sinnlos vernichtet als alle deutschen Vernichtungslager zusammen. Administration und quälende Langsamkeit infolge von eigentlich unnötigen „Schutzmaßnahmen“ sind die eine Sache. Aber dann kommen die Hypertechnokraten der „DATEV“ und setzen auf den mehrfach ‚aufgebohrten‘ Havaristen noch ihr eigenes „Datev Framework“ obenauf. In den letzten Monaten war ich mehrfach Zeuge von DATEV-Installationen, jeweils durchgeführt von ausgewiesenen Fachleuten. Da ist wirklich nichts, was man nicht mit einem Bulldozer sanieren könnte.

Die Anwender unterdessen klagen über mangelnde Ergonomie, Unterbrechung des Arbeitsflusses durch langsame Software, hohe Komplexität und häfige Abstürze.

Was von den Vätern Du ererbt – erwirb es, um es zu besitzen

Der Tod von Heinz Sebiger macht mich traurig, ich kann mich noch gut an ein zufälliges gemeinsames Mittagessen beim Nürnberger „Behringer“ erinnern:  „Nie die eigene Aufgabe aus den Augen verlieren“.

Und für die DATEV wünsche ich mir eine neue Führung, die das Potential des ursprünglichen DATEV – Modells von Heinz Sebiger begreift und mit aktueller Technologie erneut umsetzt.

Das wäre einmal eine „Digitale Transformation“ nach meinem Geschmack !

-hb

Hans Bonfigt
Sonntag, der 21. August 2016

Ende mit Schrecken

Der Roland, zurecht, sagt ja immer, hier im Blog müsse das Positive überwiegen. Und er hat recht. Deswegen fange ich jetzt einmal mit etwas Positivem an.

Denn es gibt junge Leute, die sich eigenständig etwas erarbeiten, das nicht der Erzielung von Einkünften dient, sondern der Erforschung des Wesens der Dinge. Nehmen wir einmal den Herrn Warkus. Der, im Rahmen seines Philosophiestudiums in Marburg, hat die Arbeiten von C.S. Peirce, den „Digitalfritzen“ unter uns bekannt vom ‚Peirce-Operator‘, fortgeschrieben. Er spricht nicht mit mir, uns trennt ein Marianengraben an Gegensätzen, den man dahingehend abstrahieren kann, daß er Gerechtigkeit als hohes Gut erachtet, ich dagegen Ungerechtigkeit als notwendiges Übel.

Dennoch nehme ich mir die Freiheit, jemanden zu bewundern, der „über die Veränderung in Zeichen“ promoviert wurde. Er stellt das bisherige Paradigma von Veränderung, „eine Eigenschaft ist entfallen oder hinzugekommen“ infrage und kombiniert die Sichtweise von Peirce mit semiotischen Ansätzen: Wahrnehmungen werden von der Realität quasi gespiegelt, zum Beispiel die Farbe an einer Wand. Gleichzeitig werden aber auch Wahrnehmungstäuschungen ‚mitgespiegelt‘, zum Beispiel durch den Farbton der Beleuchtung. Das resultierende Ergebnis wird von uns sogleich perzipiert, quasi einem Bewertungsalgorithmus unterzogen. Interessant wäre es jetzt, zu postulieren, daß Veränderungen (nur) dann existieren, wenn sich die Perzeption ändert. Ganz herunterbanalisiert: „Das Wesen der Dinge ist ihr Schein“.

Das soll natürlich keine Zusammenfassung einer Arbeit sein, für die ein außergewöhnlich intelligenter Mann bestimmt zwei Jahre gebraucht hat. Der Ansatz ist interessant und die Begründung ebenfalls. Der praktische Nutzen dieser Arbeit unterdessen ist – ähm – mäßig.

Der Witz ist bekannt:
Schimpft der Dekan mit dem Leiter seines physikalischen Instituts: „Ja SPINNEN denn Sie? Schon wieder eine Viertelmillion Nachtragshaushalt für den neuen Strömungssimulator??? Wie gehen Sie denn mit dem Geld um? Sehen Sie sich einmal die mathematische Fakultät an: Die brauchen nur Bleistift, Papier und Papierkorb. Und die Philosophen erst: Die brauchen nur Bleistift und Papier!“.

Es wäre ganz schlimm, wenn es nicht Menschen wie den Herrn Warkus gäbe. Aber es gibt eine Menge Dampfplauderer und Möchtegerns, die in allen möglichen „Geisteswissenschaften“ promoviert werden. Da ist ja erstmal nix gegen zu sagen, aber dummerweise wollen die nach der Uni auch Geld verdienen. Möglicherweise sogar mehr als ein „einfacher“ Maurer.

Dann landen sie irgendwo in Unternehmen. Und treffen plötzlich Entscheidungen. Das Dumme ist nur, sie sehen die Welt als ihr kleines Modell, und es braucht auch nicht gegebenenfalls angepaßt werden, denn es muß richtig sein, weil nicht sein kann, was nicht sein darf. Und so werden Entscheidungen nicht semiotisch sondern semi-idiotisch getroffen. Bis zum bitteren Ende.

Eine Groß- und Deutschbank betreibt nicht nur ein eigenes Rechenzentrum. Einer der beiden Server, welche einen Großteil von Deutschlands SEPA-Lastschriften abwickeln, steht „full serviced“ in einem externen Rechenzentrum. So, wie vermögende Leute die Ponys für die Töchter „im Vollberitt“ auf einem Pferdehof vollversorgen lassen, so wird dort der Server mit Daten, Strom und einer Wartungsmannschaft versorgt.

Und weil so viele gebildete Akademiker beteiligt sind, die noch nie so einen Rechner gesehen haben, gibt es definierte Schnittstellen und „SLA“s in hierarchischer Form:

Vertragspartner der Bank ist eine indische Firma. Die hat die Wartung des IBM-Rechners bei Hewlett-Packard in Auftrag gegeben. Hewlett-Packard hat zwar weder Ersatzteile noch Know-How, aber die Inder haben ja ein „SLA“, was kann das schon schiefgehen. Hewlett-Packard vergibt die Wartung weiter, an eine hessische Proletentruppe, die nicht einmal eine Klospülung würde reparieren können. Aber sie können ein „SLA“ schreiben.

Und nun passiert es:
Der seltene Fall tritt ein und der IBM-Mainframe fällt aus. Übrigens wegen einer Bagatelle. Über die „SLA-Kette“ gelangt die Proletentruppe zum Server und muß nun die Anweisungen aus Hinterindien ausführen, mit HP als „Relaisstation“. Der einzige, der Ahnung hat, kommt nicht zur Analyse, geschweige denn zur Entscheidung: Das arme Schwein muß alle 15 Minuten „Reports“ schreiben, und zwar an mehrere Stellen. Wenn er mit einer Welle Reports fertig ist, kann er gleich die nächste beginnen.

In Panik ruft der Chef der Proletentruppe einen IBM-Partner an, jener versucht verzweifelt einen AIX-Experten zu bekommen.

Als allerletzte Option (ich bin nicht bankkompatibel) werden wir involviert, denn schon nach dem dritten Tag kommt einer der Inder auf die Idee, daß es doch ganz schön wäre, wenn jemand dabei wäre, der so ein Ding vielleicht einmal einschalten kann (zugegebenermaßen nicht trivial bei IBM). Während der folgenden vier Tage werden, auf Anweisung aus Indien, die lustigsten Dinge getan, unter anderem wird eine baugleiche Maschine im Nachbarrack aufgebaut. Unser Job: Warten.

Jede mögliche einfache Lösung wurde „von oben“ verhindert.

Jeder noch so abstruse Ansatz wurde stattdessen verfolgt, Geld spielte auf einmal keine Rolle.

Bereitwillig angebotenes Fachwissen von Seiten des Endkunden wurde ignoriert oder zurückgewiesen.

Und so endete ein Einsatz in einer peinlichen Katastrophe:

Jemand bei der Bank, ohne akademische Bildung, aber mit dickem Scheckbuch, rief bei IBM an.  Und weil der Scheck hoch war, ließ sich IBM nicht lange lumpen. Per Anordnung: KONTAKTSPERRE für uns mit dem IBM-Mitarbeiter. Naja, beim Frühstück in der Cafeteria haben wir uns dann doch kurz unterhalten: Ein banaler Ausfall eines VRM im primären CEC, das hätte jeder leicht sehen können, dem erlaubt worden wäre, das Ding aufzuschrauben und nachzugucken. Das passende Ersatzteil kam dann drei Stunden später.

Zwei Tage wurden unterdessen benötigt, das von der Proletentruppe auf Anweisung aus Indien verursachte Schlachtfeld zu beseitigen.

Und nun frage ich mich, was wohl passiert wäre, wenn es den Hauptserver erwischt hätte anstatt wie in unserem Fall den Backup-Server. Höchstwahrscheinlich wären noch mehr Parteien involviert worden, die noch mehr Bullshit verzapft hätten. Und Deutschland wäre zwei Wochen ohne Zahlungsverkehr geblieben.

Irgendein konservativer (eher reaktionärer) Kunde meinte einmal zu mir, „wenn fremde Leute mit fremdem Geld fachfremde Sachen tun, dann kannst Du dein Unternehmen beerdigen“.

Wohl wahr!

-hb

In meinem Unternehmertagebuch #41 habe ich in eine schöne Geschichte erzählt, die ich mal von einer amerikanischen Professorin gehört hatte. Da wurde die Frage beantwortet, warum das British Empire unter Queen Viktoria so einzigartig in Blüte stehen konnte, obwohl die weltweite Kommunikation damals alles andere als einfach war und vor allem sehr lange Zeit benötigte.

Heute möchte ich – auch wieder an einem Beispiel als Metapher – eine andere Frage auf ähnliche Art und Weise beantworten:

Airbus A400M, Schattenrisse, created by Hilbertz, Quelle siehe P.S.

Airbus A400M, Schattenrisse, created by Hilbertz, Quelle siehe P.S.1

Wie kann es sein, dass Airbus mit der Entwicklung von Produkten wie dem A 380 so erfolgreich ist und gleichzeitig mit dem M400 eine Katastrophe zu sein scheint?

A380

Wie so oft erfahren wir ganz einfach alle wichtigen Infos zum A380 in Wikipedia. Ich in in der Tat wirklich beeindruckt, wie gut Airbus das gemacht hat. Einen ganz neuen und außergewöhnlich großen Flieger so präzise zu entwickeln. In ganz anderen Dimensionen vorzustoßen, auch unter Nutzung völlig neuer Materialien.

Die im Projekt aufgetretenen Schwierigkeiten würde ich als normal und im Vergleich mit anderen Großprojekten als absolut unterdurchschnittlich bezeichnen, gerade unter Betrachtung der Verzögerungen bei der Konkurrenz Boeing mit ihrem „dreamliner„.

A400M

Auch über den A400M finden wir alles in Wikipedia. Und seit Jahren erreichen uns schlimme und sehr negative Meldungen zu diesem Projekt. Der schlimmste Zwischenfall dürfte wohl der Absturz eines A400M mit der Fertigungsnummer MSN023 bei seinem ersten Testflug in Spanien am 9. Mai 2015 gewesen sein. Das Projekt A300m scheint dem Außenstehenden total „out of time und budget“. Das ganze scheint so eine richtige „Großprojekt-Katastrophe“ zu sein bzw. noch zu werden.

Jetzt kommt die Frage:

Wie ist es vorstellbar, dass im selben Unternehmen ein Flugzeug so erfolgreich entwickelt wird? Und gleichzeitig die Entwicklung eines anderen so ein extremer Misserfolg wird?

Ich nehme mal an, das die Entwicklung der beiden Flieger zwei unterschiedliche Projekte waren, in denen verschiedene Menschen gearbeitet haben. Und so erscheint mir die Antwort ganz einfach:

Es liegt an den Menschen in den Projekten.

Die Gründe könnten sein:

  • Der A380 war ein ziviles Projekt und wurde
  •  als positive Vision und die große Herausforderung für Airbus kommuniziert.
  • Es stand für Innovation und einer Revolution des Fliegens und wurde
  • zur Metapher für die Zukunft von Airbus.
  • Der A400M war ein Militärflugzeug und
  • in der Wahrnehmung zumindest der Außenstehenden „just another military aircraft“.
  • Dies auch auf jeden Fall in der oberflächlichen Betrachtung basierend auf konservativer Technologie.

Und jetzt frage ich Euch:

Für welches Projekt hättet Ihr Euch entschieden?

P.S.
Alle Artikel meines Unternehmertagebuchs findet man in der Drehscheibe!

P.S.1
Das Bild ist aus Wikipedia. Created by Hilbertz with imaging software in April 2014, veröffentlicht unter CC BY-SA3.0.

Roland Dürre
Freitag, der 11. März 2016

„Inspect-and-A­dapt“ deine Schätzungen!

td-logoIch gehe immer gerne zum TechTalk der Techdivision in München. Das ist eine für mich attraktive Veranstaltung, die mein Freund und PM-Camp-Komplize Sacha Storz organisiert. Der nächste Termin ist am Mittwoch, den 16. März 2016 von 19:00 bis 20:30. Das Ende ist früher als sonst, damit die Besucher die Möglichkeit haben, rechtzeitig zum Bayern-Spiel vor dem Fernseher zu sein. Die Veranstaltung findet in den Räumen der TechDivision in der Balanstr. 73 (Haus 8, 3 OG) in 81541 München statt.

Hier die offizielle Ankündigung:

In der agilen Softwareentwicklungen nehmen Schätzungen von User Stories in der Planung eines Projektes eine zentrale Rolle ein. So führen ungenaue Schätzungen beispielsweise zu Überschreitungen des geplanten Budgets und des angedachten Zeitraums.

In einer Studie bei der TechDivision untersuchten wir die User Story Schätzungen in vier verschiedenen Projekten. Das Ziel dabei: Probleme identifizieren & Verbesserungen einbringen. Ein bekanntes Prinzip – denn schließlich gilt Scrum selber auch als ein „Inspect-and-Adapt“ Framework.

Aber: Wie könnte so etwas in Bezug auf Schätzungen aussehen? Und wie stehen die Ergebnisse der Studie in Bezug zur Diskussion um #NoEstimates?

Ich finde das Thema sehr interessant, bin ich doch ein Anhänger der sicher ein wenig provokanten These „Don’t estimate“ und kann dies auch trefflich begründen. Zusätzlich motiviert mich, dass mein Sohn Rupert der Vortragende ist.

Zum Redner:
imagesRupert Dürre ist als Consultant bei der schwedischen IT-Beratung Netlight tätig. Dabei interessiert er sich für unterschiedliche Bereiche in der agilen Softwareentwicklung vom Requirement Engineering, verschiedenen Entwicklungspraktiken bis hin zu der Fragee, wie man Teams organisieren könnte, um eine effektive Zusammenarbeit zu ermöglichen.

Anmeldung:
Die Veranstaltung ist kostenfrei, um Anmeldung wird gebeten. Hier geht es zur Website der Veranstaltung.

Dann bin ich mal um am nächsten Mittwoch um 19:00 in der Balanstraße und freue mich, wenn ich dort viele Freunde treffe!

RMD

Hans Bonfigt
Montag, der 28. Dezember 2015

Ganz agil vorbei am Ziel

Wenn man vor lauter Meta-Ebenen den Boden der Tatsachen nicht mehr sieht …

Die Spatzen pfeifen es von den Dächern: Nur etwa 20 Prozent aller Softwareprojekte funktionieren so, daß sie die Anforderungen erfüllen. Mit anderen Worten: Die Ausschußquote beträgt 80 Prozent:

  • 20% der Projekte scheitern, weil schlichtweg so falsch geplant wurde, daß sie gar nicht zu realisieren sind
  • 20% scheitern an Kommunikationsproblemen zwischen Auftraggeber und Entwickler
  • 20% werden aufgrund von Selbstüberschätzung der Entwickler nicht fertig und
  • 20% verenden, weil eingebundene Module von Drittanbietern nicht das leisten, was erwartet wurde

Von den verbleibenden 20 Prozent kann man mehr als die Hälfte getrost in die Tonne hauen, weil es entweder an Stabilität oder an Performance mangelt.

Nur in zehn von hundert Fällen liefern Softwarefirmen also das ab, was erwartet wurde – eine erschreckende Bilanz, die noch furchtbarer aussieht, wenn man das Kriterium „Termintreue“ hinzuzieht.

„Da muß doch ‚was zu machen sein“, dachten sich viele Leute, und der Schuldige war ganz schnell ausgemacht:

Der Wasserfall.

„Bitte reinigen Sie mein Auto“, mit diesen Worten übergab ein Firmenchef etwa zweimal im Monat den Mercedes-Schlüssel an seinen Prokuristen. Bevor hier Zweifel entstehen: Diese Abläufe habe ich Ende der 80er Jahre mehrfach persönlich erleben dürfen. Der Prokurist sah das Fahrzeug nach evtl. darin verbliebenen vertraulichen Dokumenten oder kompromittierenden Gegenständen durch und übergab den Auftrag an den Buchhaltungsleiter, der wiederum delegierte an seinen Chefbuchhalter, welcher seinerseits einen Lehrling verdonnerte. Am Samstagmittag reiste zuerst der Buchhalter an, um die Arbeit des Lehrlings zu begutachten, das Fahrzeug auf eventuelle Beschädigungen zu prüfen und danach erforderlichenfalls noch einmal selber Hand anzulegen. Kurze Zeit später holte dann der Buchhaltungsleiter das Gefährt ab, verbrachte es in die Remise des Chefs, wo bereits der Prokurist wartete, um die evtl. entnommenen Gegenstände wieder einzulegen sowie den Schlüssel persönlich an seinen Gebieter zurückzuüberstellen.

Besonders effizient war das sicherlich nicht. Dummerweise jedoch wurden und werden viele Softwareprojekte nach diesem Schema abgewickelt. Denn die Theorie ist äußerst verlockend:

  • „Oben“ gibt es wenige, die den nötigen Überblick  und damit den Kopf frei haben für die wirklich strategischen Entscheidungen
  • „In der Mitte“ können die taktischen Entscheidungen auf mehrere kompetente Spezialisten aufgeteilt werden und
  • „unten“ kann die zeitaufwendige Codierarbeit von vielen, ggfs. austauschbaren Programmierern schnell erledigt werden.

Das hört sich zunächst einmal schlüssig an. Und um es klar zu sagen: So hat das früher auch einmal funktioniert, und zwar erstaunlich gut. Es bleibt aber nichts, wie es war.

Eins vorweg: Eine monokausale Erklärung, warum der „Wasserfall“ nicht mehr so funktioniert wie früher, kann für solch ein komplexes Phänomen niemals ausreichen. Die nachfolgende Polemik, soweit möchte ich mich aber doch vorwagen, „erschlägt“ einen nicht ganz so kleinen Anteil der Fälle.

Der Ärger fing an mit der Verbreitung des PC. Bevor diese scheußlichen Kisten den Massenmarkt überschwemmten, besaßen Unternehmen typischerweise eine einzige Rechenanlage, und die war extrem wichtig. Deswegen wurde diese gehegt und gepflegt, und zwar von einem gut aufeinander abgestimmten, qualifizierten Team. Es dauerte mitunter Jahre, bis ein neuer Mitarbeiter administrative Rechte bekam. Der Beruf des „Admins“ oder des „Programmierers“ war geprägt von Kontemplativität. Die Maschine zeigte einem oft und unnachgiebig die eigenen Fehler und Grenzen auf, andererseits aber forderte sie häufig, daß man ihre eigenen, zumeist durch die Hardware „eisern“ festgelegten Restriktionen mit neuen Verfahren neutralisierte. Dazu mußte man dieses Ding gut kennen. Ein Assemblerlauf dauerte gerne auch einmal 2 1/2 Stunden, Fehler im Quellcode gab es immer und wer da nicht zwischen den Tests im Maschinencode „patchen“ konnte, der assemblierte sich zu Tode. Das galt sinngemäß für „Hochsprachen“, und so war es selbstverständlich, daß man sehr genau wußte, was genau ein Compiler aus einer PERFORM- oder COMPUTE – Anweisung machte. Man war auch gezwungen, sich bei der Lösung eines Teilproblems genau zu überlegen,

  • soll es besonders schnell ausgeführt werden,
  • soll es möglichst wenig Hauptspeicher belegen (ein unwahrscheinlich wichtiges Kriterium seinerzeit) oder
  • soll es möglichst portabel und, fast immer damit einhergehend, selbstdokumentierend sein?

Unterließ man diese Vorüberlegungen, fiel einem schon das Teilproblem fast unweigerlich schmerzhaft auf die Füße.  Manchmal mußte man auch noch sehr „hardwareschonend“ programmieren, beispielsweise ein eigenes Caching implementieren, um Platten-, Disketten- und vor allen Dingen Bandeinheiten vor frühem Verschleiß zu schützen.

Seit langem arbeite ich in einem Unternehmen, welches nicht nur „Computerprogramme“, sondern manchmal auch komplette Anlagensteuerungen beispielsweise zur Polyesterextrusion entwickelt – vom Steuerprogramm selbst bis zu angepaßter Sensorik und Aktuatorik; wenn es irgendwie geht, verdrahte ich auch die Schaltschränke selbst. Typischerweise übernimmt bei größeren Anlagen der Steuerungsbauer auch die Rolle des Anfahrleiters. Bei der Erstinbetriebnahme, wo aufgrund kleinster Fehler ausgesprochen rohe Kräfte sehr sinnlos, dafür aber umso verheerender walten können, muß man sich auf seine Teamgefährten, aber auch auf die eigene Arbeit hundertprozentig verlassen können. Ein einziges verdächtiges Geräusch, rechtzeitig erkannt und richtig interpretiert, kann enormen Schaden verhindern. Dazu braucht man Menschen mit Erfahrung, Sorgfalt, Vorsicht und Demut.

Nun kamen in den 90ern die scheußlichen „PC“s auf den Markt, und urplötzlich war jeder sein eigener Admin und jeder präsentierte stolz irgendeine heimgebackene Detaillösung, die unter bestimmten Umständen sogar dann und wann funktionierte. Es begann eine grauenvolle Zeit der „dezentralen EDV“, in der jeder Mitarbeiter so eine Daddelkiste unter dem Schreibtisch hatte und auch gerne daran herumschraubte. Das „Fachpersonal“ nutzte die neuen, eigentlich bis heute vielfach völlig unnötigen graphischen Fähigkeiten der Geräte für immer albernere Spiele. Das Hauptproblem bei dieser Entwicklung hat mir einmal eine Psychologin erklärt:Wissen Sie, gern läßt sich eine verlassene Frau von einem Verehrer trösten — doch sie wird nie etwas mit diesem anfangen, nach dem Motto, „Wo ich kotze, eß ich nicht“. Es gibt aber nicht nur den Dipol „kotzen – essen“, sondern auch den Dipol „Spiel und Spaß — Arbeit und Verantwortung“

Vielleicht lag es daran: Wirklich ernsthaftes Arbeiten an PCs habe ich nie erlebt. Es hing ja auch keine Verantwortung daran: Wenn so ein Ding abschmierte, dann war der Schaden lokal begrenzt und alsbald festigte sich ein allgemeines Vorurteil, daß Computer nun einmal von Zeit zu Zeit gerne abstürzen – so einfach ist das. Irgendwelche Maschinen wurden auch nicht mit den Büchsen betrieben, also konnte auch niemand zu Schaden kommen.

Wo keine Verantwortung, da auch keine (Selbst-)Disziplin. Dieses Wort wird m.E. viel zu stark verteufelt, indem es in die autoritäre Ecke gedrängt wird. Dabei leitet es sich aus dem lateinischen ‚discipulus‘ ab, übersetzt am besten mit „Schüler“. Disziplin im positiven Sinne heißt Lernwillen, heißt auch, zunächst einmal deskriptiv anstatt normativ zu arbeiten.

In der PC-Szene will aber

  • jeder
  • immer
  • alles
  • sofort

mit „seinem“ Computer machen, und das knallt schon dann, wenn er alleine an seiner Daddelkiste sitzt, denn „machen wollen“ heißt ja noch lange nicht „machen können“. „Niedere“ Arbeiten haßt der Computerbeherrscher, welcher sich gern mit Künstlernamen wie „Merlin“ oder Bezeichnungen wie „Geek“ schmückt, von ganzen Herzen und besteht darauf, diese an die unwürdigen „User“ zu delegieren. Dabei ist gerade die handwerkliche Seite der Softwareentwicklung von größter Bedeutung. Genau so, wie es keine „minderwertigen Menschen“ gibt, gibt es auch keine „minderwertigen Arbeiten“. Richtig verheerend wird es dann, wenn viele Möchtegern-Herrscher, -Künstler und -Genies gemeinsam an einem Projekt arbeiten müssen, womöglich auch noch auf ein- und derselben Kiste.

Lieber Leser, soweit Sie es bis hierhin geschafft haben: Also, wenn Sie mich fragen, dann ist es in einer solchen Konstellation sehr erstaunlich, daß überhaupt fünf bis zehn Prozent brauchbare Produkte aus einer solchen Situation resultieren können.

Und deswegen haben ganz schlaue Menschen das „Projektmanagement“ erfunden, und eine Untergruppe dieser Menschen hat das „Agile Manifesto“ aus der Taufe gehoben:

Individuen und Interaktionen über Prozesse und Werkzeuge
Funktionierende Software über umfassende Dokumentation
Zusammenarbeit mit dem Kunden über Vertragsverhandlung
Reagieren auf Veränderung über Befolgen eines Plans

Hört sich gut an, nicht wahr? Oder sind Sie selber Softwareentwickler und sehen da vier dicke fette Ausreden von cleveren Böcken, die den Gärtner geben wollen?

 

Wie auch immer – irgendwann erwischt es jeden. Und hier mein ungeschminkter Erlebnisbericht „aus der neuen Welt“:

Es ist noch früh, als ich beim Kunden auflaufe, ich bin zum erstenmal dort. Man hat dort Probleme, ein selbstentwickeltes Programm auf die IBM POWER-Architektur zu portieren. Der Kontakt kommt über IBM zustande.

Man geleitet mich in einen größeren Konferenzraum. Dort sitzen schon vier Leute, jeder versteckt sich hinter seinem Rechner, drei „Apple“, ein „Vaio“. Rechts daneben haben alle „Smartphones“ neben sich liegen. Ich sage vernehmlich Guten Morgen, bekomme etwas zurückgenuschelt (der Stuttgarter Einheimischenslang ist schwierig) und setze mich auf einen der freien Plätze. Lege mir Block und Druckbleistift zurecht und prüfe nochmal, ob das Mobiltelephon ausgeschaltet ist.

Die Empfangsdame war ein junger Mann und entsprechend wurde mir kein Kaffee angeboten. Auch keiner der Anwesenden fühlt sich bemüßigt, einem Gast, der etwa 700 Km weit angereist ist, irgendetwas anzubieten. Irgendwann kommt eine junge Frau, welche im bald beginnenden Rollenspiel die „Project Owner“ gibt. Das ist die bedauernswerte Person, die den Ärger mit den Endkunden hat. Nett angezogen, spricht hochdeutsch und war wohl die, die angeregt hat, einen Externen hinzuzuziehen. Das genaue Gegenteil ist die „Scrum Mistress“, die den „Spielablauf“ steuert.

Letztere stellt mich vor, ich sei von außerhalb und könne vielleicht helfen. „Wo haben Sie Ihr Notebook?“ fragt sie mich, worauf ich antworte, „Ich bin zum Arbeiten hier“. Als das kollektive Getipsel abrupt aufhört, wird mir klar, daß von den mittlerweile 12 anwesenden Personen 11 so ein Knaddeldaddel vor sich haben.

„Aber ein Kaffee wäre nicht schlecht“, versuche ich den gelungenen ersten Eindruck noch zu toppen.

Am Klondike

„… dwelt a miner, fourtiy-niner, and his daughter Clementine“: Im Rahmen einer Agilen Retrospektive soll ich Projekt und Status erfassen. Ein mühsames Geschäft: Ich komme mir wirklich vor wie ein mäßig erfolgreicher Goldgräber, der Fakten-Nuggets aus dem Informationsstrom filtert. Zwei anstrengende Stunden brauche ich, um zu erfassen, worum es eigentlich geht:

Gescannte Dokumente (die SCRUM-Drum sagt immer „eingescannte“) sollen aufgrund von darauf befindlichen Barcodes automatisch bestimmten Anwendungen zugeordnet werden, typischerweise den Anwendungen, welche für die Barcodes verantwortlich waren. Auf den ersten Blick hört sich das blödsinnig an, aber in der Praxis ist dies sehr wichtig, weil im täglichen Betrieb sehr viele maschinell erstellten Belege später, teilweise durch Kunden und Partner, modifiziert oder signiert werden. Der Scanner also als „Datenklo“, wo man alle anfallenden Belege ‚reinsteckt nach dem Motto, „den Scheiß bin ich erst mal los“.

Es wird ungefähr 65.536 mal versichert, daß das Datenklo im eigenen Hause prima funktioniere, bloß nicht auf dem bösen Zielrechner des Distributors.

Der Überblick fehlt: Es gibt niemanden, der mir, quasi in Form eines Blockdiagramms, die beteiligten Module auf die Reihe bringen kann.

Wo viele verantwortlich sind, ist es am Ende keiner mehr: Eine Testmaschine im Hause existiert nicht! Mir bleibt der Mund offen stehen (aber nur kurz, danach frage ich zur Sicherheit nach, ob ich mich hier in einer Softwarebude befinde oder bei einem rheinischen Tuntenballett – für letzteres spreche nicht nur die hohe Anzahl an Apple-Geräten). Auch der „PO“ scheint der Umstand, daß man nicht einmal eine Testmaschine vor Ort hat, völlig neu zu sein: Ihr angenehmer Teint bekommt eine Spur Purpur dazu. Die SCRUM – Drummerin dagegen bekommt rote Flecken im Gesicht und meint, das sei genau richtig und beabsichtigt so und außerdem stehe die Inbetriebnahme einer Testmaschine auch in den Anlagen zum „Burn-Down-Chart„.

Studieren geht über Probieren: Auf dem Burnout-Chart kann man sehen, wieviele Aufgaben noch erledigt werden müssen. Dabei hat man das gleiche Problem wie ein Mikroprozessor mit seinem Instruktionsstrom: Wie vielen älteren Menschen bekannt, wird eine Instruktion ja nicht in einem Takt vom Rechner abgearbeitet, sondern durchläuft typischerweise zwischen 16 und 24 „Bearbeitungsstufen“. Wenn die „Pipeline“ erst einmal gefüllt ist, fällt mit jedem Takt eine abgearbeitete Instruktion an (also, jetzt nicht bei Intel und Konsorten, sondern bei ordentlichen Konzepten). Dumm nur: Manchmal gibt es Sprünge innerhalb eines Programmes und dann heißt es für die Pipeline, die bisher linear nachgeladen hatte: „Zurück auf Start, alle Planung war für’n Arsch“. Fast genauso schlimm wirkt sich die sehr häufig vorkommende Situation aus, die entsteht, wenn aufeinanderfolgende Arbeitsschritte voneinander abhängig sind:

Dann muß halt so lange gewartet werden, bis der Vorgänger fertig ist. (Ja, ‚branch prediktion‘ ist mir ebenso bekannt wie ’superpipelining‘, hier geht es ums Prinzip). Mit dem Burnout-Chart wird geplant wie mit einem schlecht konfigurierten SAP-System, indem davon ausgegangen wird, daß alle Arbeitsschritte gleichzeitig und voneinander unabhängig seien. Ein Anstreicher kann aber kein Haus anstreichen, dessen Mauern noch nicht gesetzt sind. Die ganzen Schätzungen fallen wie ein Kartenhaus zusammen, wenn es, wie jetzt, einmal ernsthaft klemmt und keine Auswege da sind. Bevor man detailreich etwas postuliert, heißt es: „Vorher ausprobiert!„.

PPPPPP: Proper Preflight Planning Prevents Poor Performance! Sonst kommt es zu einem Kollaps, den Judith Andreesen gut beschrieben hat, überdies, völlig branchenuntypisch, in einer klaren, angenehmen Sprache: Die Reißleine ziehen. Überhaupt hat sich die Autorin erkennbar viel Mühe mit ihrem Blog gemacht. Korrektur: Nicht erkennbar viel Mühe gemacht. Denn auch das zeichnet einen guten Text aus, daß er nicht nach Fronarbeit riecht, sondern leicht und angenehm daherkommt.

Not my department – oder „Schuld sind die and’ren, stellt mir keine Fragen“: Die PHP – Mannschaft meint, „was kümmert uns ein Architekturproblem, wo doch unsere Sprache genau dazu gemacht ist, um Architekturprobleme zu abstrahieren („und Zombies wie Euch zu generieren“, aber das kann ich gerade noch unterdrücken – in etwa weiß ich schon, wie weit ich zu weit gehen kann. Nicht einmal Rambo kommt ohne fremde Hilfe ans Ziel). Die Webtrottel also lehnen sich zurück und genießen die Show. Das wäre bei uns in der Firma nicht denkbar. Da packt jeder mit an, um Kollegen, denen die Krawatte klemmt, weiterzuhelfen. Nun sitzen wir übrigens schon seit gut drei Stunden zusammen – und keiner raucht! Das irritiert mich jetzt aber schon.

Selber habe ich vor 20 Jahren damit aufgehört, nicht aus prinzipiellen Erwägungen (intelligente Menschen haben sowieso aus Prinzip keine Prinzipien, weil sie sie prinzipiell nicht brauchen. Doch ich wollte einmal im Leben einen Kampf gegen meine eigene Fremdbestimmtheit gewinnen). Aber jetzt vermisse ich den würzigen Duft einer leckeren Zigarette. Man sitzt in einem Boot, gemeinsam raucht man eine Zigarette, die entweder die kreative Lösungsidee bringt oder, wer weiß, als legendäre „letzte Zigarette“ das gemeinsame Ende besiegelt. Da kommen Emotionen auf! Nicht: „Wir schaffen das!“, sondern: „Wir wollen das!“. Ich frage, ob es irgendwo hier einen nahegelegenen Park gibt, damit man sich die Beine vertreten kann und auf andere Gedanken kommt – die gucken mich an, als hätte ich Gruppensex vorgeschlagen.

Niedere Arbeiten – aber doch nicht für einen „Geek“! Einer meiner Mentoren und großen Vorbilder war jahrelang Leiter der Motorenentwicklung bei seinerzeit IHC, heute bekannter unter dem Namen Case. Eine seiner Thesen war, man könne sowieso nur für ganz kurze Zeit eine kreative und konstruktive Arbeit leisten. Weil man aber schlecht 90 Prozent der Arbeitszeit Pause machen kann, nimmt man sich etwas anderes vor. Und merkwürdigerweise, genau bei diesen scheinbar „untergeordneten“ Aufgaben fallen einem die besten Ideen ein – oder, nicht so schön, aber nicht weniger wichtig, man entdeckt in einem winzigen Detail einen kapitalen Showstopper. Ich erinnere mich noch, als wäre es gestern gewesen – wir hatten ein Problem mit der sogenannten Werkzeugsicherung eines Stanzautomaten: Die Steuerung erkannte zu spät, daß ein Werkstück in einem schnellaufenden Folgeverbundwerkzeug klemmte, der Weitertransport sorgte für Überlagerung und das gewaltige polare Massenträgheitsmoment des Schwungrades der Exzenterpresse für einen kapitalen Maschinen- und Werkzeugschaden.

Mein Mentor „verdonnerte“ mich, die Maschine zu reparieren. Allein. Eine Drecksarbeit, nicht ungefährlich noch dazu. Beim Zerlegen der Drehkeilkupplung, welche die kraftschlüssige Verbindung zwischen Exzenter und Schwungrad herstellt, wurde mir klar, daß diese Verbindung bei einfacher Modifikation der Pneumatik auch noch zu einem wesentlich späteren Zeitpunkt getrennt werden konnte. Glücklicherweise hat das Unternehmen, für das ich arbeitete, bis heute noch einen Werkzeugbau und wir fertigten modifizierte Steuerkulissen und andere Komponenten selbst an. Der Leiter des Werkzeugbaus, obwohl kurz vor der Pensionierung, war mit Feuereifer bei der Sache. Nach drei Tagen lief die Maschine wieder und jahrelang gab es keinen Bruch mehr. Mein Mentor sah mich schräg an und meinte, „Das hätten Sie nie hinbekommen, wenn ich Sie nicht genötigt hätte, die Maschine selbst auseinander zunehmen“. Diese Erfahrung ist der Grund dafür, weshalb ich auch heute noch ganz gern das eine oder andere Modul selbst programmiere. Und sehr gerne irgendwelche Dinge zusammenlöte oder -schraube.

Peer Review: Nach einigem Suchen finden wir einige verdächtige „Hilfsprogramme“, welche aus einer Linux-Distribution stammen. Eines ist mir besonders suspekt. In C geschrieben, gespickt mit Abscheulichkeiten. Mein alter Deutschlehrer brachte mir eine interessante Definition nahe, „Kunst ist die konsequente Umsetzung eines Prinzips“. Hier war die Umsetzung so kaputt, daß das Prinzip angegriffen sein mußte. So wurde zum Beispiel abgefragt,

if (3==i) …

Irgendwelche Germanisten und Nichtprogrammierer haben sich das ausgedacht: Weil ausgemachte Anfänger in den ersten Tagen gern eine Wertzuweisung (=) mit einem Vergleichsoperator (==) vertauschen, wird doch allen Ernstes empfohlen, anstatt des lesbaren und unmittelbar verstehbaren ‚if (i==3)‘ so einen Blödsinn zu schreiben wie oben, denn eine Wertzuweisung an eine Konstante legt den Compiler auf die Nase. Der Anfänger ist „geschützt“ und alle Profis müssen sich jahrelang mit unleserlichem Programmkot herumärgern. Das orientiert sich an einer Lehrpädagogik, die an ein Rennrad Hilfsräder anschraubt: „Hier:  Mit unseren Stützrädern kann keiner mehr umfallen!“. Dumm nur: Mit dem Zusatzklapparatismus macht man aus einem einspurigen Fahrzeug ein mehrspuriges. Und wenn sich ein Profi mit dem „Schutz“ einmal sportlich und schnell in eine enge Kurve legt, fliegt er buchstäblich aus der Bahn, weil er seinen Schwerpunkt nicht mehr ins Kurveninnere verlagern kann und landet im Dreck. Ganz abgesehen davon: Wer „sicher“ und „geschützt“ programmieren möchte, der macht das sinnvollerweise nicht in C, sondern beispielsweise in ADA. Die Krönung: Im vorliegenden Fall steckte auch noch ein gehöriger logischer Fehler drin, denn eigentlich gemeint war: ‚if (i >= 3)‘ …

Es geht richtig fies weiter: Nicht nur „RTL – Castings“ sind stockpeinlich, auch bei der C – Programmierung erkennt man leicht den Stümper. Aus schierem Unverständnis heraus, was Indexregister („Pointer“) sind und wie ein C-Compiler sie interpretiert, werden Werte absolut zugewiesen. So was meckert der Compiler zu Recht an. Mit einem „Cast“, dem Elixier der „Aber bei mir funktioniert es doch!“ – Generation, kann man ihn ruhig stellen. So habe ich es gerne: Zwei Zeilen vorher den Sicherheitsfanatiker herauskehren und dann sozusagen den Brandmelder ausschalten.

Die nächsten Zeilen sind ein offener Angriff auf die abendländische Kultur:

for (…) sprintf (buf,string);

Die Standardfehler, zwei fiese, mißbrauchbare Sicherheitslücken, will ich gar nicht diskutieren. Wer „PHP“ einsetzt, der braucht sich um „Security“ keine Gedanken mehr zu machen. Viel schlimmer finde ich, daß

  • es dieser „teuren“ Funktion gar nicht bedurft hätte: Es werden vier konstante Buchstaben übergeben. Die Aufbereitung dieser vier Buchstaben wird an eine extrem mächtige Funktion übergeben, die die übergebene Zeichenkette lexikalisch analysiert.
  • bei „unpassender“ Parametrierung, beispielsweise mit einem Prozentzeichen im Funktionsargument, das Programm im günstigsten Fall undefiniert auf die Nase fällt.
  • bei jedem der extrem häufigen Schleifendurchläufe die „teure“ Aufbereitung erfolgt, obwohl man dies ohne Not außerhalb dieser Schleife hätte tun können.
  • der Rückgabewert der Funktion ignoriert wird. In diesem Falle wäre das o.K. gewesen, aber dann ist man so nett und benutzt tatsächlich einmal einen „Cast“, indem man ein  ‚(void)‘  vor die Funktion schreibt, um den Compliler am Meckern zu hindern („function returns value which is always ignored“) und den Kollegen anzuzeigen, „Hier habe ich bewußt auf eine Prüfung verzichtet“.

Das Allerschlimmste aber: Die Art und Weise, wie innerhalb der (in der Realität deutlich größeren) Schleife Daten übergeben und in eine Datei geschrieben werden, macht die Portabilität des Codes in Bezug auf die sogenannte Endianness kaputt. Die aufgebohrten „386er“ PC-Prozessoren sind typischerweise „Little Endian“, Mama Blue baut typischerweise „Big Endian“. In der Ausgabe landet jetzt nicht, wie beabsichtigt, „Y800“, sondern „008Y“.

Ich erläutere meinen Verdacht und ernte: Achselzucken. Denn die einzige im Raum, die die Erläuterung kapiert, ist die „nichttechnische“ Project Owneress. Später erfahre ich, daß sie gelernte Floristin ist. Was ich immer sage, „Informatiker meiden!“.

Crisis ?  What Crisis ?

Die Masteress geht jetzt mit SCRUM — vielfach ums Problem herum:

Es wird diskutiert, ob man einen laufenden „Sprint“ abbrechen sollte, um einen neuen zu beginnen, natürlich nicht ohne „Review„. Hat die noch alle Latten am Zaun? Das erste, was man jetzt vielleicht tun sollte, frei nach dem agilen Motto, „Individuen und Interaktionen über Prozesse und Werkzeuge“: Programmkorrektur, Kurztest auf im Hause vorhandener Intel-Spielarchitektur, Testrelease auf einen richtigen Computer packen (und zwar nicht auf die Endkundenmaschine, um diesen nicht weiter zu inkommodieren), dort nochmaliger Test.

Aber weit gefehlt: „Das paßt nicht in unser Tooling„.

Bei uns in der Firma sind wir ja der Meinung, daß man nur das verantwortlich einem Kunden empfehlen kann, was man selber im Einsatz hat, insofern haben wir natürlich auch zwei IBM POWER – Maschinen am Start und im Gegensatz zur INTEL-Welt gibt es dafür auch eine brauchbare Virtualisierungsplattform – ich könnte also innerhalb von kürzester Zeit eine Testumgebung bauen.

Nur leider: „Das ist in unseren Prozessen nicht vorgesehen“.

 

Wenn’s am schönsten ist, Freunde …

… dann muß man halt gehen. Das ist nicht mehr meine Welt. Ich erkenne schlagartig, daß wir „Informationstechniker“ längst zu dem geworden sind, was wir verachtet und bekämpft haben:  Wir sind die neuen Bürokraten. Bleistiftspitzer. Bürohengste. Tintenpisser. Anstatt unseren Job zu machen, „Verwaltung von Information“, beschäftigen wir uns längst fast ausschließlich mit der Verwaltung der Verwaltung. Die eigentlichen Probleme sind ganz weit weg.

Mir fällt noch eine prima Verbalinjurie für die Mannschaft ein, aber irgendwie bin ich gerade zu traurig, um sie auszukippen. Ich bedaure also, unter den gegebenen Umständen nicht die Hilfe gewesen zu sein, die man sich erhofft habe, aber die neue Welt würde mich überfordern – ich käme mir vor wie der „Ich“ – Erzähler in Umberto Ecos spannendem Krimi „Der Name der Rose“:  „sic stat printine nomine rosa, nomina nuda tenemus“.

 

Epilog

Schon drei Tage später bekommen wir Bescheid von der „PO“: Ja, man hat den Fehler bestätigen können. Er wird aber nicht behoben, sondern man hat im „sprint review“ nach langer Diskussion vereinbart, daß der Kunde seine „offensichtlich unzulängliche“ POWER – Maschine von „Big Endian“ auf „Little Endian“ umstellen muß. Denn, so hat man bei IBM erklärt, mit der neuen Generation der POWER-Maschinen könne man das einstellen und außerdem gäbe es da ein passendes „UBUNTU“ …

 

Fazit

  1. Wasserfälle sind wunderschön.
  2. Zwei Dinge sind aktueller als jemals zuvor:  Brechts „Anachronistischer Zug“ und, hier einschlägiger als man es sich wünscht: »Jeder Zuwachs an Technik bedingt, wenn damit ein Zuwachs des menschlichen Glücks verbunden sein soll, einen entsprechenden Zuwachs an Weisheit.«
  3. Endlich tut sich mir schemenhaft ein Erklärungsansatz für die epochemachenden Glanzleistungen der T-Systems auf.

Und ansonsten halte ich mich bei der Softwareentwicklung zukünftig wieder an eine Empfehlung von Eberhard v. Kuenheim:

„In großer Höhe fliegt der Adler besser allein“.

hb