Dies ist die Heimat der Java User Group Nürnberg.


Freitag, 14. März 2008

Moderne Prozessoren und ihr Einfluss auf die Performanz in der JUG

Gestern fand das JUG-Treffen wie gewünscht zum Thema "Moderne Prozessoren und ihr Einfluss auf die Performanz unter Java" statt. Wir hoffen, es war interessant und hilfreich^^ 

Donnerstag, 13. März 2008

Hex and the City: Was machen wir eigentlich?

Wer kennt ihn nicht, den ganz normalen Projektwahnsinn. Zumindest ein jeder, der selbst Teil unserer IT-Branche ist. Diejenigen werden also vielleicht im Laufe des Artikels schmunzeln und denken "kenn ich". Alle anderen1 bringt es hoffentlich die Probleme und Aufgaben näher, mit denen wir uns täglich herumschlagen. Was sind denn das für Aufgaben?


Bevor wir zu den Aufgaben gelangen, sollten wir erst betrachten, was wir so machen. Und wer wir sind.


Je nachdem wen wir fragen, glauben die Leute, unser Hauptproblem sei zwei Nullen zu addieren und 1 dabei als Ergebnis zu erhalten. Oder etwas in der Richtung. Andere meinen wir haben zig Tabellen und beschäftigen uns mit dem Ausfüllen und Löschen von Spalten und Reihen. Nicht ganz unwahr, wobei hier Oracle-Profis und Tabellenkalkulationstipper (böse Zungen sprechen auch von Wirtschaftsinformatikern, ich natürlich nicht) in einer Kategorie landen.2 Wieder andere behaupten, wir drücken den ganzen Tag Start um zu Beenden, auch nicht unwahr.


Eigentlich ist unsere Arbeit aber viel simpler, als die Leute glauben meinen. Es ist nämlich Magie. Wir schreiben einen Satz in einer für Uneingeweihte unbekannten Sprache und schwupps: es passiert gar schreckliches, oder irgendeine sinnvolle Nachricht erscheint. Manchmal müssen wir auch ritualähnlich vorher seltsame Diagramme aus kryptischen Symbolen zeichnen – mancher Nichtinformatiker hat vielleicht schon mal was von diesen Ummel-Diagrammen gehört.


Im Ernst: die Welt der Informatik verbirgt hinter all ihrer Magie Personen in unterschiedlichen Jobs mit verschiedensten Aufgaben. Es folgt ein kurzer Überblick (vielleicht nicht mehr mit ganz soviel Ernst), natürlich gibt es jede der Rollen auch in der weiblichen Form.


Da gibt es den Projektleiter (Zauberkurator): der hält die Meute in Zaum und passt auf, dass Geld nicht total sinnlos verbraten wird.


Der Architekt (Erzmagier oder Zauberermagister): Er zeichnet die Diagramme. Dabei handelt es sich nicht um Ummel wie manche gehört zu haben glauben, sondern um UML. Es sind nämlich genau betrachtet gar keine Zeichnungen, sondern Sätze einer graphischen Sprache. UML bedeutet nämlich Unified Modelling Language, und die Symbole sind wie Wörter. Der Architekt arbeitet aus, was notwendig ist, um aus zwei Nullen eine Eins zu machen, bzw. wie es technisch geht, dass wir bei einem Internetshop ein Buch über Zauberei kaufen, und uns später der Postbote ein Paket bringt. Und das, obwohl das Millionen Leute auch gerade gleichzeitig tun – vielleicht nicht gerade mit dem gleichen Buch.


Der Entwickler (Zauberer): Er richtet sich nach den technischen Vorgaben des Architekten und behauptet vor dem Projektleiter grundsätzlich im Zeitplan zu sein, aber mehr Budget zu brauchen. Er baut auch unter Anleitung des Architekten dergleichen Feinheiten ein, dass uns der Internetshop morgen die passenden Kräuter und Utensilien zum Zauberbuch vorschlägt. Häufig verliert er sich in diversen Nebenbeschäftigungen (wie selbst im Internetshop zu stöbern), aber der Projektleiter führt ihn wieder auf die richtige Spur. Der Entwickler darf (im Gegensatz zum Programmierer) noch selbst – auf die Aufgabe bezogen – denken.


