Software-Engineering

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.

Inzwischen bin ich ja in der zweiten Woche in meinem neuen Wirkungskreis.

Abgesehen, dass das Arbeiten in einem 30-Mann-Laden voellig anders ist, als in einer Tausend-Mann-Software-Organisation, habe ich mich aber schon ganz gut eingelebt .

Ich komme als Vollblut-Softie in eine Gruppe begnadeter Projekt-Manager, erfahrener Dokumenten-Artisten und Requirements-Dokumentierer und bekomme die (in den letzten zwei Jahren etwas zu kurz gekommene) Multikulti-Atmosphaere wieder. Manchmal an Stellen, wo man sie nicht erwartet (wenn ein Zulieferer im Rheinland ernsthaft die Integration verschieben will, weil sie mit dem Karneval kollidiert).

Die Spielzeuge, an deren Entstehung ich jetzt mitwirke, entstehen nach neuartigen Prozess-Konzepten wie dem V-Modell (mit seinen Urspruengen in den 1980ern), die Entwicklung im Detail ist dagegen an manchen Stellen unerwartet agil. Trotzdem kaempft man gegen die Fehlentscheidungen, die vor zwei Jahren getroffen wurden und weiss, dass man noch gut und gerne zwei bis drei Jahre damit zu tun haben wird.

Die Situation an der Toolchain-Front ist ungefaehr vergleichbar mit dem Zustand, den ich vor etwa zwei Jahren bei meinem Ex-Arbeitgeber vorgefunden habe. Dieses Mal sind allerdings sie jeweiligen Inseln ueber mehrere Firmen verteilt, das An-Einem-Strang-Ziehen der verschiedenen Parteien und die Transparenz untereinander wird also nur marginal einfacher gehen als in den letzten zwei Jahren wo sich alles innerhalb eines Konzerns abgespielt hat.

Ach ja: natuerlich geniesse ich den kurzen Arbeitsweg, solange es noch was Besonderes fuer mich ist und die Kantine ist wirklich so gut, wie sich viele Geruechte und Legenden im Ort erzaehlen.

Und: kommentieren bitte hier und nicht auf Facebook!

Nachdem ich ja eine Weile auf der Bewerber-Seite stand und in meinem aktuellen Job-Umfeld keine Neu-Einstellungen zu taetigen waren, bin ich fuer ein paar Wochen auf die Gegenseite gewechselt und filtere Lebenslaeufe. Nach der Lektuere von ca. 50 (gefuehlten 100) Lebenslaeufen gibts ein paar Erfahrungen.

Ein paar Dinge sind mir schon aufgefallen:

• Wie eine vollstaendige Bewerbung auszusehen hat, ist eigentlich kein wohl gehuetetes Geheimnis mehr, es gibt Webseiten darueber, die Bewerber-Portale grosser Konzerne lassen auch keine Unklarheiten (auch wenn ich zugeben muss, das Portal meines aktuellen Arbeitgebers nicht dahingehend angeschaut zu haben), trotzdem schaffen es Unmengen Bewerbungen mit fragwuerdiger Qualitaet bis zu "uns" als Fachabteilung
  
• Es ist selbst fuer Deutsch-Muttersprachler mit akademischen Abschluss offenbar nicht selbstverstaendlich, den Office-Spellchecker ueber den Lebenslauf und Anschreiben laufen zu lassen (oder ersatzweise mindestens einen Mitmenschen vor dem Abschicken Korrektur lesen zu lassen)
  
• Wenn man (zB insolvenzbedingt) in einer Transfer- oder Beschaeftigungs-Gesellschaft angestellt ist, bewirbt man sich offensichtlich ohne Ruecksicht auf Verluste bei jeder Stelle, ganz egal, ob das Profil IRGENDwie passen koennte
  

Auf letzteren Punkt lohnt es sich, etwas genauer einzugehen.

Ich kann jeden in dieser Lage verstehen. Aber dann kann es hilfreich sein, den Lebenslauf zu ueberarbeiten, dass eine gewisse Vielseitigkeit und schnelle Auffassungsgabe daraus hervorgeht. Lebenslaeufe, die keine Berufserfahrung in den direkt geforderten Bereichen aufweisen, klopfe ich darauf hin ab, und wenn ich das nicht herauslesen kann, setze ich im entsprechenden Recruitment-Portal auf "Absage". Ich meine damit nicht die (fast ueberall auftauchenden) Schlagworte in den Soft-Skills, sondern eine gewisse Vielseitigkeit in den Aufgaben. So kann es sinnvoll sein, wenn ein Software-Entwickler auch Themen wie "Administration eines Linux-Servers" im Lebenslauf stehen hat. Auch dies sollte natuerlich in sich stimmig sein, also macht es keinen Sinn, bei der genannten Server-Administration, dann bei "Sonstigen Kenntnissen" nur Windows stehen zu haben.

