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.

 

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

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.

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

craftsmanshipIn 2013 hatten wir bei der InterFace AG ein schönes „Fachliches IF-Forum“. Es ging um „Software Craftsmanship“. Wir hatten tolle Gäste und starke Referenten. Die Diskussion drehte sich um Fragen wie: Wie kommt man also zur Meisterschaft, wie gewinnt man die dafür notwendige Erfahrung? Wie entsteht die Motivation zu Perfektion? Wie schafft man Spitzenleistung und Qualität in Teams am besten?

Eine Aussage ist in diesem Workshop ist bei mir besonders hängen geblieben. Bernhard Findeiss berichtete damals (vielleicht auch ein wenig als Provokation gedacht), dass ein guter „Craftsman“, der es in seinem Handwerk zur Meisterschaft bringen will,  in der Woche bis zu 20 Stunden  für Weiterbildung aufwenden muss. Und dass dies in der Regel nicht in der Arbeitszeit geht, sondern zu einem oft nicht unwesentlichem Teil die Freizeit dafür herhalten muss.

Die Zahl hat mich zuerst überrascht. Ich musste daran denken, wie viele Menschen ihr Leben streng in Freizeit und Arbeit einteilen. Und habe mich an manche Diskussion mit Kollegen erinnert. Zum Beispiel wie viel Prozent der Weiterbildung denn als Arbeitszeit kontiert werden dürfen. So habe ich die letzten zwei Jahre viel über dieses Thema nachgedacht. Auf der einen Seite sind 20 Stunden pro Woche Üben und Lernen notwendig, will man es zur Meisterschaft bringen.

Dem stimme ich zu. Auf der anderen Seite braucht man noch viel Zeit, um für den Erfolg zu arbeiten. Und für Familie und Privates soll auch genug Zeit bleiben. Und ich meine es geht. Viele meiner Freunde – Fachleute, Manager und Unternehmer, männlich wie weiblich – leben und lieben ihren Job. Sie sind wirkliche „Meister“ und beschäftigen sich eigentlich immer mit den ihnen wichtigen Themen. Und sind trotzdem gute Ehepartner und Mütter wie Väter.

Ich bin jetzt in „Rente“. Und lerne und übe immer noch 20 Stunden. Nur ob ich ein Meister bin, da habe ich Zweifel. Aber ich werde weiter üben …

RMD

P.S.
Hier geht es zu den Videos vom IF-Forum Craftsmanship„.

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

Roland Dürre
Dienstag, der 3. Februar 2015

agile.ruhr Camp 2015

Vor kurzem habe ich mit Dominik Rose telefoniert. Da hat er mir berichtet, dass der Termin des von ihm gemeinsam mit Berthold Barth organisierten agile.ruhr Camp 2015 jetzt langsam näher rückt. Schon in weniger als drei Wochen ist es soweit!

„Agile“, das passt mir gut, denn meine Überzeugung ist ja, dass man alles wichtige immer „ALO“ angehen sollte. Wobei ALO als Abkürzung steht für Agile, Lean und Open.

agile-camp-ruhr-595x114

So freue ich mich, dass das Organisationsteam des agile.ruhr Camp in diesem Jahr erstmals zu einer „Unkonferenz“ für agiles Vorgehen im Projektumfeld und bei der Entwicklung von Software einlädt. Am 21. + 22. Februar 2015 ist es so weit, da findet das barcamp im Unperfekthaus in Essen statt.

Dass die InterFace AG mit von der Partie ist und das Orgateam als Sponsor unterstützt finde ich natürlich ganz besonders toll.

Das agile.ruhr Camp steht für Veränderung und Überzeugung. Ziel der Veranstaltung ist Menschen, Organisationen und Unternehmen eine moderne Plattform anzubieten, zum Teilen von Erfahrung und Wissen. Denn Wissen ist der einzige Rohstoff, der durch teilen mehr wird.

Wie kann man erfolgreich agile Methoden und Werkzeuge nutzen? Was wird durch agiles Bewusstsein und Handeln alles möglich? Wie schaffen wir die notwendige Veränderung? Und dies eben nicht nur bei der Entwicklung von Software!

Und natürlich bietet sich als der klassische Rahmen für eine freie Unkonferenz zu Agilität das Format „barcamp“ an, bei dem ganz bewusst im Gegensatz zur klassischen Konferenz auf eine einengende Agenda verzichtet wird und der redliche Diskurs im offenen Dialog überdurchschnittlichen Erkenntnisgewinn generiert.

