Berlin fand ich spitze, aber da das hier kein Blog über Städtereisen ist, schreibe ich heute „nur” eine kurze Zusammenfassung dessen, was ich mit Nico und Frank auf der International PHP Conference Spring Edition 2010 und der Webinale 2010 erlebt und gelernt habe.

Die Workshops

Begonnen hat die Konferenz für mich mit einem Workshop am Sonntag nachmittag (morgens hatten wir eine Stadtrundfahrt, aber dazu wollte ich ja hier nichts schreiben). Der Workshop „Softwarearchitektur vs PHP” von Johann-Peter Hartmann war sehr unterhaltsam und mit der Vorstellung von ATAM (Architecture Tradeoff Analysis Method) habe ich auch etwas neues gelernt. Ich hatte zwar mit etwas mehr Inhalten zum Thema Architektur gerechnet und hätte auf den interaktiven Teil auch verzichten können, aber alles in allem war es ein interessanter Vortrag.

Montag

Der Montag startet mit zwei eher durchwachsenen Keynotes: Während der Vortrag „Die Mensch-Maschine-Beziehung und ihre Folgen” von Ibrahim Evsan unterhaltsam war, obwohl er nichts Neues erzählt hatte, war die Google-Keynote „Die Zukunft liegt in der Cloud” einfach nur langweilig. Der Gipfel war, dass Petra Sonnenberg zeigen wollte, wie in Zukunft alle unsere Applikationen in der Cloud laufen, gleichzeitig aber eine Präsentation mit Google Docs erstellt hatte, die aussah wie die ersten Gehversuche mit Power Point. Geendet hat die Keynote mit einem Werbevideo von Google. Nicht gerade das, was ich mir von einem Unternehmen wie Google versprochen hatte.

Danach kam das Highlight des Tages: Julian Koschwitz hat in seiner Session zu „Augmented Editorial Design” gezeigt, wie man klassische Printmedien mit dem Web verbinden kann und Magazine um dynamischen Content wie Videos oder Sound anreichern kann. Eine Webcam und ein Browser ist ausreichend. Ähnlich gut war die erste Session der IPC, die ich danach besucht habe. David Soria Parra hat sehr anschaulich dargestellt, wie „Git für Fortgeschrittene” Probleme beseitigt, die viele von uns mittlerweile mit Subversion haben.

Nachmittags ging es mit einem Vortrag zu „Continuous Integration und Continuous Deployment” von Manuel Pichler weiter, von dem ich mir auch mehr erhofft hatte. Manuel hat die zwar Bewegründe für CI und wie man es schrittweise einführt schön zusammengefasst, der Teil über Deployment ist leider sehr kurz ausgefallen und war für mich leider nicht hilfreich, da wir täglich und nicht nur wöchentlich deployen.

Abgeschlossen habe ich den Tag mit der für mich langweiligsten Session der Webinale: „Positive User Experience durch User Centered Web Design”. Meine Experience war in diesem Vortrag nicht sehr positiv, was zum Teil auch an der fortgeschrittenen Uhrzeit gelegen haben mag.

Dienstag

Der Dienstag morgen begann mit einem Vortrag zu „Frontend Performance mit PHP” von Frank und Nico, der sehr gut besucht war und mir auch noch ein paar neue Impulse gegeben hat, obwohl ich natürlich wußte, was auf mich zu kommt.

Da sich Jung von Matt für die aktuelle 1&1 Kampagne verantwortlich zeigt, habe ich mir danach die Session „Künftig entscheidend für den Erfolg (fast) jeder Marke: Produktinfo und -inszenierung” von Michael Behrens angeschaut. Die Beispiele, die er gezeigt hat, waren interessant, jedoch weit weg von dem, was JvM für 1&1 macht. Deutlich cooler waren auch die Beispiele, die Michael Chaize in seiner Session „Ten Innovative Projects for the Flash Platform” gezeigt hat. Von 3D-Grafiken über Gesichtserkennung bis hin zur Emulation von Spielekonsolen war da für jeden was dabei. Flash scheint (leider) trotz HTML5 immer noch nicht tot zu sein.