Der Programmierer (konfuser Zauberer): Er unterscheidet sich vom Entwickler darin, dass er mehr Arbeitsanweisungen und Richtlinien vom Architekten benötigt (glauben zumindest alle anderen). In der Regel wird von ihm gefordert nicht mehr selbst zu denken – in Bezug auf die Aufgabe.


Der Skripter (Thaumaturg): Während Entwickler/Programmierer sehr viel in sehr komplexen Sprachen schreiben, damit etwas passiert, schreibt der Skripter eher wenig in simpleren (trotzdem aber unbekannten) Sprachen, woraufhin auch etwas passiert. Skripter sagen, ihr Ergebnis ist gleich dem Resultat der anderen, die anderen behaupten, das ginge nur, solange wenige Menschen gleichzeitig das Ergebnis wollen (und tun die Skripterei als Amateurkunst ab). Niemand von beiden Fronten kann aber genau sagen wie viel „wenig Menschen“ sind.


Der Admin (Hexer): Sorgt dafür, dass die anderen Arbeiten können, in dem er Rechner, Betriebssystem und die gängigsten Programme für den Rest hinstellt und am Laufen hält. Häufig nebenbei Skripter.


User (Opfer der Zauberei3): Benutzt was die anderen ihm bieten. Kann auch zeitgleich eine der anderen Rollen einnehmen.


Jetzt ist grob geklärt, wer sich u.a. in unserer Branche tummelt. Aber was machen wir? Sicherlich nutzen wir nicht den ganzen Tag ein Tabellenverarbeitungsprogramm. Im Folgenden kann ich nur für mich und meine Erlebnisse sprechen, aber der eine oder andere findet sich sicherlich wieder:


Da wären Projekte der Art, dass Unternehmen, die sich mit dem Verschlüsseln von Fernsehsendungen beschäftigen, Klärungsbedarf bezüglich Verschlüsselung haben, so dass man ihnen die technischen Verfahren der Kryptographie näher bringt. Dies ist quasi die Aufgabe eins (unter den Rollen bislang nicht genannten) Beraters (der Heilige unter den Rollen).


Oder eine Software, die seit mehreren Jahren entwickelt wurde und weltweit verbreitete Unternehmensdaten zentral sammelt und verwaltet und als Managerinformationen mit mannigfaltigen Analysemethoden wieder international zu Verfügung stellt, bricht plötzlich den Dienst ab. Hier ist ein Review notwendig, dass heißt Jahre alte Diagramme werden studiert, die magischen Zeilen gelesen (die in ihrer Menge ganze Bücher füllen), und die eine falsche Stelle wird identifiziert. Nicht über auspendeln, sondern tatsächlich über Lesen und Verstehen. Man stelle sich einen mathematischen Beweis aus der Schulzeit vor, jetzt aber in Buchlänge und der enthält (mindestens) einen Fehler. Ein extrem großes logikbasiertes Suchbild.


Das sind die kurzfristigen Beschäftigungen, denen wir im Alltag immer wieder ausgesetzt sind. Natürlich gibt es auch längerfristige Aufgaben:


Darunter fällt die Erstellung einer Börsenhandelapplikation, welches alle Finessen zum Thema Sicherheit, Synchronität, Performanz etc. fordert. Hier stellen sich insbesondere Probleme mit der Vermeidung von Missbrauch durch kriminelle Aktivitäten. Also wird monatelang die Architektur erarbeitet, das Programm geschrieben und immer wieder getestet und verbessert. In den Testphasen tut man sein möglichstes Lücken zu finden, damit später im finalen Programm niemand auf ein fremdes Konto zugreifen kann, oder sich illegal Geld an der Börse verschafft.


Bei diversen Unternehmen sind so genannte WorkFlow-Szenarien umzusetzen. Dies bedeutet man krempelt das Formularwesen des Unternehmens um und richtet alles auf elektronische Verarbeitung ein. Eines der größten Probleme bei Projekten dieser Art liegt nicht unbedingt in der Technik. Vielmehr ist hier die spätere Benutzerakzeptanz entscheidend, denn alle Arbeit ist erfolglos, wenn später der Umgang mit den Formularen in handfester Papierform immer noch leichter erscheint, als der neue Weg. Hier ist also Geschwindigkeit, sprich der effiziente Umgang mit den Formularen, und der Nährwert (z.B. im Auffinden von Daten, Archivierung, schnellere Rückwege bei Klärungsbedarf zu Formularinhalten) wichtig. Monatelanger Feinschliff folgt meist der raschen Entwicklung zu Beginn.