Die Tagesordnung wird von den Besuchern festgelegt. Man duzt sich, Augenhöhe ist angesagt und Zuhören ist wichtiger als sprechen. Nur so werden können Teilhabe „ihre“ Sessions (zu einem Themenkomplex ihrer Wahl) anbieten und werden zu „Teilhabern“.

Leider kann ich persönlich am 13./14. Februar nicht dabei sein, da ich genau an den beiden Tagen bei einer ganz anderen „Unkonferenz“ sein möchte, bei der ich schon seit ein paar Jahren Stammgast bin – der „Biike“ in Westerland auf Sylt. Die „Biike“ ist nur ein Brauchtum, den Termin habe gute Freunde für ihre Nicht-Konferenz genutzt.
🙂 Das Leben ist eine Aneinanderreihung von verpassten Gelegenheiten.

Aber vielleicht kann ja der eine oder andere IF-Blog-Leser an meiner Stelle an diesem einzigartigen agile.ruhr Camp teilnehmen. Und dann in seinem Blog oder über Twitter darüber berichten.

RMD

P.S.
Wenn ich den Hashtag vom agile.ruhr Camp 2015 weiß, dann trage ich ihn hier nach.
Mein Vorschlag: #AgileRuhrCmp

P.S.1
In diesem Kontext etwas Lesenswertes zur InterFace AG.

Gerade habe ich mir ein wenig die Hintergründe zum SSL/TLS-Bug durchgelesen, der Apple diese Woche ereilt hat.

Wer grad nicht weiß, wovon ich spreche, hier ein paar Links:

Heise.de: „Ein Sicherheitsdesaster“: Hintergründe zu Apples schwerwiegendem SSL-Problem
Golem.de: iOS erhält SSL-Bugfix, OS X bald auch
Spiegel.de: Sicherheitslücke: Apples furchtbarer Fehler

Interessant dabei ist, daß dieser Bug nur auf eine einzige Code-Zeile hinausläuft. Er wäre einfach zu verhindern gewesen, hätte man die grundlegenden Regeln von „Clean Code“ befolgt.

Hier der Code-Auszug, der den Fehler beinhaltet. Ich habe ihn von Apple selbst, da der entsprechende Code unter einer OpenSource-Lizenz steht (siehe hier).

hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
goto fail;


if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;

Warum ist nun aber genau dieser Code problematisch?

Schon gesehen?

Ich gebe zu, auch bei mir hat es ein wenig gedauert. Ich versuche es mal zu erklären:

Normalerweise ist es in der Programmiersprache C (in der dieser Code geschrieben ist) der Brauch, Anweisungen nach einem „If“-Statement in geschweifte Klammern zu setzen. In etwa so:

if (bedingung) {
Anweisung 1;
Anweisung 2;
Anweisung 3;
...
}

Es gibt jedoch die Möglichkeit, auf die geschweifte Klammer zu verzichten, wenn hinter der Bedingung nur eine einzige Anweisung folgt.

Also so:

if (bedingung)
Anweisung 1;

In diesem, zweiten Stil, sind auch alle „If“-Statements aus dem Code-Auszug von Apple geschrieben. Der Programmierer wollte sich so wohl einige Zeichen Tip-Arbeit sparen. Dummerweise hat sich aber nun ein kleiner Fehler eingeschlichen: Nach dem rot markierten If-Statement steht nicht eine, sondern 2 Anweisungen.

Was passiert nun in so einem Fall?

Nun, der Compiler wertet die Regel strikt aus: Steht hinter einem If-Statement keine Klammer, so folgt genau 1 Anweisung: Die erste Anweisung (in diesem Fall „goto fail;“) gehört also noch zum If-Statement. Die zweite Anweisung gehört für den Compiler jedoch nicht mehr zum If-Statement. Sie wird daher in jedem Fall ausgeführt. Ganz so, als sähe der Quellcode so aus:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;

goto fail;

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;

Das zweite „goto fail;“ wird daher in jedem Fall ausgeführt, und damit die Textmarke „fail“ bereits angesprungen, bevor das letzte, blau hinterlegte if-Statement ausgeführt werden kann.

Was hat das nun aber mit Clean Code zu tun?

