Die Fehler von Microsoft

Auf der ix-Konferenz war ich heute morgen in der Session "Die Fehler von Microsoft" von Andreas Zeller (Universität des Saarlandes). Dabei ging es um die Frage, ob und wie man Fehlerhäufigkeit bestimmter Module vorhersagen kann, um diese besonders intensiv zu testen. Andreas Zeller hat dazu Untersuchungen an Microsoft- und Eclipse-Modeulen durchgeführt. Der Vortrag war nicht nur gut vorgetragen, sondern transportierte auch ein paar interessante Erkenntnisse:

1. Wenn ein Modul in der Vergangenheit sehr fehlerträchtig war, wird es auch in Zukunft fehlerträchtig sein.


2. Mit Metriken kann man nicht universell vorhersagen, welche Module besonders fehlerträchtig sein werden. Zitat Zeller: "Das ist ein herber Schlag für die Metrik-Community. Ein Glück, dass ich nicht dazu gehöre."


3. Man kann je Produkt (z.B. Microsoft Internet Explorer) Metriken definieren, die ganz gut funktionieren. Dazu braucht man aber Zahlen aus der Vergangenheit. Damit ist das Verfahren nur sinnvoll für neue Module in einem bestehenden Produkt. Für die existierenden Module in einem bestehenden Produkt haben wir ja Erkenntnis Nummer 1.


4. Die erfahrensten Entwickler machen die meisten Fehler. So hat angeblich Erich Gamma eine der höchsten Fehlerraten im Eclipse-Projekt. Und Module, die sehr viele Unittests haben, sind sehr fehleranfällig. Das liegt daran, dass die erfahrenen Entwickler immer nach vorne geschickt werden, wenn es brenzlig wird. Und die Entwickler schreiben dort viele Unittests, wo sie viele Probleme vermuten. Das bedeutet, dass die Entwickler unabhängig von Metriken eigentlich ganz gut wissen, wo die fehlerträchtigen Module rumlungern. Dann kann man sich doch auch einfach an deren Einschätzung orientieren.

Weitere Informationen zu dem Thema finden sich unter www.softevo.org.

Post bewerten

Gute Entwickler

Bei den XP-Days war es bei der Fishbowl-Session zu Agile 2.0 explizit ein Thema, bei anderen Vorträgen stand die Frage implizit im Raum: Wie wird man eigentlich ein guter Entwickler?
Es rief keinen Widerspruch hervor, als ich behauptet habe, die Unis würden keine nennenswerten Programmierfähigkeiten vermitteln. Ich finde das absurd: Wenn etwas im Kern aller Einzeldisziplinen der Informatik steht, dann doch wohl Programme und die muss doch auch jemand programmieren. Aber im Moment sind die Unis wohl nicht der Ort, um ein guter Programmierer zu werden. Also muss man das Programmieren wohl außerhalb der Uni lernen. Da gibt es zwei Möglichkeiten: Neben dem Studium oder nach dem Studium. Im Autismus-Mode wird das nur begrenzt gehen: Man braucht Partner, von und mit denen man lernen kann.
Da finde ich es sehr schön, dass vermehrt Lernformen auftreten, die genau das ermöglichen: Programmieren lernen.

• Im Coding-Dojo lernt man durch Beobachten anderer Entwickler das Programmieren. Das kann mit oder ohne Pair-Programming und mit oder ohne testgetriebener Entwicklung (TDD-Dojo) geschehen.


• Im Coding-Tournament treten Programmierpaare gegeneinander an, um Bots zu programmieren, die dann gegeneinander spielen - im Fall der XP-Days Indian Poker.

Ich habe jetzt ein paar solcher Veranstaltungen selbst mitgemacht/veranstaltet und habe erlebt, wieviel man dort in sehr kurzer Zeit lernen kann - und das mit jeder Menge Spaß. Ich halte Coding-Dojos und Coding Tournaments auch für eine Klasse Idee, um sie innerhalb von Firmen zur internen "Weiterbildung" durchzuführen.
Ein TDD-Dojo bieten übrigens Henning Wolf und ich gemeinsam auf der ix-Konferenz in Frankfurt am 30.11.06 an.

Post bewerten

NEZIAK als neue Methode der Softwareentwicklung?