Durch das ständige Vertauschen von Sessions habe ich leider mittags einige Sessions verpasst und die Zeit genutzt, was für’s Büro zu programmieren. Abgeschlossen habe ich den Tag mit einer spontanen Session zu YQL von Yahoo!, in der leider nur die Standard-Beispiele gezeigt wurden.

Mittwoch

Den Mittwoch habe ich nach dem Hotel-Checkout wieder mit zwei Keynotes auf der Webinale begonnen. David Carr hat in seiner Keynote „The Speed of Now” den Namen zum Programm gemacht und ist extrem schnell durch eine Masse an Slides gegangen, so dass man ihm kaum noch folgen konnte. Ossi Urchs Keynote „Social Web oder Die neue Macht der Nutzer” klang eher nach einer Keynote von 2008 als nach einer Keynote in der man Trends für 2011 erfahren hätte. Das allgegenwärtige „Twitter, Facebook und Smartphones beherrschen unser Leben!” wurde am dritten Tag der Webinale dann doch etwas alt.

Danach fand die Panel Diskussion „Holy Code, holy Shit! – Die Developer-Designer-Hölle” statt, an der ich auch beteiligt war. Leider war es organisatorisch nicht möglich, dass sich alle Teilnehmer vorher treffen, so dass hier keine wirkliche Diskussion entstand und es eher bei „Thema verfehlt” einzuordnen war. Sollte ich jemals wieder an einer Panel-Diskussion teilnehmen, dann nur, wenn es vorher auch möglich ist, sich mit den anderen Teilnehmern und vor allem dem Moderator abzustimmen.

Nach der Mittagspause war ich dann mit meinem Vortrag „23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten” dran.

Der Vortrag lief gut, ich habe mir auch meinen „Cowboy/Indianer”-Witz merken können und das Feedback war durchweg positiv. Abgeschlossen habe ich den Tag mit einem Vortrag von Frank zum Thema „A better Approach for File System dependent tests”, in dem Frank sein Projekt vfsStream vorgestellt hat.

Zusammenfassend hat sich der Besuch der Konferenzen für mich mehr gelohnt, als das in den letzten Jahren der Fall war. Tatsächlich habe ich während der Konferenz jedoch festgestellt, dass mich die Themen der Webinale mittlerweile mehr fesseln als die Sessions auf der PHP Conference.

Leave the campground cleaner than you found it.

Genau an dem Tag, als ich den Eintrag schreiben wollte, kamen mir jedoch Nils und Holger zuvor. Mein erster Impuls war, meinen Eintrag einfach zu löschen und das Thema zu den Akten zu legen. Doch Schritt für Schritt (wer findet hier den Wortwitz?) bin ich wieder zu der Idee zurück gekehrt.

Die Überschrift „Kleine Schritte sind besser als keine Schritte” war das Motto von Willy Brandt (dt. Bundeskanzler von 1969 bis 1974), der damit seine Ostpolitik der langsamen Annäherung beschrieben hat.

Willy Brandt hat bei diesem Zitat sicher nicht an Uncle Bob, Coding Standards und kleine Refactorings gedacht. Sehr viele Entwickler, die sich die Pfadfinder Regel auf die Fahne schreiben, beschränken diese jedoch zu stark auf den Quellcode und wenden diese nicht ganzheitlich auf die eigene Arbeit und das Umfeld an. Richtig aufgefallen ist mir das auch erst in den letzten Wochen, in denen ich ausführlich mit Holger über Clean Code und die Einührung der Prinzipien in unseren Teams gesprochen habe.

Wenn Willy Brandt diese Regel auf eine Ostpolitik angewandt hat und damit eine Annäherung an Polen und die damalige Sowjetunion damit geschafft hat, dann sollten wir diese Regel auch in unserem täglichen Arbeitsumfeld anwenden können.

