Letztens beim Vorstellungsgespräch …
…
Projektleiter: Sie wissen jetzt worum es geht, Herr Schilken. Bitte erzählen sie jetzt etwas über sich. Was sind ihre Stärken, was tun sie besonders gerne, wie sind sie gewohnt zu arbeiten?
A. Schilken: Ich denke meine Stärken liegen darin, das Wesentliche einer Aufgabe zu erkennen und mich darauf zu konzentrieren, dass dieser wesentliche Kern optimal realisiert wird. Dabei ignoriere ich zunächst alle Schnörkel und unwesentlichen Details; dafür ist Zeit, wenn die grundsätzliche Funktion erfüllt ist.
Auch Optimierungen berücksichtige ich erst dann, wenn Messungen bewiesen haben, dass optimiert werden muss, um geforderte Randbedingungen zu erfüllen.
Ich habe eine Vorliebe für die einfachste Lösung einer geforderten Aufgabe. Mögliche zukünftige Erweiterungen gleich im ersten Entwurf vorzubereiten vermeide ich, wenn möglich. Mehrmals habe ich erlebt, dass es entweder nie zu diesen Erweiterungen kam, oder zu ganz anderen, wobei die Vorbereitungen nicht nur nichts halfen sondern auch von Anfang an unnötige Komplexität ins Design brachten.
Ich bin gewohnt, eine abgeschlossene Komponente vollständig zu bearbeiten, also vom Analysieren der Anforderungsdetails, über den Entwurf von Szenarios, dem Suchen möglicher Problemfälle und KO-Kriterien, bis zu Feindesign, Codierung, Test und Integration.
Bis ungefähr zum Jahr 2000 habe ich hauptsächlich in C, C++ und perl entwickelt. Das erste große Javaprojekt war ein eCommerce-System zum Verkauf von Tickets im Internet. Ein Application Server von ATG diente als J2EE-Container für die zu entwickelten Komponenten. Ich erstellte unter anderem eine Sessionbean für die Abwicklung von Kreditkartenzahlungen, die Darstellungsschicht für WAP-Handys in Form von Java-Server-Pages(JSP) und diente als "Springer" für die Bearbeitung hartnäckiger Probleme.
In diesen Sondereinsätzen kommt mir mein Hintergrund als Experimentalphysiker zu Gute: Bei schwer zu reproduzierenden Fehlern hat es sich bewährt, wie in der Physik, über Gedankenexperimente geeignete Abwandlungen des Testfalls zu finden und damit den Fehler immer mehr einzugrenzen.
Schwierige Fälle bearbeite ich am liebsten im Zweierteam mit dem Entwickler der betroffenen Komponente. Ich kann dabei den Fehler als "lustiges Problem" sehen, das gelöst werden will wie ein kniffliges Rätsel. Diese Einstellung hilft, die Anspannung aus dem Suchprozeß zu nehmen.
Das ist wahrscheinlich ein Relikt aus meiner Lehrerausbildung: Lernen und Problemlösen funktieren nicht unter Stress.
Projektleiter: Sie sagten, sie haben ursprünglich Lehramt studiert. Wie sind sie in unsere Branche gekommen?
A. Schilken: Dazu muss ich etwas ausholen: Schon auf dem Gymnasium, der Hohen Landesschule in Hanau, hatte ich Gelegenheit mit Digitalelektronik und einem HP-Rechner Erfahrung zu sammeln. Unser sehr ungewöhnlicher Mathematiklehrer forderte von jedem Schüler ein Referat über ein Detail der Fortran Programmiersprache - das war 1974 nicht gerade üblich.
Ich beschloss also Physik- und Mathematiklehrer für Gymnasien zu studieren in der Hoffnung, dass ich so meine Interessen für Physik, Computer und Psychologie unter einen Hut bringen könnte. Ich spezialisierte mich auf "angewandte" Fächer, also Experimental- und angewandte Physik, sowie numerische Mathematik. Im Computerpraktikum ging es darum, Fortranprogramme in Lochkarten zu stanzen. Meine Examensarbeit im Labor der angewandten Physik war ein Glücksfall: Unter dem Thema "Mikroprozessorgesteuerte Störkörpermessungen an Hochfrequenzresonatoren" konnte ich meinem Hobby nachgehen und einen der ersten verfügbaren Mikroprozesoren programmieren.
Im Referendariat wurde diese Entwicklung aprupt gestoppt: Was sechs Jahre vorher an meinem Gymnasium üblich gewesen war, gab es an meiner Refenrendariatsschule überhaupt nicht - keinen einzigen Computer, obwohl 1981 schon einige kleine Rechner erhältlich waren. Nach der ersten Halbzeit meines Referendariats bewarb ich mich in der Industrie und trat meine erste Stelle als Systemprogrammierer an. Bei Linotype in Eschborn konnte ich meine Erfahrungen mit Machinensteuerungen nahtlos fortsetzen.
Ich arbeitete dort von 1982 bis 1986 und machte mich dann selbständig als EDV-Berater.
Projektleiter: In welchen Projekten haben sie mitgearbeitet, welche Entwicklungsumgebungen haben sie dabei eingesetzt?
A. Schilken: Mein letztes Projekt war die Referenzimplementierung einer sehr zeitkritischen Auftragserfassung. Es ging darum zu beweisen, dass eine J2EE-Architektur auch bei massivem Parallelbetrieb sehr gute Antwortzeiten liefern kann.
Aus Performanzgründen wurde auf Entitybeans verzichtet und statt dessen die Persistenz mit Oracle Toplink direkt in Sessionsbeans implementiert. Zum Nachweis diente eine JMeter-Testbean, deren Antwortzeit bei 300 parallelen Threads gemessen wurde. Weil der Kunde bereits JDeveloper einsetzt, nutzte ich ebenfalls diese IDE, die einige Vorteile bei der EJB-Codegenerierung hat.
Davor arbeitete ich in einem J2EE-Projekt, bei dem es um die Implementierung eines komplexen Fragebogens im Internet ging. Die Darstellungsschicht realisierte ich mit struts, wobei die Daten von mehreren Sessionsbeans eines Jboss-Applicationservers geholt wurden. Hier zeigte sich, dass auch ohne Entitybeans eine strukturierte J2EE-Anwendung bauen läßt.
Mein Einstiegsprojekt in Java war bereits 2000, das sagte ich ja vorhin schon.
Seit dieser Zeit habe ich, sozusagen als Training, einige J2ME-Anwendungen entwickelt: als erstes eine Handy-Version meines im Eigenverlag vertriebenen 1x1-Kartenspiels. Danach folgten weitere Anwendungen wie Tachometer, Sonnenkompass, Intelligenztest, Rechentraining und andere. Es ist eine Vorliebe von mir, mit einer Aktivität möglichst mehrere Vorteile zu erreichen.
Beispielsweise dienten diese Handyprogramme als Werbemittel für mein Kartenspiel, als Weiterbildung für die J2ME-Plattform, als Einarbeitung in die Eclipse IDE, als vorzeigbare Ergebnisse für mögliche J2ME-Projekte. Die meisten davon wurden in J2ME-Archiven als Freeware aufgenommen, beispielsweise in Archiv der Zeitschrift ct des Heise-Verlags. Auf meiner Website www.schilken.de liegen sie natürlich auch zum Download bereit.
Vor 2000 arbeitete ich mehrere Jahre an der Entwicklung einer Verkaufsoberfläche für den Ticketverkauf. Das war eine hoch optimierte Client/Server Anwendung in C++. Weil Clients per ISDN angeschlossen waren, mußte der Datenaustausch übers Netzwerk minimiert werden. Jeder Tastendruck wurde diskutiert, weil im Abendkassenverkauf einfach keine Zeit für Unnötiges ist.
Davor, also ungefähr zwischen 1989 und 92, sammelte ich Erfahrung im Großprojekt. Bei IBM in Niederrad arbeitete ich mit an der BTX-Software für die Vermittlungsstellen der Telekom. Eine meiner Aufgaben war die Statemachine für das BTX-Protokoll, also ein sehr technisches Thema. Wir waren mehr als 50 Mitarbeiter; ohne formale Code- und Fehlerverwaltung wäre hier gar nichts gelaufen. Ich glaube, in dieser Zeit habe ich gelernt, wie wichtig klar vorgegebene Methoden und funktionierende Tools sind.
Projektleiter: Vielen Dank für das Gespräch, Herr Schilken
A. Schilken: Ich sage immer: wenn mir 80% der Projektanforderungen bekannt sind und 20% neu, dann haben sie den Vorteil, dass ich schnell für sie produktiv sein kann und mir macht es Spaß, weil ich etwas Neues dazulerne. In ihrem Projekt scheint das so zu sein. Ich würde mich freuen, daran mitzuarbeiten.