Archiv für Januar 2010
Skateboard für’s Wohnzimmer
09. Jan
Gesehen bei Amazon.de und seit dem 24.12. auch in unserem Wohnzimmer. Leider hat Holger uns alle abgezockt, was nach fünf Jahren echtem Skaten eine Schande ist.
Tatsächlich ist das aber weitaus näher am echten Skateboard-Gefühl dran, als ich erwartet hätte. Und wie beim echten Skaten, macht mit der Airwalk den meisten Spaß.
Happy Birthday, Elvis!
08. Jan
Zur Feier von Elvis‘ 75. Geburtstag gibt’s heute noch ein klassisches Video.
In case of emergency…
08. Jan
Entwickler sind Menschen. Fehler passieren. Und wenn Entwicklern ein Fehler passiert, dann nennt man das Bug.
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.
Denk positiv!
07. Jan
Unter dem Tag „An meiner Wand” publiziere ich Weisheiten, die mir so wichtig sind, dass sie bei mir im Büro an der Wand hängen. Heute habe ich allerdings eine Weisheit, die nicht an meiner Wand hängt, sondern, die auf einem kleinen Zettel steht, den ich immer in der Innentasche meines Jacketts mit mir rumtrage.
Denk positiv, Du Idiot!
Dieser soll mich regelmäßig dran erinnern, beim Auftreten eines Problems, positiv zu denken, anstatt mich auf den negativen Aspekt zu fokussieren. Beispiele für solche Situationen, in denen ich oft zum negativen Aspekt tendiere, bis mich mein Jackett umstimmt, sind:
- Ein Bug ist aufgetreten. Statt eine Lösung zu suchen, hält man sich mit der Klärung der Schuldfrage auf.
- Ein Kunde ist mit dem gelieferten Ergebnis, das genau den Anforderungen entspricht, nicht zufrieden. Statt einen Kompromiss zwischen neuen Anforderungen und Umsetzbarkeit zu suchen, wird darüber diskutiert, dass alle Anforderungen korrekt umgesetzt wurden. Das macht den Kunden unglücklich und mein Glück ist nun mal eng mit dem Glück des Kunden verbunden.
- Eine Schnittstelle wird nicht rechtzeitig und wie vereinbart geliefert. Statt nach einer Lösung zu suchen, wie die weitere Zeitplanung eines unverschiebbaren Projektes noch eingehalten werden kann, wird darüber diskutiert, warum es zur Verschiebung kam und dass dadurch der unverschiebbare Zieltermin eben doch verschoben werden muss.
Nüchtern und objektiv betrachtet, wissen wir alle, wie man sich in solchen Situationen verhalten muss, um das Beste daraus zu machen. Befinde ich mich aber subjektiv und emotional in einer solchen Situation, bedarf es oft eines Außenstehenden, der mich daran erinnert, wie ich mich eigentlich verhalten möchte. Dieser Außenstehende bin ich durch meinen Zettel selbst, eben nur mit einer Erinnerung aus der Vergangenheit.
Dank gebührt hierbei auch Stefan Schopohl, der „Denk positiv, Du Idiot!” für mich gestaltet, ausgedruckt und ausgeschnitten hat, nachdem ich immer nur davon geredet habe.
Frisch im RSS-Reader
06. Jan
Seit ich mich entschlossen habe, selbst aktiv zu bloggen, habe ich auch wieder angefangen, regelmäßig andere Blogs zu lesen. Neu in meinem RSS-Reader sind jetzt:
Frank Westphal
Mit seinem Buch „Testgetriebene Entwicklung mit JUnit und FIT” verfolge ich in unregelmäßigen Abständen, was Frank Westphal veröffentlicht. Auf seiner Website veröffentlich er interessante Artikel zum Extreme Programming, Agiler Entwicklung und Qualitätssicherung. Seinen Podcast „Tonabnehmer” habe ich mir bislang noch nicht angehört, wären aber sicher ein guter Grund, Podcasts endlich mal auszuprobieren.
Neal Ford
Neal Ford ist Meme Wrangler bei Thoughtworks. Auf ihn bin ich bei einer Keynote auf der Dynamic Languages World aufmerksam geworden. Am meisten beeindruckt hat mich damals (und auch heute noch) sein Satz
Simplify essential complexity; diminish accidental complexity.
Diesem Satz hatten Holger Rüprich und ich auch eine unserer neun Regeln in unserem Workshop „Die Kunst des Software Design” auf der PHP World 2009 gewidmet.
Ludwig Ostrowski
Auf das Blog von Ludwig Ostrowski bin ich nur per Zufall (aka Twitter) gestolpert. In meinen Reader hat er es aus zwei Gründen geschafft:
- Seine neusten Einträge befassen sich mit Dependency Injection (und sogar PHP und Google Guice, meine Lieblingsthemen bei DI), Continuous Integration und Sonar. Alles Themen, die mich auch schon seit einiger Zeit fesseln.
- In seinem Blog zitiert er Martin Fowler mit einem meiner Lieblingszitate.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Ich werde das Blog auf jeden Fall mal im Auge behalten.
David Seah
Zum Abschluss noch ein Blog, das nichts mit Software-Entwicklung zu tun hat. David Seah schreibt über Design und Produktivität und kombiniert beides, in dem er wunderschöne Vordrucke für Tasklisten oder auch Ressourcenplanung zum kostenlosen Download anbietet. Zusammengefasst werden diese unter dem Namen „The Prinable CEO”, den David Seah wie folgt erklärt:
The Printable CEO name comes from the idea that a good CEO should focus primarily on those things that move the company forward; since I can’t afford to hire my own CEO, being able to print one out seemed like the next best thing!
Die Feeds
Things to make and do in London
05. Jan
Im Februar geht es endlich mal wieder nach London. Und dieses Mal habe ich Google Maps für die Shopping-Planung entdeckt. Ich bin einfach entzückt, was die alles möglich machen. Dafür gebe ich gerne meine Privatsphäre auf.
Don’t assume!
05. Jan
Manche Weisheiten sind so einfach, dass man sie immer wieder vergisst. Aus diesem Grund hänge ich mir solche gerne bei mir im Büro an die Wand, damit ich regelmäßig mit der Nase drauf gestoßen werden.
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.
Yoda Desk Protector
04. Jan
Gefunden bei mikfunshopping.de, und seit einer Woche bei mir auf dem Schreibtisch.
Jedes Jahr eine neue Programmiersprache
04. Jan
Chad Fowler schreibt in seinem Buch „Der leidenschaftliche Programmierer” (im Original „The Passionate Programmer”), dass man jedes Jahr eine neue Programmiersprache lernen sollte.
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.
23 Dinge über Software-Entwicklung in Teams
03. Jan
Artikel der Serie "23 Dinge"
- 23 Dinge über Software-Entwicklung in Teams
- 23 Dinge #0: Menschen
Auf der PHP World 2009 in München habe ich einen Vortrag mit dem Titel „23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten” gehalten.
Der Vortrag war gut besucht und ein voller Erfolg. Um die Inhalte einer breiteren Öffentlichkeit zugänglich zu machen, werde ich in den nächsten Wochen jedes der 23 Dinge heraus greifen und in einem Eintrag in meinem Blog genauer betrachten. Eine feste Timeline gibt es dafür nicht, genau so könnte es sein, dass ich die Reihenfolge vom Vortrag abweichen wird.
Xing
LinkedIn
Twitter
Ohloh
Slideshare
Facebook
Delicious
Github
Technorati
Flickr
Last.fm
YouTube
Amazon Wishlist