Ein gutes Beispiel ist, dass ich auf Konferenzen, auf denen ich über Clean Code, Testgetriebene Entwicklung und eine Menge andere „gute Dinge” geredet habe, am Ende immer gefragt werde, wie man diese in Teams einführt. Für die Teilnehmer sieht das immer nach einem großen Schritt aus, ein Team, das kein Verständnis für eine geminesame Code-Basis, Qualität und Entwicklungsmethodik hat, in ein Team zu transformieren, das bei der Entwicklung und der Pflege des Codes harmonisiert. Meine Antwort ist auch hier immer die selbe: Man muss es in kleinen Schritten angehen. Sie werden es nicht schaffen, das Bewußtsein für neue Entwicklungsmethodiken bei allen Teammitgliedern sofort zu wecken, also wecken Sie es bei einem und schauen Sie, wie es sich danach entwickelt.

Ähnlich verhält es sich bei der klassischen Beförderung vom Entwickler zum Leiter eines Entwicklungsteam. Sie können planen, wie Sie als perfekter Teamleiter sein könnten und diesen Plan dann in einem Jahr umsetzen. Oder Sie fangen morgen an und erledigen eine Teilaufgabe Ihres neuen Jobs mit Bravour und gehen dann die nächste an.

Sei es also ein neues Projekt oder ein neuer Job, der eine große Veränderung bedeutet, so ist der erfolgsversprechende Weg der, der mit vielen kleinen Schritten auf ein Ziel führt, das sich vielleicht sogar während des Wegs verändert.

Und wäre das nicht zu dramatisch für das Ende eines Blog-Artikels, würde ich jetzt schreiben:

Danke Willy Brandt. Danke Uncle Bob. Danke Holger.

Streng genommen ist das ja wahrscheinlich noch nicht mal Hip Hop sondern Rap. Und ein Hip Hop Fan bin ich eigentlich auch nicht.

Falls jemand meine Meinung zu HipHop For PHP hören möchte, ist die ganz einfach:

Facebook hatte ein Problem, Facebook hat das Problem gelöst. Jetzt stellt Facebook die Lösung noch jedem zur Verfügung, der sie nutzen möchte. So funktioniert Open Source. Also ist alles bestens.

Ich werde es wohl nicht nutzen, ich hab’ andere Probleme als Facebook.

Was ich jedoch versuche, an allen Stellen zu vermeiden, ist der schreckliche „not”-Operator, der in den meisten Sprachen durch den Einsatz von „!” implementiert wird. Der Einsatz dieses Operators macht den Quellcode immer schwerer zu lesen. Ich möchte keine Bedingungen wie die folgende in meinem Code haben:

if (!$this->isUserAuthenticated()) {
    $this->requireLogin();
}

So ein kleines Ausrufezeichen übersieht man einfach viel zu leicht und da es die Logik des Ausdrucks komplett umdreht, ist es einfach viel zu wichtig, um übersehen zu werden. Noch schlimmer wird es, wenn Sie den Operator mehrfach in einer Bedingung einsetzen.

if (!$this->isUserAuthenticated() && !$this->isInternalIP()) {
    $this->requireLogin();
}

In solchen Code-Stellen kommt es gerne auch mal vor, dass man UND mit ODER verwechselt. Denn wenn man etwas negieren möchte, sollte man dran denken, auch die Verknüpfung zu negieren oder entsprechend zu klammern. Die obige Bedingung ist mit der folgenden identisch, statt einem logischen UND verwenden Sie jedoch ein logisches ODER:

if (!($this->isUserAuthenticated() || $this->isInternalIP())) {
    $this->requireLogin();
}

Auf den ersten Blick erschließt sich mir nie, was die Bedingung aussagt, sobald ein „not”-Operator im Spiel ist.

Aber welche Möglichkeiten gibt es, um den ungeliebten Operator loszuwerden?

Verneinen Sie den Methodennamen

Statt einer Methode isUserAuthenticated() einen „not”-Operator voranzustellen, könnten Sie eine zweite Methode implementieren, die bereits auf das Gegenteil prüft und einen sprechenden Namen hat:

if ($this->isUserUnknown()) {
    $this->requireLogin();
}

