Etwas stärker bewölkt als an den anderen Morgenstunden der letzten Woche. Der wetterbericht ist aber nicht anders, als die letzten Tage: 35grad, Regen (was bisher immer bedeutet hat, dass es am Nachmittag gescheit scheppert)

Nach zwei Abenden im hiesigen Nachtleben hier nun also ein paar Bilder:


Skyline-Blick aus dem 13. Stock, wo man gepflegt in westlicher Atmosphaere sein Kingfisher (oder die ganze Bandbreite an westlichen Getraenken) schluerfen kann.


Haupteinkaufsmeile


Shopping-Mall, in dem man Luxusgueter zu Luxuspreisen (selbst fuer unsere Verhaeltnisse) kaufen kann.


Gestriges Abendessen (keine Sorge, es sind staendig Leute vorbeigekommen, die nachgefuellt haben, wenn man nicht resolut abgelehnt hat)

Hinter der passkontrolle findet sich deutlich anderes Publikum, als auf den Businesskasper-Flügen. Hier sind es dann schon eher indische Familien, langhaarige Rucksack-touristen mit Apple-gadgets und ein paar Geschäftsreisende ohne Apple-gadgets.

Zu hause wäre so ein Anblick nicht einmal ein Foto wert, aber fast sechs Autostunden entfernt hätte ich diese Werbung nicht erwartet

In der Kantine ist es mir ja schon aufgefallen und das Plakat hat es bestätigt

Inzwischen liegt der erste Januar 2010 ja schon eine Weile zurueck und irgendwie scheinen die Banken ihren Kunden immer noch keine wirkliche Loesung fuer das EC-Karten-Problem praesentieren zu koennen.

Nachdem es sich ja offensichtlich um einen typischen Bug in einem typischen Stueck Software handelt, der durch einen dummen Zufall grosse Auswirkungen auf ein paar Zigtausende Geraete mit ein paar Millionen Benutzer hat, kann man das Alles ja mal ein wenig durch die Brille eines Softies beleuchten.

Wir bewegen uns also in einem Markt, wo eine Handvoll Technologie-Anbieter (die Anbieter von Chipkarten bzw. die Chips derselbigen), sich um ein paar Hundert (mehr Herausgeber von EC- und Kreditkarten gibs sicher nicht in Deutschland) balgen, die sich wiederum um die bereits erwaehnten paar Millionen Bank-Kunden bemuehen.

Ich war ja diverse Jahre in einem Markt zugange mit aehnlichen Zahlenverhaeltnissen in der Rolle der Handvoll "Platform-Anbieter". Die Umgebungsbedingungen sind gepraegt durch einen Standard, der (zum Glueck) vorgibt, wie die Geraetschaften alle untereinander ein Mindestmass an Funktionalitaet erbringen sollen (also im Wesentlichen Transaktionen in Girosystemen loszutreten). In diesen Standards sind normalerweise auch Test-Prozeduren festgelegt, wo es eben auch um Banalitaeten wie Jahreszahlen gehen sollte.

Nachdem es ja auch nur Geraete mit einer bestimmten Software eines bestimmten Anbieters betrifft, kann man mal davon ausgehen, dass der Standard an dieser Stelle robust genug ist, bzw. dass man an dieser Stelle das Problem erkannt und auf mehr oder weniger saubere Art umschifft hat.

Idealerweise hat man (insb. als Platform-Anbieter) fuer solche Uebergaenge wohldefinierte Testroutinen, die idealerweise genau dieses Problem feststellen, bevor es in ein paar zigtausend Geraetschaften ein paar Millionen Benutzer stoert. Am idealsten fuer das "Systemhaus" ist es natuerlich, wenn die Tests derart umfassend sind, dass bereits dem Entwickler der das betreffende Programm-Schnippsel erzeugt, der Code auf die Fuesse faellt. Eine derart hohe Testabdeckung kostet aber richtig Geld. Die Tests muessen entwickelt werden, Infrastruktur muss dafuer vorgehalten werden, die Tests muessen gepflegt werden. Auf der anderen Seite steht dem nicht wirklich messbares gegenueber. Sitzen Entscheidungstraeger ohne einen ausgepraegten Software-Hintergrund am Ruder steht man eigentlich dauernd unter Rechtfertigungs-Druck. Andererseits ist an dieser Stelle die Behebung des Fehlers noch am billigsten (ein Mann, der den Fehler mit Tools-Hilfe entdeckt, sich in den Bauch beisst, den Fehler behebt und froh ist, dass es sonst niemand gemerkt hat).

Hat man einen halbwegs passabel funktionierenden Review-Prozess, hat man womoeglich noch Chancen, dass dem zweiten Entwickler so ein Fehler auffaellt, aber bereits diese Chance ist deutlich geringer. Hier laesst es sich mit entsprechender Tool-Unterstuetzung und Protokollierungsaufwand womoeglich messen, wieviele Bugs gefunden wurden, so dass man schon etwas einfacher argumentieren koennte, aber es ist eben schon deutlich lueckenhafter. Ausserdem ist es an dieser Stelle schon deutlich teurer (ein zweiter Mann, der sich erst in die Code-Aenderung einarbeiten muss, der den Fehler entdecken und erklaeren muss, die Behebung kommt dann noch dazu).

Ist der Fehler mal von dem kleinen Arbeitspaket in die naechste Stufe gewandert ist die Wahrscheinlichkeit verschwindend gering, dass jemand diesen Test ausfuehrt:

1. setze das Systemdatum auf den 1. Januar 2010
   
2. fuehre eine Transaktion durch
   

Die Integratoren, die diese Aenderungen Wochen nach der eigentlichen Entwicklungsarbeit in das Gesamtsystem (also die Software fuer ein Kartenterminal) einpflegen, haben mit hoher Wahrscheinlichkeit ein paar Tausend Aenderungen ("Change Requests") abzuarbeiten und stehen normalerweise zu stark unter Zeitdruck, um mehr als einen absolut minimalen Testdurchlauf zu machen ("Smoke Test"). Dieser wird womoeglich so aussehen:

1. Geraet einschalten
   
2. Transaktion nach dem Ermessen des Testers durchfuehren
   
3. Geraet ausschalten
   

Dieser Test ist genau genommen zufaellig, findet vermutlich unter irgendwelchen Laborbedingungen statt und prueft lediglich einen kleinen Teil eines Anwendungsfalles ab (ein "Sunny Day Scenario").
Selbst ein Fehler, der an dieser Stelle gefunden wird, ist nochmal deutlich teurer in der Behebung, weil eben noch (mindestens) ein dritter Mann involviert ist, in diesem Fall der urspruengliche Entwickler von seiner jetzigen Aufgabe auf die bereits mehrere Wochen alte Aenderung angesetzt werden muss, dafuer diverse Scheffs involviert werden muessen, neue Projekt-Kostentraeger aktiviert werden muessen usw.

Den teuersten Fall erleben wir hier. Der Fehler wird erkannt, wenn er bereits beim Benutzer angekommen ist. Andererseits stehen viele Banken unter massiven Kostendruck (es wird immer schwieriger, Konto-Gebuehren zu verlangen, um die Manager-Boni zahlen zu koennen), dieser Druck wird natuerlich tendenziell an die Lieferanten weitergegeben (und am Ende dieser Nahrungskette steht nunmal irgendein Systemlieferant). So eine Investition in gute Tests kann man da nur schlecht innerhalb eines Quartals umlegen, so dass es dem CEO nicht gruendlich sein variables Gehalt verhagelt. Einfacher lebt es sich dann mit bekannten Qualitaetsrisiken.

Die Kosten dafuer werden in allen der geschilderten Faelle aber auf die eine oder andere Art bei uns als Bankkunden ankommen, nachdem die Kosten irgendwie auf uns umgelegt werden (und wenn auch ueber mehrere Jahre verteilt).
Womoeglich schaffen es allerdings die Entscheidungstraeger das immer noch so schoen zu rechnen, dass es in schlauen Excel-Tabellen immer noch billiger war, als ein solides Testsystem am Laufen zu halten. Das hilft dem Kunden an der Supermarkt-Kasse zwar nicht, aber der Prozess-Verantwortliche des Software-Hauses steht sicher glaenzend da (und wie gesagt, die Zeche zahlt ja der Kunde).

Kommentieren natuerlich wieder hier und nicht auf Facebook.

Heute war der letzte Arbeitstag dieses Jahres 2009. Ich hatte die Möglichkeit, ihn nicht allzu lang werden zu lassen und durfte mit Hilfe meines Schwiegervaters unseren Tannenbaum aufstellen.

Nachdem die Physik (im Wesentlichen die von Herrn Newton formulierten Gesetze) irgendwie eine andere Meinung von Christbäumen in entsprechenden
Halterungen hatten, waren wir auf einen großen Teil der handwerklichen Fähigkeiten angewiesen, bis der Baum dann doch in die Senkrechte kam und auch ohne menschliche Stabilisierung auch (wenigstens zum größten Teil) so blieb.

Inzwischen ist er auch geschmückt (mit ganz CO₂ unneutralen) Lichterketten und diversen Schmuck. Mein Großer hat schon angemeldet, daß doch bitte nächstes Jahr das Christkind den Weihnachtsbaum bringen soll, wie bei Freunden von uns.

Auf jeden Fall wünschen wir allen Lesern ein friedvolles Weihnachtsfest und ein erfolgreiches neues Jahr!

PS: Kommentieren natuerlich hier und nicht auf Facebook.

Inzwischen habe ich eine weitere Uebersetzung des deutschen Wortes "Telefonkonferenz" bekommen.

Offensichtlich findet man keine zwei Firmen (Branchen koennen es nicht sein), die da die gleiche Uebersetzung (und Abkuerzung) benutzen:

1. ConfCall (amerikanische Firma, tief im Halbleitergeschaeft verwurzelt)
   
2. TelCo (deutsche Firma, tief im Halbleitergeschaeft verwurzelt)
   
3. Telecon (deutsch/franzoesisch/kanadische Firma, tief im... naja worin eigentlich verwurzelt?)
   

Nachdem Variante 1. und 3. aus einem (zumindest ein bisschen) englischsprachigen Dunstkreis kommt, wuerde mich jetzt natuerlich interessieren, wie ein "original" native speaker das jetzt sagen wuerde.

Die englishsprachige Wikipedia sagt dazu Conference Call, wo ConfCall eine gute Abkuerzung waere. Allerdings findet man auf dem zitierten Artikel dann einen Link auf Teleconference, deren Abgrenzug ich beim eher fluechtigen Drueberlesen nicht verstehe (immerhin wartet ja auch noch DOORS und MS Office darauf, dass ich den Kampf wieder aufnehme).

PS: Kommentieren natuerlich wieder hier und nicht auf Facebook.