Aus meiner Sicht ist es kein guter Stil, in if-Statements auf die geschweifte Klammern zu verzichten. Zu welch schwerwiegenden Problemen das führen kann, sieht man z.B. genau mit diesem Beispiel hier. Besser ist es, man verwendet geschweifte Klammern, dann ist es auch eindeutig, was ausgeführt wird und was nicht. Wahrscheinlich hätte hier dann sogar der Compiler davor gewarnt, dass das zweite „goto fail;“ nicht erreicht werden kann („Dead Code“), und damit überflüssig ist.

So jedoch hatte der Compiler keine Chance. Auch die ganzen Tools zur statischen Quellcodeanalyse, die Apple sicherlich im Hintergrund anwendet, laufen hier ins Leere. Und die Wahrscheinlichkeit, daß ein anderer Programmierer das zufällig entdeckt, wenn er drüberschaut, ist ebenfalls nicht allzu hoch: Der Fehler ist gut versteckt. Man muß schon mehrmals hinsehen, um ihn zu entdecken.

Was kann man nun dagegen machen?

Die einfachste Methode ist es, sich solche „besseren“ Schreibweisen gar nicht erst anzugewöhnen, sondern beim Standard zu bleiben. Die meisten IDEs bieten dafür sogar Regeln an, die man hinterlegen kann. Dadurch werden entsprechende Code-Stellen als Warnung oder sogar als Fehler hinterlegt. Rutscht doch einmal eins durch, so wird es bei der automatischen Code-Formatierung (dessen Tastenkombination man während der Entwicklung ständig drückt) wieder in die Standard-Schreibweise aufgelöst.

Es ist eine gute Idee, einmal einen kompletten Satz solcher Code-Formatierungsregeln zu definieren, und dann anschliessend an alle Teammitglieder zu verteilen.

Man kann dies sogar so einstellen, daß es automatisch an alle verteilt wird, die das Projekt aus dem Versionsverwaltungssystem auschecken. Z.B. indem man etwa projektspezifische Regeln anlegt, und diese in ein Verzeichnis innerhalb des Projekts legt.

Sollten Sie das bisher noch nicht gemacht haben, so ist es eine gute Idee, nun damit anzufangen.

Ich kann mir vorstellen, bei Apple sind sie gerade voll dabei  😎

bfi

Roland Dürre
Sonntag, der 26. Januar 2014

Interview für die DOAG

„Da findet eine Evolution statt, die kaum vorhersehbar ist …“

Die Informationstechnologie entwickelt sich schneller als je zuvor. Dr. Dietmar Neugebauer, Vorstandsvorsitzender der DOAG, und Wolfgang Taschner, Chefredakteur der DOAG News, sprachen darüber mit Roland M. Dürre, Vorsitzendem des Vorstands der Interface AG, also mit mir :-). Das ganze anlässlich der großen DOAG-Konferenz 2013 in Nürnberg.

Sie haben die Interface AG gegründet. Was ist deren Geschäftsmodell?
Gestartet im Jahr 1984 als Produkt-Unternehmen sind wir mit der professionellen Textverarbeitungs-Software HIT/CLOU innerhalb weniger Jahre zum europäischen Markführer auf UNIX-Systemen aller Hersteller geworden. Um die Jahrtausend-Wende haben wir uns zum IT-basierten und Branchen-neutralen Dienstleistungs- und Beratungsunternehmen gewandelt. HIT war das UNIX-Textsystem, CLOU die ergänzende 4GL-Maschine für Textgenerierung. Schon in den ersten CLOU-Versionen gab es die Möglichkeit, SQL-Scripten einzubetten, so dass der Textautomat aus der zugewiesenen Datenbank qualifiziert lesen und bei Bedarf auch in sie schreiben konnte. In vielen Einsätzen war dies die Oracle-Datenbank.

Neben der Interface AG gibt es unter dem Dach der IF-Group noch weitere Unternehmen. Was machen diese?
Unsere Tochter-Unternehmen sind spezialisiert auf Dienstleistung im Umfeld besonderer Hersteller-Technologien wie Microsoft oder allgemeiner IT-Technologien wie Virtualisierung. Ein Unternehmen fällt aus der Rolle, es ist die IF-Localization, die Übersetzungen in alle Sprachen organisiert und interkulturelle Anpassungen durchführt.

In welchem Rahmen setzen Sie bei Ihren Kunden Produkte der Firma Oracle ein?
Fast alle unsere Kunden setzen in den geschäftskritischen Prozessen die Oracle-Datenbanken ein. Diese Datenbanken sind die Basis für IT-Anwendungen aller Art.