So liest sich der gesamte Code viel flüssiger und es kann nicht dazu kommen, dass der Operator übersehen wird oder das Ergebis im Kopf evaluiert werden muss.

Prüfen Sie auf false

Statt den „not”-Operator zu verwenden, können Sie die Rückgabe der Methode auf false prüfen:

if (false === $this->isUserAuthenticated()) {
    $this->requireLogin();
}

Der Code ist zwar nicht so lesbar wie im vorherigen Beispiel, aber wenn Sie die Bedingung nur einmal prüfen müssen, kann es sinnvoll sein, auf die Implementierung einer Methode für diesen einen Fall zu verzichten. Achten Sie übrigens immer darauf, bei einer Bedingung den konstanten Wert auf der linken Seite der Klammer zu setzen. Sollten Sie zu wenige Gleichheitszeichen verwenden, so kann aus der Bedingung nicht aus Versehen eine Zuweisung werden.

Verwenden Sie unless

Sollten Sie Ruby verwenden, so haben Sie noch eine dritte, sehr elegante Möglichkeit. Ruby bietet Ihnen neben der if-Anweisung auch eine unless-Anweisung, die, wenn Sie sie als Modifier einsetzen, besonders elegant zu lesen ist.

require_authentication unless user_is_authenticated

In diesem Beispiel ist der Code kaum noch von einem englischen Satz zu unterscheiden. Unterstützt wird das natürlich noch dadurch, dass Sie in Ruby keine Klammern verwenden müssen, wenn Sie keine Parameter an eine Methode übergeben wollen.

Wenn Sie also das nächste Mal eine Bedingung negieren, dann denken Sie darüber nach, ob es keine bessere Lösung gibt. Und falls Sie in einer Bedingung zweimal negieren müssen, dann denken Sie nochmal über eine Alternative nach. Es gibt sie sicher.

Damit das anderen nicht auch so geht, versuche ich nochmal, zu rekapitulieren, welche Schritte dazu nötig waren:

1. Laden Sie den Ruby One-Click Installer 1.8.6 von der Ruby Website herunter.
2. Installieren Sie Ruby 1.8.6 (zum Beispiel in C:\ruby).
3. Laden Sie das Ruby 1.8.7 Binary von der Ruby Website herunter.
4. Entpacken Sie das Binary in den selben Ordner (C:\ruby), in den der Installer die Version 1.8.6 installiert hat.
5. Laden Sie ZLib Packages von der ZLib Website herunter und Entpacken Sie das Archiv.
6. Benennen Sie die Datei zlib1.dll nach zlib.dll um.
7. Kopieren Sie die Datei zlib.dll nach C:\ruby\bin.
8. Laden Sie libiconv 1.91 herunter und Entpacken das Archiv.
9. Kopieren Sie die Datei bin/iconv.dll nach C:\ruby\bin.
10. Laden Sie OpenSSL herunter und installieren es. Bei der Installation kann es sein, dass Sie aufgefordert werden, zuerst das Microsoft Visual C++ 2008 Redistributable Package zu installieren.

Damit sollte Ruby installiert sein. Überprüfen können Sie das einfach in der Konsole über:

C:\Users\schst> ruby --version
ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-mswin32]

Um Ruby on Rails zu verwenden, sollten Sie nun auch noch SQLite installieren. Während der Entwicklung können Sie Ihre Models sehr komfortabel in einer SQLite Datenbank persistieren. Sollten Sie SQLite noch nicht installiert haben, reichen dazu die folgenden Schritte aus:

1. Laden Sie die vorkompilierte Verson für Windows herunter.
2. Entpacken Sie das Archiv
3. Kopieren Sie die Datei sqlite3.exe nach C:\ruby\bin.

Als nächstes können Sie sich nun daran machen, den gem Installer für Ruby zu installieren:

1. Laden Sie die aktuelle Version von RubyForge herunter.
2. Entpacken Sie das Archiv.
3. Führen Sie ruby setup.rb aus.

Alle weiteren Schritte erledigt nun gem für Sie:

C:\Users\schst>gem install rails
C:\Users\schst>gem install sqlite3-ruby