Auch sind Projekte zur Kundenbindung häufig vertreten. Dabei geht es um ein ganzes Szenario, welches es zu entwickeln gilt. Meist kann der Endkunde, der gebunden werden soll, Punkte sammeln4. Diese Punkte darf er in einem Prämienshop ausgeben. Dazu kommt noch ein Service-Center, denn auch Leute die gebunden werden sollen, dürfen sich beschweren oder haben Fragen. Solche Systeme bestehen also aus Service-Center Applikationen, einem Prämienshop, diversen Anbindungen zu Unternehmen, bei denen man die Punkte sammeln kann, und vielen automatischen Prozessen (Informationsbrieferstellung, Punktestandberechnung, Registrierungsverarbeitung, uvm.) sowie einer gigantischen Datenmenge auf der alles basiert.


Was wir immer wieder in Projekten lösen müssen, ist:

  • Stabilität: eine Website, die häufig nicht erreichbar ist, wird sicher irgendwann nicht mehr besucht

  • Konsistenz: wer möchte schon gerne, dass sein Bankkonto eine Ziffer in den schwarzen Zahlen zu wenig hat

  • Performanz: überlegen Sie mal, Sie sitzen an einem Computer nur für sich. Und sie machen das Mailprogramm auf. Und warten sekundenlang, bis es verfügbar ist. Gut, das ist Realität, aber wetten, das dauert Ihnen zu lange? Und jetzt soll eben jener Computer auf die Zugriffe von Tausenden von Benutzern gleichzeitig reagieren (die sich zum Beispiel eine Webseite anschauen wollen, die auf dem Computer liegt). Und die wollen maximal (jeder für sich!) auch nur ein paar Sekunden warten. Warum klappt letzteres und beim ersteren müssen sie so lange warten? Das traue ich mich nur in der Fußnote zu beantworten5

  • Und etliches mehr, vor allem die Softskills sind nicht zu unterschätzen. Also mit den Kollegen reden, trotz stressiger Situationen und Zeitdruck gelassen bleiben, böse eMails einfach gar nicht ignorieren^^


Wir machen gerade bei den technischen Aspekten immer wieder Fehler. Mir ist nichts suspekter als ein Informatiker, der behauptet, sauber zu arbeiten und keine Fehler zu machen. Lauffähige Software nahezu fehlerfrei herzustellen, bedeutet einzusehen, dass Fehler gemacht werden und unvorhergesehene Probleme entstehen. Daher gibt es (hoffentlich) umfangreiche Testphasen während der Entwicklung, in denen wir Fehler (die wir ja alle machen!) erkennen und dann beheben. Wir sprechen somit davon, dass wir Software meist iterativ entwickeln und verbessern. Folglich gehört das Testen unserer Software zu unseren Aufgaben, mehr oder weniger täglich.


Ein interessanter Fehler, der einmal auftrat, ist, dass Entwickler aus Effizienzgründen bei einem Navigationssystem zur Raketensteuerung Vorzeichen (also Plus und Minus bei Zahlen) ignorierten. Die Rakete hatte bezüglich der Drehlage um ihre Längsachse keine Anforderungen. Soweit so gut. Bis jemand auf die Idee kam, Wiederverwendbarkeit zu betreiben und die Software für den Autopiloten eines Flugzeuges genutzt haben. Es gab nach vielen nationalen Tests einen extrem interessanten Testflug über den Äquator, als dort das missachtete Vorzeichen dazu führte, dass sich das Flugzeug begann um die Längsachse zu drehen, um sich auf den Rücken zu legen. Auch dieser Fehler wurde dann iterativ behoben ...6


Jetzt habe ich einmal gewagt, einen kurzen subjektiv geprägten Blick auf das Leben in unserer Branche zu werfen und ihn zu verdeutlichen. Ich hoffe, niemand legt dabei Wort für Wort auf die berühmte Goldwaage, aber auch denke ich, dass die aufgezeigten Punkte tatsächlich Säulen im Tempel der Informatik bilden.