In welchem Bereich sehen Sie die Stärken der Oracle-Produkte, wo die Schwächen?
Mein Eindruck ist, dass die Oracle-Produkte in der Regel immer sehr gut im Wettbewerb abschneiden. Bedauerlich ist aus meiner Sicht eher, dass es gerade im Middleware-Bereich keine Übersicht über die Vielfalt der Produkte gibt. Da ist noch viel Platz für Oracle nach oben.

Wie beurteilen Sie generell die Produkt-Strategie von Oracle?
Es steht mir nicht an, die Produkt-Strategie von Oracle zu bewerten. Zumal ich gar nicht in der Lage bin, die Vielfalt ganz zu überschauen. Vielleicht wäre da eine Produkt-Landkarte sinnvoll, die alle Produkte und ihre Möglichkeiten beschreibt.

Würden Sie Ihren Kunden empfehlen, ein Komplettsystem von der Hardware bis zu den Applikationen von einem einzigen Hersteller wie Oracle einzusetzen?
Warum sollte ich nicht? Ich bin schließlich ein alter Fan von Sun-Systemen. Aber im Ernst, eine integrierte und abgestimmte Architektur hat viele Vorteile, die sich wahrscheinlich auch rechnen. Eine Abhängigkeit vom Hersteller besteht ja immer, ganz gleich ob der Anbieter Microsoft, IBM, SAP oder Oracle oder anders heißt.

Was hat Sie damals an Sun so beeindruckt?
Wir waren ja eine UNIX-Firma und ich war mir damals (fälschlicherweise) ziemlich sicher, dass Windows keine Chance im professionellen Einsatz hat. Da habe ich mich freilich gründlich geirrt. Sun war damals neu  und modern – in der grafischen Oberfläche der Sun-Workstations sah ich eine große Zukunft. Zudem waren mir die damaligen Sun-Mitarbeiter auf ihren Veranstaltungen sehr sympathisch.

Was ist Ihnen durch den Kopf gegangen, als Oracle Sun übernommen hat?
Einerseits war ich entsetzt, andererseits hatte ich die Hoffnung, dass diese Akquisition eine große Chance ist. Die große Performance der Oracle Engineered Systems sind ein gutes Beispiel dafür.

Die Interface AG setzt stark auf soziale Medien. Welche Erfahrungen haben Sie damit gemacht?
Persönlich nur die besten. Allerdings ist es nicht immer einfach, die Menschen und auch zentrale Abteilungen zum Mitmachen zu bewegen. Witzigerweise erfahre ich oft aus Facebook, Google+ oder Twitter, was unsere Mitarbeiter gerade so machen, auch dienstlich.

Welche Vorteile sehen Sie im Einsatz der sozialen Medien im Unternehmen?
Ich betrachte das heute als ein unbedingtes Muss. Das Management hat sich über die Jahre verändert, an die Stelle des hierarchisch aufgebauten Systems gibt es heute eine vernetzte Struktur. Bei größeren zusammenarbeitenden Gruppen sind deshalb moderne Hilfsmittel erforderlich, um beispielsweise die zahllosen Besprechungen zu vermeiden. Entscheidend ist jedoch, alle Team-Mitglieder von den Vorteilen der sozialen Medien zu überzeugen.

In welche Richtung wird sich die IT in den kommenden Jahren entwickeln?
🙂 Wenn ich das wüsste, würde ich nicht hier sitzen, sondern auf einer schönen Yacht in der Karibik und einem Glas Champagner in der Hand. Seriös: ich gehe davon aus, dass die IT ihren Weg und dies sehr schnell gehen wird. Da findet eine Evolution statt, die kaum vorhersehbar oder gar bestimmbar ist. Ich gehe aber davon aus, dass die großen Impulse nicht mehr aus Europa und auch nicht mehr so stark wie bisher aus den USA kommen werden, sondern aus Asien. In der Pionierzeit von Unix war der große Nachteil für uns deutsche Anbieter, dass der deutsche Markt so viel kleiner als der Englisch-sprechende war. Heute bestimmen China und auch immer mehr Indien, wo es lang geht.

Was erwarten Sie dabei von einem IT-Unternehmen wie Oracle?
Die Kunst wäre, die richtige Mischung und/oder Gewichtung zwischen „open“ und „proprietär“ zu schaffen. Die Märkte in der IT wandeln sich schnell und sind nicht mehr von einem Unternehmen alleine beherrschbar. So sind technologische Offenheit und strategische Transparenz wünschenswert und bestimmt langfristig auch nützlich für IT-Unternehmen.