Danach können Sie mit Ihrer ersten Ruby on Rails Applikation loslegen:

C:\Users\schst> rails my-app
C:\Users\schst>     cd my-app
C:\Users\schst>     ruby script/server

Ihre Anwendung öffnen Sie nun im Browser über http://localhost:3000.

Artikel der Serie "23 Dinge"

1. 23 Dinge über Software-Entwicklung in Teams
2. 23 Dinge #0: Menschen

Bevor ich über 23 Dinge blogge, möchte ich noch einen Artikel voran stellen, der die folgenden Artikel meiner Serie in einen entsprechenden Kontext setzt. Sie bekommen hier sozusagen einen Tipp, wie Sie die folgenden Tipps anwenden sollten.

Beginnen möchte ich mit einem Yogiism von Dale „Yogi” Berra, einem der erfolgreichsten Baseball-Spieler der US-Major League:

„In theory, there is no difference between theory and practice. In practice, there is.”

Frei übersetzt bedeutet dies so viel wie:

„In der Theorie sind Theorie und Praxis das selbe, in der Praxis sind sie es nicht.”

Meine 23 Dinge, die Sie über Software-Entwicklung ins Teams wissen sollten, entspringen zwar meiner praktischen Erfahrung, aber in diesem Blog werden sie auf Theorien reduziert. Die Tipps haben mir in den Teams, in denen ich bereits gearbeitet habe (sowohl in geschäftlichen, als auch im Open Source Umfeld), wertvolle Dienste geleistet. Das bedeutet jedoch nicht zwangsläufig, dass diese Tipps sklavisch bei Ihnen angewendet werden sollten. Manche Tipps müssen vielleicht an ihr Umfeld angepasst werden, andere funktionieren in Ihrem Umfeld überhaupt nicht.

Sobald Sie von Teamarbeit sprechen, sollten Sie nicht vergessen, dass es dabei auch immer um Menschen geht. Die Menschen sollten immer im Mittelpunkt Ihrer Bemühungen stehen, denn sie sind es, die Ihr Team formen und am Ende die Software produzieren.

Und Menschen sind nun mal verschieden. Also sind auch Teams verschieden und werden nicht genau gleich auf die Tipps in dieser Artikelserie reagieren. Achten Sie also beim Umsetzen der Tipps darauf, dass Ihnen nicht der Fehler auf diesem Poster passiert:

Schätzen Sie die Unterschiedlichkeit Ihres Teams und wenn ein Tipp nicht zu Ihnen oder Ihrem Team passt, dann passen Sie ihn an. Dieses Poster hängt im Büro übrigens auch in DIN A1 an meiner Wand, um mich und andere jeden Tag daran zu erinnern.

„PHP Design Patterns” ist das erste deutschsprachige Buch zu Entwurfmustern in PHP. Neben einer Einführung in objektorientierte Programmierung im Allgemeinen und mit PHP im besonderen (Kapitel 1) sowie einem kurzen Ausflug in die SPL (Kapitel 2), zeigt das Buch auf grundlegende Regeln für gutes Software Design wie z.B. „Vererbung sorgt für starre Stukturen. Verwenden Sie stattdessen Objektkomposition, um verschiedene Funktionen einfacher miteinander kombinieren zu können.” Kapitel 3 behandelt weiterhin auch Fluent Interfaces und Dependency Injection, samt der Verwendung des DI-Containers in Stubbles.

Kapitel 4,5 und 6 behandeln dann einige der Standard Gang of Four Entwurfsmuster, wie Abstract Factory, Prototype, Composite, Facade, Flyweight, Command, State oder auch Chain-of-Responsibility. Die letzten beiden Kapitel stellen das Schichtenmodell vor und zeigen, wie man dies mit Hilfe eines Model-View-Controllers und Patterns wie Active-Record, Template-View, Registry oder auch Event-Dispatcher implementiert.

Das PHP Magazin schreibt zur ersten Auflage (1/2007):