Gestern haben wir bei Hennings Geburtstagsparty in ausgelassener Stimmung unsere Gedanken schweifen lassen und sind dabei auf NEZIAK gestoßen. Zu NEZIAK kommt man, wenn man KAIZEN (kontinuierliche Verbesserung in kleinen Schritten) umgedreht aufschreibt. Inhaltlich bedeutet NEZIAK entsprechend die kontinuierliche Verschlechterung in kleinen Schritten :-)
Ist natürlich offensichtlicher Blödsinn... Allerdings habe ich den Eindruck, dass viele Projekte konsequent NEZIAK einsetzen. Nanu? Wer macht denn etwas offensichtlich Blödsinniges und warum?

Post bewerten

XP-Days 2006 in Hamburg sind vorbei

Die XP-Days 2006 in Hamburg sind vorbei. Sie haben mir gut gefallen. Die Vorträge waren im wesentlichen gut bis sehr gut und ich habe alte Bekannte wieder getroffen. Schon während der Konferenz konnten die Teilnehmer bloggen. Inzwischen trudeln auf dem Konferenzblog auch die Folien zu den Vorträgen ein.

Post bewerten

Wie schwer kann es sein, ein PDF mit Java zu drucken?

Eigentlich ist es ganz einfach, haben wir uns gedacht. Aber nichts da. Man kann zwar mit allen möglichen Programmen PDFs erzeugen, aber die PDFs dann automatisch an einen Windows-Drucker zu schicken, scheint noch ein offenes Forschungsthema zu sein.
Unser erster Anlauf ging über die Java Printing Services. Laut API-Doku ist es ganz einfach. Man sagt mit dem PDF-Flavor, dass man ein PDF drucken will und fertig. Dummerweise hat Sun den PDF-Flavor nicht implementiert. Man hofft wohl, dass das jemand anderes tut. Wir konnten aber niemanden finden, der es auch getan hat.
Zwischenzeitlich hatten wir dann ein BAT-Programm gefunden, dass schwindelerregende Dinge mit der Registry tut. Das haben wir aber nicht zum Laufen bekommen, außerdem braucht es Admin-Zugang auf dem PC der Anwender und das ist bei Unternehmenssoftware eher nicht angesagt.
Schließlich hat uns das kommerzielle JNIWrapper aus der Klemme geholfen.
Aus dem gleichen Stall stammt übrigens auch JExplorer, mit dem man den MS-Internet-Explorer nahtlos in Swing-Anwendungen einbetten kann.

Post bewerten

Java-Script auf dem Server

Bei aktuelllen Web-Anwendungen hat man immer Java-Script auf dem Client. Die AJAX-Frameworks versuchen, diese Tatsache zu verstecken, so dass man nur mit der einen serverseitigen Programmiersprachen arbeiten muss.
Wenn es anspruchsvoll wird, reichen die Frameworks aber nicht mehr aus und man muss doch wieder Java-Script für den Browser programmieren. Wäre es da nicht viel eleganter Java-Script auch auf dem Server einzusetzen und damit nur eine Programmiersprache benutzen zu müssen? Schließlich braucht sich Java-Script bzgl. der Sprachkonstrukte eigentlich nicht verstecken hinter anderen Script-Sprachen.
Siehe dazu Phobos.

Post bewerten

Unit-Testing in Multi-Projekt-Settings mit JUnit 4

Die von mir zitierte Lösung für Unit-Testing in Multi-Projekt-Settings funktioniert nur für JUnit 3.8, aber nicht für JUnit 4. Johannes Link hat die Lösung für JUnit 4 adaptiert.

Post bewerten

Newsfeed zieht um

Der Newsfeed zu diesem Blog wird umziehen nach: http://stefanroock.blogspot.com/rss.xml

Post bewerten

Unit-Testing in Multi-Projekt-Settings

Die Eclipse-IDE bietet sich an, um ein Gesamtprojekt in mehrere Subprojekte/Komponenten zu unterteilen. Die Abhängigkeitsverwaltung in Eclipse sichert dabei, dass man keine ungewollten Abhängigkeiten in sein System einbaut.
Unverständlicherweise kann man in Eclipse aber nicht Unit-Tests über mehrere Projekte auf einmal ausführen. Wenn man sehr viele Projekte in Eclipse hat, wird das Ausführen der Unit-Tests zur echten Qual.

Aber es gibt eine ganz einfache Lösung über eine generische Test-Suite, die einfach alle Tests im Classpath ausführt. Den Code (< 100 Zeilen) dazu findet man bei Björn Martensson.

Post bewerten