Zum Schluss noch eine kleine Anekdote, was alles in einem Projekt schief laufen kann, selbst wenn wir in der Technik keine Fehler mehr machen (würden). Vor wenigen Tagen wurden zur Einführung eines wirklich großen Projektes Formulare an potentielle Endkunden verschickt. Das Formular soll bei Interesse von eben diesen Kunden (vollständig!) ausgefüllt werden (mit den üblichen Verdächtigen: Felder wie Name, Anschrift, Geburtsdatum, etc.). Die Fachabteilung hat sich redlich Mühe gegeben, dies so angenehm und benutzerfreundlich wie möglich zu gestalten, und das Formular wurde für den Kunden bereits vorausgefüllt. An dieser Stelle erinnern wir uns bitte an das bereits erwähnte „vollständig!“. Leider fehlte im Vordruck das Geburtsdatum. (Fast) Niemand der antwortete, hat das Geburtsdatum selbst angegeben, denn wem fällt schon auf, dass unter den Daten etwas fehlt. Kleiner Fehler. Leider große Wirkung. Denn ohne rechtliche Absicherung, dass der Endkunde über 16 Jahre alt ist, durfte das eigentliche Kerngeschäft des Projektes nicht durchgeführt werden, was mit hohen Zahlen ziemlich in das Risikobudget geschnitten hat. Vielleicht hätte man noch etwas unternehmen können, wenn erste Formulare so zurückgekommen wären, und noch nicht alle verschickt worden wären. Leider ließen die Formulare auf dem Rückweg auf sich warten. Dies geschah aber nicht, weil die Endkunden verträumt in der Sonne warteten und keine Lust auf eine Antwort hatten. Nein, es gab einen schwergewichtigeren Grund, bzw. leichtgewichtigeren, wie nach einer Beschwerde der Post bemerkt wurde. Das entsendete Papier war zu dünn und hatte die Sortiermaschinen mehr als verstört. Diese standen erst einmal verstopft und somit unbrauchbar herum. Nachdem die ersten Formulare ihren Heimweg endlich gefunden hatten, begaben sie sich mehr oder weniger selbstständig zum Scannen und der anschließenden Texterkennung. Dazu prangte auf dem Formular extra der Hinweis: „Bitte in Großbuchstaben ausfüllen“. Klasse Idee, wenn sich die Endkunden daran hätten halten können. Aber wie bereits erwähnt, das Formular war ja bereits ausgefüllt. Wie man es an dieser Stelle bereits erahnen kann, natürlich mit großen und kleinen Druckbuchstaben. Was wieder nach einer simplen Verwechslung beim Erzeugen des Vordrucks seitens der Fachabteilung klingt (und nichts weiter war es), brachte das Projekt erneut in Bedrängnis. Denn das Teilprojekt zur Texterkennung war nach den früheren Vorgaben des Fachbereiches lediglich in der Lage, Großbuchstaben zu verarbeiten... Murphy's Gesetz.



1Also Personen, die immer wieder Fragen der Kategorie „was machst Du eigentlich“ stellen. Daraufhin denke ich mir jedes Mal: sage ich die volle Wahrheit (dann wird es komplex), gebe ich mir die Mühe es zu erklären (darauf habe ich nicht immer Lust), oder behaupte ich einfach einen ganz anderen Beruf zu haben, damit die Augen meines Gegenüber sich nicht wieder so merkwürdig verdrehen**

** Schlimmer sind übrigens Fragen wie: „Du hast doch Informatik studiert. Ich habe da ein Problem mit [meinem Textverarbeitungsprogramm***]“

*** In der Regel wird statt Textverarbeitungsprogramm der simple englische Begriff für Wort verwendet, aber ich gehe rechtlichen Problemen da gern aus dem Weg.

2Ich werde mir kein Urteil erlauben, wem dabei mehr Unrecht angetan wird.

3Es gibt zum User auch die Subklasse des DAU (was ich mich nicht traue ausgeschrieben anzugeben). In dieser Form ist er seit Joanne K. Rowlings „Harry Potter“-Buchreihe als Muggel bekannt.

4Um ihn zu binden – erinnert ein wenig an Tolkien

5Vielleicht haben unsere Projekte bessere Architekten und Entwickler als das Mailprogramm und Betriebssystem? Wer weiß. Vielleicht ist es aber auch leichter, Tausenden Nutzern eine Webseite über das Internet zukommen zu lassen, als ein paar eMails am Bildschirm zu präsentieren ... (wobei das jetzt ketzerische Anstachelei war^^)

6An dieser Stelle muss ich erwähnen, wie froh ich bin, nicht in der Luftfahrtindustrie zu arbeiten. Ich könnte keine Urlaubsreise entspannt antreten.