Ein rundes, das anvisierte Themengebiet hervorragend ausfüllendes Buch, das vom Leser nur eins verlangt: Zeit und Konzentration auf den Inhalt. Der Lohn dieser geringfügigen Investition sind verschiedenste Aha-Effekte und ein echter Schub an neuen Kenntnissen und Ideen. Und ein Nachschlagewerk, das man nach dem ersten Lesen nicht mehr vom Schreibtisch nehmen möchte.

Das Buch wurde für die zweite Auflage komplett überarbeitet und an PHP 5.3 angepasst. Dabei wurde ein Großteil der Kapitel erweitert:

• Komplett neue Abschnitte zu Namespaces, Late Static Binding und Closures
• Neuer Abschnitt zur SPL_Types Erweiterung
• Komplett neuer Abschnitt zu Fluent Interfaces
• Komplett neuer Abschnitt zu Stubbles Depencency Injection
• Neue Pattterns: Prototype, Facade, Flyweight, State, Chain of Responsibility, Identity Map und Data Mapper

Details zu Buch:

• Gebundene Ausgabe: 496 Seiten
• Verlag: O’Reilly; Auflage: 2. Auflage (27. Februar 2009)
• Website zum Buch unter www.phpdesignpatterns.de
• „PHP Design Patterns” auf der O’Reilly Website
• Buch bei Amazon bestellen

Das in einem Projekt nach dem Release nochmal Bugs auftreten, ist nicht wahrscheinlich, es ist absolut sicher. Meist haben diese Bugs dann eine (negative) finanzielle Auswirkung, oder zumindest ist das die Vermutung des Kunden. Der Kunde befürchtet einen Verdienstausfall, der natürlich so kurz wie möglich gehalten werden muss; und das rationale Denken beim Kunden, Manager und Entwickler setzt leider allzu häufig aus.

Die pragmatischen Programmierer Andrew Hunt und David Thomas haben einige Tipps, wie man sich bei der Fehlersuche verhalten sollte:

Lösen Sie das Problem, nicht die Schuldfrage.

Der Bug ist bereits aufgetreten, es wird Ihnen jetzt nichts helfen, wenn Sie wissen, wer Schuld daran ist. Leider ist es oft viel einfacher, rauszufinden, wer schuld ist, als rauszufinden, wie der Bug gefixt werden kann. Deshalb tendieren viele Menschen eher zur ersten Alternative. Was man dagegen tun kann, habe ich bereits in „Denk positiv!” geschrieben.

Wenn Sie auf Grund von Verträgen oder SLAs wissen müssen, wer die Schuld trägt, so ist für die Klärung dieser Frage nach Beseitigung des Fehlers noch genug Zeit.

Keine Panik!

Wenn man so schnell wie möglich versucht, den Bug zu fixen, ohne genauer darüber nachzudenken, ist die Gefahr groß, dass weitere Bugs ins System eingeführt werden, während einer behoben wird. Und natürlich fügen diese Bugs Ihrem Kunden meist einen noch größeren Schaden zu, als der ursprüngliche Bug.

Das absolute Highlight ist, dass in solchen Situationen gerne auch die Unit-Tests (die Folgefehler entdeckt hätten) vor dem Deployment übersprungen werden, um den Fix möglichst schnell live zu bekommen. Näher werden Sie Kamikaze in Ihrem Leben wahrscheinlich nicht kommen. Ich selbst war leider schon so nahe dran.

Bleiben Sie also ruhig und stellen Sie sicher, dass Sie eine saubere Entwicklunsumgebung haben, bevor Sie mit dem Bugfixing beginnen. Fixen Sie den Bug also nicht in einem lokalen Checkout, der Modifikationen enthält, die noch nicht deployed wurden.

Wenn Sie Hufabdrücke sehen, sollten Sie an Pferde denken, nicht an Zebras.

Wenn ein Fehler auftritt, nachdem Sie den Code geändert haben, dann ist es wahrscheinlich, dass Ihre Änderung den Fehler verursacht hat. Suchen Sie also dort. Entwickler sind gerne der Ansicht, dass die letzte Änderung so marginal war, dass sie keinen Fehler verursacht haben kann. „Sicher muss es ein Problem im Kernel sein, dass nur Donnerstags bei Regen auftritt und deshalb nicht entdeckt wurde.” Sehr wahrscheinlich ist das nicht das Problem, sondern die marginale Änderung war der Auslöser.

