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

4 Kommentare zu “Ganz agil vorbei am Ziel”

  1. Rabba (Montag, der 28. Dezember 2015)

    Herzlichen Glückwunsch zu diesem Beitrag.
    Hans Bonfigt muss in der Nähe meines Jahrgangs liegen, denn später hat niemand mehr Probleme allein lösen müssen, so wie er an der Presse.
    Tragikomisch die Beschreibung des Teams und der Atmosphäre in der Besprechung, die mich beklemmend an meine Umgebung in unserer Zentrale erinnert. Dort wird auch nicht mehr versucht, wie am Beispiel des Stanzautomaten, dem Problem zunächst einmal selbst auf den Grund zu gehen, sondern man reklamiert beim Hersteller oder holt sich einen Experten.
    Köstlich die Beschreibung des vermanschten Wortschatzes aus englischen Begriffen und deutschen Interpretationen. Ich glaube, dass viele glauben, wenn sie die Ausdrücke beherrschen und entsprechend in den Diskussionen einsetzen, auch damit an Kompetenz gewonnen zu haben.
    Zusammengefasst ist der Artikel eine gute Beschreibung der traurigen Arbeitswelt.
    Ich hoffe, dass der Autor sein Wissen und vor allem Erfahrung breiter streut, als nur in diesem kleinen aber feinen Blog.
    Klaus Rabba

  2. Hans Bonfigt (Montag, der 28. Dezember 2015)

    –> Klaus Rabba:
    Ich freue mich wie fast jeder über Komplimente, aber:
    Die Problemlösung am Stanzautomaten stammt eben NICHT von mir, sondern ich wurde von einem erfahrenen Ingenieur mit der Nase darauf gestoßen.
    Mir war es wichtig aufzuzeigen, daß Teams, speziell interdisziplinäre, auch ganz andere Katalysatoren haben können als „Projektmanagement“.
    – hb

  3. Klaus Rabba (Montag, der 28. Dezember 2015)

    Da bin ich ganz bei Ihnen.
    Immerhin wurde Ihnen die Aufgabe übertragen und da Sie nicht zu arrogant waren einen erfahrenen Ingenieur zu befragen, gelang die Problemlösung unter enthusiastischer Beteiligung der Nicht-Geschäftsführungsebene.
    Sie haben dieses Beispiel nicht vergessen, ebensowenig die Beteiligten.
    Als ehemaliger Leitender Schiffsingenieur weiß ich, dass man allein nicht alles lösen kann.
    Es ist vielleicht die Gnade der frühen Geburt, die es uns ermöglichte, die Entwicklung von der reinen Mechanik und Konstruktion auf Zeichenpapier hin zu „Industrie 4“ mit zu erleben und ein ganz kleiner Teil davon zu sein.
    Viele Anglizismen aus Informatik und Management sind mir allerdings fremd geblieben, obwohl ich leidlich englisch spreche und schreibe.

    Ich lebe in Frankreich, wo man bis heute fast immer einen französischen Begriff für die US-englischen Ausdrücke fand, was eben nicht zu meiner Entwicklung auf dem Gebiet: Neudeutsch oder im Management ‚Neusprech‘ beitrug.

    Grüße
    Klaus Rabba

  4. rd (Montag, der 28. Dezember 2015)

    Lieber Hans, dieser Artikel spricht mir aus dem Herzen. Vielen Dank!

    Das agile Manifesto möchte ich aber ein wenig verteidigen. Zum einen waren da auch Autoren und Unterzeichner dabei, die zum schwarzen Humor fähig waren und eine gewisse morbide Freude an der Beobachtung des Untergangs hatten, der sich schon damals aufgrund des sich mehrenden Wahnsinns (siehe Projekt Management) abgezeichnet hat.

    Ich betrachte das agile Manifest jedoch nicht als Deklaration von Werten sondern als nützliche Erinnerung, dass man immer einen Trend zu mehr „Bürocrazy“ und „Management“ hat, gegen den man wirken sollte / muss. Weil dieser uns sonst überwältigt.

    Wenn ich noch hinzufügen darf: Das wunderschöne Zitat
    »Jeder Zuwachs an Technik bedingt, wenn damit ein Zuwachs und nicht eine Schmälerung des menschlichen Glücks verbunden sein soll, einen entsprechenden Zuwachs an Weisheit.«
    ist im Original ein wenig länger und von dem großen Bertrand Russell, auch einem Helden meiner Jugend:

    Das habe ich oft in Vorträgen zum Teil am Schluss als zusammen fassende Metapher genutzt. Lasse ich aber mittlerweile sein, weil ich gemerkt habe, dass viele Menschen diese Metapher ganz anders oder gar nicht verstehen. 🙁

    P.S.
    🙂 Muss mal prüfen, ob es auf der http://www.duerre.de nicht auch verkürzt steht.

    Aber zurzeit steht dort eh der Benjamin Franklin mit einem genauso wichtigem und richtigen Satz:

    »Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben, verdienen weder Freiheit noch Sicherheit.«

    »Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.«

    Benjamin Franklin (1706-1790)

Kommentar verfassen

*