Zur Vollstaendigkeit:

Oft kann ich in der Fachabteilung ersehen, wie oft die Personaler Ping-Pong spielen mussten, bis die Bewerbung "vollstaendig" war (was das fuer mich bedeutet, kommt gleich ). Wenn sich das ueber laengere Zeit hingezogen hat, gibt das auch Minus-Punkte.

Fuer mich bedeutet "vollstaendig", dass ich einen Lebenslauf finde, aus dem hervorgeht, wie lange der Bewerber wo war, und was er dort gemacht hat. Anschreiben finde ich zwar vor, lese ich aber im Normalfall nicht genauer (in vielen Faellen ist es eh eine nichtssagende Email).

Hat ein Lebenslauf mein Interesse gefunden (also bei ca. 10% der Bewerber) steht eine Google-Suche an, die in vielen Faellen auch Fundstellen in den gaengigen Social Networks zu Tage bringt. Interessiert bin ich aber eher an Publikationen oder Vortraegen des Bewerbers, oder an Usenet-Postings (insbesondere bei aelteren Bewerbern) oder Forums-Beitraegen (insbesondere bei juengeren Bewerbern). Allerdings sind hier eher fachlich relevante Artikel interessant. Ein Software-Entwickler, der aktiv in Eclipse-Mailinglisten oder Foren mitschreibt, ist spannend. Ich wuerde allerdings einen Bewerber dessen einziger Footprint im Netz eine grosse Urlaubs-Photo-Serie im Netz ist, nicht von vornherein aussortieren.

Ist ein Lebenslauf in irgendeiner Form "seltsam", also ist er

• Extrem gut, oder extrem schlecht
  
• Von einem Englisch-Muttersprachler oder Inder in Englischer Sprache
  

freut sich der geneigte Fachidiot ueber ein Arbeitszeugnis eines deutschen Arbeitgebers.

Hier lassen sich die Standard-Formulierungen entweder von einem Personaler oder von Herrn Google genauer unter die Lupe nehmen.

Es ist und bleibt aber so, das Haupt-Werkzeug ist und bleibt der Lebenslauf. Normalerweise entscheidet sich beim ersten Lesen, ob es eine Zu- oder Absage wird. Als Lebenslauf-Autor hat man also ein paar Minuten meiner Aufmerksamkeit. Spannenderweise sind mein Kollege, mit dem ich die Lebenslaeufe diskutiere meistens einig.

Ach ja:

Wenn schon kommentieren dann hier und nicht auf Facebook!

Morgen steht der letzte Besuch bei der Niederlassung in Daenemark an.

Die letzten Wochen und Monate waren schon gepraegt von Vorbereitungen fuer die kommende Woche, in der die Entwickler dort "unser" Configuration Management zu benutzen beginnen sollen.

Damit soll ein Teil der Fehler, die beim Vorgaengerprojekt mit dem gleichen image-traechtigen Kunden passiert sind (und klassische CM Fehler) vermieden werden.

Auf meinen letzten Besuchen im noerdlichen "hyggeligen" Nachbarland durfte ich schon Bestandsaufnahmen und Politik machen, Konzepte erarbeiten und Trainings veranstalten.

Ich bin gespannt, wie das funktionieren wird. Ein grosser Teil der Arbeit wird Support und Haendchenhalten sein, bevor naechste Woche dann ein Kollege die gleiche Reise unternimmt, um Support vor Ort ("on-site" wie man im Managerdeutsch so sagt) zu leisten.

Ob es vermag, wenigstens diese Sorte Fehler zu vermeiden kann natuerlich niemand sicher beantworten, noch viel weniger, ob das neue Projekt weniger Staub aufwirbeln wird, als das gerade ueberstandene.

Gestern ist Joseph Weizenbaum ist gestern in Berlin mit 85 Jahren gestorben.

Wir haben ja schon seit ein paar Monaten eine neue Mitterfirma. Diese Mutterfirma hat ausser uns noch diverse ander Toechterfirmen. Von diesen Toechtern dreht es sich jetzt um eine, die thematisch genau die gleiche Software strickt wie wir, wenn auch mit ein paar anderen Vorgehensweisen, anderen historisch gewachsenen Strukturen usw. Diese Tochterfirma erstreckt sich ueber mehrere Standorte, wo uns der naechstliegende in Muenchen (dort, wo wir ab Ostern auch residieren werden) und ein nicht ganz so naheliegender in Nuernberg zu liegen kommt.

Es ist also nicht ueberraschend, dass wir immer mal wieder angefordert werden, irgendwo zu helfen, wo es brennt, wo jemand gekuendigt wurde, oder wo einfach Spezialwissen gefragt ist, was jemand von uns hat. Jetzt soll ich mit einem Kollegen eine Aufgabe uebernehmen (90% er, 10% ich), wo wir erstmal auch eingearbeitet werden sollen. Eine Teilaufgabe davon sind Lieferungen eines bestimmten Subsystems an einen bestimmten Kunden.