(Die einzige Ausnahme von dieser Regel ist, wenn Sie mit Destrukturen in PHP arbeiten, hier habe ich schon Phänomene erlebt, die nur von Scully und Mulder gelöst werden können. Beim Einsatz von Destruktoren in PHP gilt also – Trust No One.)

Nicht annehmen, sondern beweisen.

Obwohl ein Bug einem Entwickler beweist, dass er nicht unfehlbar ist, verhält man sich oft weiterhin so, als wäre man unfehlbar. Ein Entwickler nimmt dann bei der Fehlersuche einfach an, dass eine bestimmte Methode auf jeden Fall fehlerfrei funktioniert und überspringt diese beim Debuggen. Tun Sie das nicht. Prüfen Sie jede kleine Eventualität, jede noch so einfache Methode und beweisen Sie, das diese mit den Eingaben, die produktiv zu einem Fehler führen, korrekt arbeitet. Auch dieses Thema hatte ich bereits in „Don’t assume!” tiefergehend diskutiert.

Wenn Sie diese einfachen Regeln befolgen, dann haben Sie beim nächsten Bug deutlich höhere Chancen, diesen schnell, nachhaltig und ohne Folgefehler zu beseitigen.

In regelmäßigen (oder wahrscheinlich eher unregelmäßgen) Abständen werde ich diese jetzt auch in meinem Blog posten. Ihr findet diese Artikel dann alle unter dem Tag „An meiner Wand”. Den Anfang macht heute die folgende Weisheit von Oscar Wilde:

Don’t assume – it makes an «ass» of «u» and «me».

Auf den ersten Blick klingt das in der Software-Entwicklung etwas seltsam, da wir alle wissen, dass in kaum einem Software-Entwicklungsprojekt immer alle Anforderungen klar auf dem Tisch liegen. Dabei bleibt uns als Entwicklern oft nichts anderes übrig, als Annahmen zu treffen.

Wichtig ist aber, dass man sich in solchen Moment bewusst sein muss, wo man nur Annahmen trifft. Sonst macht man ganz plötzlich Annahmen, von denen man annimmt, dass es Fakten sind. Und nichts ist schlimmer, als Annahmen über Annahmen zu treffen.

Und genau da beginnt das Problem. Sie treffen Entscheidungen auf Basis von Fakten, die nur in Ihrer Vorstellung existieren. Typische Annahmen, die zu Problemen führen sind:

• „Ich denke nicht, dass der Kunde diese Anforderung nochmal ändern wird. Die ist in Stein gemeißelt.”
• „Unsere Applikation ist so langsam, weil wir Datenbank XXX verwenden, wir müssen stattdessen die Datenbank YYY einsetzen.”

Während die erste Annahme dazu führt, dass Sie dem Kunden Flexibilität nehmen, investieren Sie bei der zweiten Annahme Zeit und Aufwand in eine Optimierung, die unter Umständen unnötig ist. Damit landen Sie nämlich bei Premature Optimization, und darüber hat Donald Knuth mal gesagt:

Premature optimization is the root of all evil.

Bevor Sie also annehmen, dass ein Kunde eine Anforderung in Stein gemeißelt hat und darauf hin eine Architektur-Entscheidung treffen, sprechen Sie doch lieber mit dem Kunden darüber. Erklären Sie ihm zur Not auch, welche Vor- und Nachteile hat, wenn er genau diese Anforderung unumstößlich festlegt und Ihnen damit eine bestimmte Architekturentscheidung ermöglicht.

Und bevor Sie annehmen zu wissen, wo das Performance-Problem Ihrer Anwendung liegt, fragen Sie doch einfach einen Profiler und stützen Ihre Entscheidungen auf Fakten.