Wie sehen Sie den Stellenwert einer Anwendergruppe wie der DOAG?
Ich habe ja eigene Siemens-Erfahrungen, als Mitarbeiter wie als Lieferant. Bei Siemens gab es die Siemens Anwender-Vereinigung. Ich war immer beeindruckt, wie dadurch sehr konstruktive Beziehungen gerade mit Großkunden und Lieferant möglich waren und welcher Nutzen für beide Seiten entstanden ist.

Welche Erfahrungen aus Ihrem langen Berufsleben können Sie an andere Unternehmer weitergeben?
Vielleicht die wichtigste: Immer fähig sein, sich ein eigenes Urteil zu bilden. Und agil bleiben und dogmatische Entscheidungen und Handlungen um alles in der Welt verhindern. Ansonsten versuche ich die Regeln für modernes Management von Hans Ulrich, dem Erfinder des St. Gallener Management Modells zu beherzigen. Diese sind: Die Unvorsehbarkeit von Zukunft als Normalzustand zu akzeptieren, die Grenzen des Denkens weiter stecken, sich besser vom „sowohl als auch” als vom „entweder oder” leiten zu lassen, mehrdimensional zu denken, Selbstorganisation und Selbstlenkung als Gestaltungsmodell zu begreifen, Managen als sinngebende und sinnvermittelnde Funkton aufzufassen, sich auf das Wesentliche zu konzentrieren und Gruppendynamik auszunutzen. Beachtenswert, dass diese Regeln aus den 1980ger Jahren stammen.

Das Interview ist mittlerweile bei DOAG veröffentlicht – so poste ich es auch mal hier.

RMD

Diese Woche ist es wieder soweit: Am 19. September 2013 um 18:00 findet in Rahmen unserer “IF-Akademie” bei der InterFace AG wieder ein spannendes IF-Forum mit einem aufregenden Vortrag statt. Diesmal ist das Thema

Mailserver & Mail-Client (Vorsicht E-MAIL!)
“Geschichte, Grundlagen, Spam&Viren” oder “Konzepte für den sicheren und zuverlässigen Betrieb eines eigenen Mailservers”
(Hans Bonfigt / Marc Haber – redoxSystems)

Und es gibt eine gute Nachricht:

HaberMarcII200911-Heidelfoto-A-orig-IMG_4678plus_v2Marc Haber kommt auch.

Mittlerweile ist sichergestellt, dass neben Hans Bonfigt auch Marc Haber anwesend sein wird. Die beiden kennen sich mit der Technik und den Abgründen unseres so viel benutzten Mediums E-Mail perfekt aus. Wir haben diesmal so zwei „Hochkaräter“ zu Gast, die höchst kompetente aber auch radikal kritische Fachleute „vom alten Schlage“ sind. Beide verfügen über die Gabe, auch komplexe Themen einfach zu erklären. Sie sind mir persönlich bekannt und werden im Ko-Referat Erstaunliches berichten.

So werden sie schlüssig ableiten, dass ein Unternehmen um den Betrieb eines eigenen Mailservers einfach nicht herumkommt. Sie werden zeigen, wie erstaunlich einfach dieser einzurichten ist und wie erstaunlich günstig das mit Freier Software funktioniert. Gleichzeitig werden die Referenten, quasi „aus erster Hand“, einmal von den ganz „alltäglichen“ „SINA-Boxen“ erzählen, mit denen tagtäglich Grundrechte verletzt werden können, ohne dass man auch nur die geringste Chance hätte, dies überhaupt zu bemerken.

Weil das Thema zurzeit ja höchst aktuell ist, haben wir den Vortrag im Rahmen der IF-Akademie zu einem fachlichen „Sonder-IF-Forum“ aufgewertet. Der Donnerstag Abend ist so für uns wieder eine sehr gute Gelegenheit, die InterFace AG unseren Freunden, Partnern, Kunden, sprich interessierten Menschen aber auch neuen Kollegen vorzustellen.

So bitte ich Euch alle, uns zu unterstützen, um aus IF-Forum eine lebendige Veranstaltung zu machen. Auch über kurzfristige Teilnehmer und „Spontan-Besucher“ freue ich mich.

Hier der LINK zu den Details und zur Anmeldung!

Ich freue mich auf zahlreiche Besucher!

RMD