Wir hatten schon vor fast zwei Wochen darauf bestanden, dass wir so eine Lieferung mal unter Aufsicht machen wollen, um die ganzen Mechanismen, Arbeitsauftraege kennenzulernen, dass wir uns schonmal daran gewoehnen koennen, Daten von einem Excel-Sheet ins naechste zu kopieren, Dinge per mail zu verschicken, die man eigentlich besser auf shares ablegt und Dinge auf shares ablegt, die eigentlich in Mails besser verbreitet werden.

Also hat sich (verkuerzt) ungefaehr der folgende Mailwechsel gesponnen:

PL1 (Muenchen) an PL2 (Nuernberg): "Xlf und $kollegevonxlf muessten eine Lieferung zur Einarbeitung machen, koennen sie das mit Dir naechste Woche machen?"
PL2 an PL1: "Ja, aber sie muessen nach Nuernberg kommen, weil ich hier jemanden anderen Supporten muss"
(es fahren also schonmal zwei Leute nach Nuernberg, um einen Menschen zu treffen)

Ich und mein Kollege erklaeren sich bereit, nach Nuernberg zu kommen (ich bin eh schon einen Tag dort und fahre dann halt einfach den Tag vorher auch schon hin).

Ich -> PL2: "Gibt es irgendwelche Dokumentation ueber die Lieferung, die wir da machen werden?"
PL2 -> Ich: "Was fuer eine Lieferung? Da ist doch gar keine Lieferung geplant"
Ich -> PL1: "Es scheint gar keine Lieferung geplant zu sein, was fuer einen Sinn hat das dann alles?"
PL1 -> Ich: "Das stimmt, aber PL3 macht naechste Woche eine Lieferung in Muenchen"

Meine Goettergattin muss mich fuer einen Schwaetzer halten und die Firma in der ich arbeite fuer total bekloppt, die Assistentin, die fuer uns die Zugfahrkarten bucht, muss mich fuer einen extrem planlosen Kollegen halten und ich will gar nicht so genau wissen, was die netten Damen im Reisebuero und im Hotel denken, wenn ich dann am Montag das alles wieder stornieren lasse.

Jetzt kann ich eh nix mehr bis Montag aendern und dann werde ich erst mal in Ruhe den Vormittag nutzen um das zu klaeren. Vielleicht haben die ganzen involvierten Leute dann ungefaehr eine Ahung, wer was macht.

Nachdem ich gestern bei meiner wichtigsten Arbeit nicht vorwaerts gekommen bin, weil der ganze Tag aus Telefonaten, Kollegen an meinem Schreibtisch, Mails beantworten usw. bestand habe ich heute nach dem abhalten eines immer mittwochs stattfindenden Meetings in ein unbevoelkertes Zimmer zurueck gezogen und habe gearbeitet. Als einziger wusste mein Scheff und die Kollegin, fuer die ich die Arbeit mache wo ich sitze.

Der Tag war dann auch erfolgreich, und als ich kurz vor meinem Feierabend an meinen Schreibtisch zurueck kam, meinten meine Kollegen, dass mein Telefon kein einziges Mal geklingelt haette und auch kein einziger Kollege waere da gewesen (Kunststueck, sie waren ja gestern schon alle da).

Seitdem bekannt wurde, dass wir wieder mal verkauft wurden, ist es richtig schwierig, neben dem Austauschen von Informationen, unbestaetigten Geruechten und pessimistischen Aussichten auch noch Arbeit zu schaffen.

Zum einen ist natuerlich bei vielen Kollegen ein massives Motivationsloch zum Anderen wollen lechzen Alle nach Informationen und aus jedem noch so kleinen Anruf um gezielt Informationen fuer mein Tagesgeschaeft zu bekommen ("in welcher Version ist der Bug Nr. 4711 geloest?") wird eine halbe Stunde Frage-und-Antwort-Spiel, wer wieviel weiss, wer noch Lust hat, was fuer die neuen Inhaber zu tun, wie hoch unsere Chance ist, dass unsere Software ueberlebt etc.

Nachdem ich als Integrator, Tools und Methoden-Arbeiter nicht direkt an der Front bin, arbeite ich zur Zeit an Aufraeum-Arbeiten, die seit Wochen liegengeblieben sind. Einerseits koennen diverse huebsche Tools und Informationssysteme auch zur Profilierung unserer Gruppe beitragen, andererseits weiss man ja nicht, wofuer es gut ist, wenn da mal jemand anderes reinguggt. Nachdem wir an einigen Stellen unseren neuen Eigentuemern was voraus haben duerften, tue ich gut daran, "meine" Software so modular zu gestalten, dass sie auch in einem neuen Umfeld arbeiten kann.