Da ich mich für einen leidenschaftlichen Programmierer halte, habe ich mir mal Gedanken dazu gemacht, ob ich diesen Tipp in meiner bisherigen Laufbahn befolgt habe. Dabei kam ich auf die folgende Liste von Programmiersprachen, die ich bisher gelernt habe:

• 1987: Basic
  Damit hat wohl jeder angefangen. Bei mir war es hauptsächlich die Grafik-Programmierung auf meinem Commodore 128D.
• 1990: Amiga Basic
  Nachdem ich dann einen Amiga 500 hatte, ging es natürlich mit Amiga Basic weiter.
• 1990: Assembler
  Demo-Programmierung auf dem Amiga 500 und 1200 war einige Jahre meine größte Liebe. Man findet heute sogar noch Demos von mir im Netz.
• 1991: ARexx
  In ARexx habe ich etwas geschrieben, was man heute wohl als Chat-Bot bezeichnen würde. User, die sich auf unser BBS eingewählt haben, dachten, sie chatten mit unserem Admin, haben sich aber nur mit meinem Programm unterhalten.
• 1992: Turbo Pascal
  Musste ich zwangsläufig in der Schule lernen, hat mich jedoch nie wirklich begeistert.
• 1994: Gopher
  Im ersten (und einzigen) Semester meines Informatik-Studiums, seltsamerweise konnte ich im Netz gar nichts mehr dazu finden.
• 1997: Visual Basic
  Das musste ich lernen, als ich eine Software, für den Comic-Laden, in dem ich gejobbt habe, in Access umgesetzt habe. Es war besser, als es klingt.
• 1998: HTML
  Ich hatte das Internet entdeckt.
• 1998: JavaScript
  Und ich hatte entdeckt, dass Webseiten auch interaktiv sein können.
• 1998: PHP3
  Und dann hatte ich entdeckt, dass Daten für Webseiten aus Datenbanken kommen sollen.
• 2000: PHP4
  Da bin ich dann ziemlich lange bei PHP hängen geblieben.
• 2001: ActionScript
  Wer zu dieser Zeit in einer Agentur gearbeitet hat, kam nicht drum rum, auch mal in Flash zu programmieren.
• 2002: XSLT
  Die Vermischung von Content, Layout und Logik hat mir noch nie gefallen, also musste ich was dagegen tun.
• 2004: C
  Und wollte natürlich auch mal eine Extension für PHP schreiben. Das hat zwar funktioniert, aber trotzdem habe ich C ziemlich schnell wieder aufgegeben.
• 2004: PHP5
  Und immer die aktuellste PHP Version einsetzen.
• 2005: Java
  Habe ich ursprünglich nur gelernt, weil ein Kollege der Meinung war, man könne eine PHP-Anwendung von mir nicht in Java schreiben und ich ihn vom Gegenteil überzeugen wollte. Mittlerweile fühle ich mich in Java mindestens genauso wohl, wie in PHP.
• 2009: Groovy
  Irgendwann wollte ich doch mal ausprobieren, wie es sich anfühlt, die Stärken von PHP und Java zu vereinen. Leider hat es sich für mich nicht so besonders angefühlt und besonders viel Code ist nicht dabei raus gekommen.

Wenn ich alles zusammenrechne, so schaffe ich es in 22 Jahren auf 17 Programmiersprachen, ich hatte also 5 leidenschaftslose Jahre. Ich hoffe mal, Mr. Fowler sieht das nicht so eng.

Tatsächlich hatte ich 1995 meine lang geplante Entwicklerlaufbahn an den Nagel gehängt und mich stattdessen für ein Pädagogik-Studium entschieden. Der Weg zurück zur Entwicklung war nicht sehr linear und hat gut 2 Jahre gedauert.

Doch nun haben wir 2010, wie soll es also weiter gehen? Weiter geht es dieses Jahr mit Ruby; das Buch dazu habe ich heute bestellt. Es ist also nicht auszuschließen, dass Sie bald an dieser Stelle auch Artikel zu Ruby finden werden. Das wiederum wird Mr. Fowler sicher gefallen, schließlich ist der einer der Mitbegründer von Ruby Central.