Die Fehler von Microsoft Thu, Mar 1. 2007
Durch Zufall habe ich gerade noch rechtzeitig von einem Vortrag von Prof. Andreas Zeller von der Universität des Saarlandes (Saarbrücken) erfahren.
Ich hatte vor vielen Jahren mal einen kurzen, aber sehr netten E-Mail-Kontakt mit Andreas Zeller. Ich habe damals einige LaTeX-Klassen für Online-Präsentationen (wie beamer, foiltex, prosper, ...) getestet und bin dabei auch auf stslide von Andreas gestoßen. Das Paket hat mir gefallen und Andreas reagierte auf eine Rückfrage prompt und sehr freundlich.
Erst später ist mir aufgefallen, dass er einer der Hauptautoren von DDD ist (dem Data Display Debugger - eines der Frontends für gdb und Co.) und ich auch ein Buch von ihm im Regel stehen habe.
In Programmierwerkzeuge gibt er eine Einführung und Tipps anhand von praktischen Beispielen zu diversen Unix-Entwicklungstools wie diff, patch, make, lex, yacc, autoconf, lint, gdb, ddd, gprof, ...
Das Buch ist zwar nett und vermittelt einen brauchbaren überblick über die wichtigsten Entwicklungstools und -methoden, dennoch möchte ich es an dieser Stelle nicht empfehlen. Denn das meiste kennt man schon und den Rest erfährt man mit etwas Aufwand auch günstiger aus dem Netz und den allgemein verfügbaren Dokumentationen. (Es gibt übrigens auch eine 2. Auflage: "Open-Source-Programmierwerkzeuge", 2003)
Ich wusste, dass sich sein Forschungsschwerpunkt hauptsächlich um Debugging- und Programm-Analyse -Techniken dreht, weshalb ich den Ankündigungstext auch gar nicht richtig gelesen hatte - der Name langte mir um einen Interessanten Vortrag zu erwarten.
Andreas Zeller hat diesen Vortrag in den letzten Monaten schon oft an verschiedenen Unis, Tagungen und Konferenzen gehalten - diese Erfahrung merkte man dem Vortrag auch deutlich an. Zudem verwendet er ein schwarzes MacBook und dazu Apples Präsentationssoftware Keynote - wodurch die visuelle Aufbereitung des Inhaltes alleine schon den Besuch wert war. Das geht ganz stark in die Richtung von Steve Jobs und Lawrence Lessig.
Es waren sehr viele Professoren von verschiedenen Informatik-Instituten anwesend, was mir sehr gefallen hat. Ich hoffe mal, dass der eine oder andere auch einige Impulse - trotz unterschiedlicher Vorraussetzungen (Stichwort: "Folien als Skriptenersatz") - für den eigenen Vortagsstil und vorallem hinsichtlich Präsentationstechniken und Folienaufbau (Stichwort "Powerpoint-Bulletpoint-Orgien") für sich mitgenommen hat.
Jedenfalls, dass war eindeutig der beste Vortrag hinsichtlich visueller Präsentation den ich bislang auf Deutsch (von einem Informatiker) gehört habe. Leider konnte ich weder ein Video des Vortrages noch die verwendeten Folien im Netz finden, sehr schade.
Nunja, kurz ein paar Worte zum Inhalt:
Zeller hat ein Konzept erarbeitet wie er Aussagen über die zukünftige Fehlerträchtigkeit von Modulen unter Einsatz verschiedenster Metriken machen kann. Dies kann man beispielsweise dazu nutzen um die Quality Assurance Maßnahmen bei besonders fehlerträchtigen Modulen anzupassen oder um herauszufinden, welches verfügbare Softwarepaket (Beispiel: DirectX vs. OpenGL) tendentiell eher weniger Probleme machen wird. Er wurde von Microsoft eingeladen seine Analysemethoden auf fünf große Softwarepakete von Microsoft anzuwenden und anhand der Daten versuchen zukünftige Fehler vorauszusagen. So hatte Zeller die Gelegenheit Code und Fehlerdatenbanken von folgenden Komponenten genauer zu untersuchen:
Ich habe noch nie bewusst auf "Problembericht absenden" geklickt. Ich fühle ich mich von diesem Dialog in einer Absturzsituation noch mehr genervt als ohnehin schon, und wenn ich lese "irgendwelche Informationen an Microsoft senden", dann suche ich reflexartig nach dem "Nee, Danke"-Button - auch deshalb, weil ich immer angenommen hatte, dass das sowieso nichts bringen würde. Mittlerweile habe ich dieses System-Verhalten gänzlich abgeschaltet. (Arbeitsplatz - Eigenschaften - Systemeigenschaften) Gut zu wissen, dass die Daten durchaus nützlich verwertet werden.
Die Analysierungsmethoden von Zeller eignen sich besonders für objektorientierte Strukturen. Einige Kernaussagen seines Vortrages:
Ich hatte vor vielen Jahren mal einen kurzen, aber sehr netten E-Mail-Kontakt mit Andreas Zeller. Ich habe damals einige LaTeX-Klassen für Online-Präsentationen (wie beamer, foiltex, prosper, ...) getestet und bin dabei auch auf stslide von Andreas gestoßen. Das Paket hat mir gefallen und Andreas reagierte auf eine Rückfrage prompt und sehr freundlich.
Erst später ist mir aufgefallen, dass er einer der Hauptautoren von DDD ist (dem Data Display Debugger - eines der Frontends für gdb und Co.) und ich auch ein Buch von ihm im Regel stehen habe.
In Programmierwerkzeuge gibt er eine Einführung und Tipps anhand von praktischen Beispielen zu diversen Unix-Entwicklungstools wie diff, patch, make, lex, yacc, autoconf, lint, gdb, ddd, gprof, ...
Das Buch ist zwar nett und vermittelt einen brauchbaren überblick über die wichtigsten Entwicklungstools und -methoden, dennoch möchte ich es an dieser Stelle nicht empfehlen. Denn das meiste kennt man schon und den Rest erfährt man mit etwas Aufwand auch günstiger aus dem Netz und den allgemein verfügbaren Dokumentationen. (Es gibt übrigens auch eine 2. Auflage: "Open-Source-Programmierwerkzeuge", 2003)
Ich wusste, dass sich sein Forschungsschwerpunkt hauptsächlich um Debugging- und Programm-Analyse -Techniken dreht, weshalb ich den Ankündigungstext auch gar nicht richtig gelesen hatte - der Name langte mir um einen Interessanten Vortrag zu erwarten.

Es waren sehr viele Professoren von verschiedenen Informatik-Instituten anwesend, was mir sehr gefallen hat. Ich hoffe mal, dass der eine oder andere auch einige Impulse - trotz unterschiedlicher Vorraussetzungen (Stichwort: "Folien als Skriptenersatz") - für den eigenen Vortagsstil und vorallem hinsichtlich Präsentationstechniken und Folienaufbau (Stichwort "Powerpoint-Bulletpoint-Orgien") für sich mitgenommen hat.
Jedenfalls, dass war eindeutig der beste Vortrag hinsichtlich visueller Präsentation den ich bislang auf Deutsch (von einem Informatiker) gehört habe. Leider konnte ich weder ein Video des Vortrages noch die verwendeten Folien im Netz finden, sehr schade.
Nunja, kurz ein paar Worte zum Inhalt:
Zeller hat ein Konzept erarbeitet wie er Aussagen über die zukünftige Fehlerträchtigkeit von Modulen unter Einsatz verschiedenster Metriken machen kann. Dies kann man beispielsweise dazu nutzen um die Quality Assurance Maßnahmen bei besonders fehlerträchtigen Modulen anzupassen oder um herauszufinden, welches verfügbare Softwarepaket (Beispiel: DirectX vs. OpenGL) tendentiell eher weniger Probleme machen wird. Er wurde von Microsoft eingeladen seine Analysemethoden auf fünf große Softwarepakete von Microsoft anzuwenden und anhand der Daten versuchen zukünftige Fehler vorauszusagen. So hatte Zeller die Gelegenheit Code und Fehlerdatenbanken von folgenden Komponenten genauer zu untersuchen:
- Internet Explorer 6
- NetMeeting
- DirectX
- Internet Information Server
- Interprozess-Komponente
Ich habe noch nie bewusst auf "Problembericht absenden" geklickt. Ich fühle ich mich von diesem Dialog in einer Absturzsituation noch mehr genervt als ohnehin schon, und wenn ich lese "irgendwelche Informationen an Microsoft senden", dann suche ich reflexartig nach dem "Nee, Danke"-Button - auch deshalb, weil ich immer angenommen hatte, dass das sowieso nichts bringen würde. Mittlerweile habe ich dieses System-Verhalten gänzlich abgeschaltet. (Arbeitsplatz - Eigenschaften - Systemeigenschaften) Gut zu wissen, dass die Daten durchaus nützlich verwertet werden.
Die Analysierungsmethoden von Zeller eignen sich besonders für objektorientierte Strukturen. Einige Kernaussagen seines Vortrages:
- Je nach Projekt greifen unterschiedliche Metriken (wie etwa Anzahl der Klassen, Anzahl von Methoden, Komplexität, Lines of Code, ...). Diese lassen sich allerdings nicht verallgemeinern und auf andere Projekte umlegen.
- Erfahrene Entwickler machen die meisten Fehler, denn sie arbeiten üblicherweise an den schwierigsten und komplexesten Modulen. (Wie z.B. bei Eclipse die CLASSPATH-Komponenten an denen auch Gurus wie Erich Gamma wiederholt scheitern)
- Auch intensives Testen eines Moduls heißt nicht, dass die Fehlerhäufigkeit dadurch geringer wäre - im Gegenteil, denn meistens testen Entwickler gerade jene Module besonders, die auch bisher schon die meisten Probleme machten. überhaupt können gute Entwickler instinktiv (wohl aus schmerzlicher Erfahrung) recht genau kritische Module bestimmen.
- Die (Fehler-)Vergangenheit eines Projektes ist entscheidend für die zukünftige Entwicklung. War eine Komponente in der Vergangenheit für viele Fehler verantwortlich, so wird sie das auch in Zukunft sein. Kann man auf keine ausreichenden Erfahrungsdaten zurückgreifen (etwa bei neuen Projekten) dann besteht die Möglichkeit Rückschlüsse über die Daten eines "sehr ähnlichen" Projekt ziehen zu können.
- Die Fehlerrate von Microsoft wäre nicht schlechter als der industrielle Schnitt, also etwa 1-2 Fehler pro Tausend Codezeilen.
- Die Open-Source Gemeinde mit ihren Aufzeichnungen liefert wertvolle frei verfügbare Daten für die Forschung in diesem Bereich (Mozilla und Eclipse wurden bereits analysiert)
Posted by Wolfgang Kaufmann
in Uni
Wann weiß man, dass... Thu, Jan 26. 2006
...man die Nacht damit verbracht hat, irgendwelche Paper für die Uni zu schreiben? Vielleicht, wenn man um 6 Uhr morgens in die Dusche dackelt und zwar rasch merkt, dass sich etwas anders anfühlt...allerdings nicht spontan Shorts und T-Shirt zu verdächtigen vermag? Guten Morgen!
Update: Eh klar, ein Tag der so beginnt...Professor verhindert, Abgabetermin um eine Woche verschoben.
Update: Eh klar, ein Tag der so beginnt...Professor verhindert, Abgabetermin um eine Woche verschoben.
Posted by Wolfgang Kaufmann
in Uni
November Tage Wed, Nov 9. 2005
November ist einer der Monate in denen man vor lauter Abgabeterminen, Übungsaufgaben und Klausurterminen schon mal vergessen kann, dass man studiert um sich Wissen zu erarbeiten, und nicht, um irgendwelche Prüfung (so kreativ, fragwürdig oder wohlüberlegt diese auch sein mögen) zu bestehen.
Insbesondere VUs machen Spass. VU steht für "Vorlesung & integrierte Übung". Klingt gut, ist es aber nicht. Jedenfalls nicht in der Praxis. Quasi, der Versuch Studenten dazu zu bringen schneller zu studieren, in denen man ihnen nahelegt sich im Zweifelsfall doch dafür zu entscheiden sich irgendwie durch die Kurse zu ringen und sich weniger um einen gründlichen, umfassenden und längerfristig rentierenden Wissenserwerb zu kümmern.
Insbesondere VUs machen Spass. VU steht für "Vorlesung & integrierte Übung". Klingt gut, ist es aber nicht. Jedenfalls nicht in der Praxis. Quasi, der Versuch Studenten dazu zu bringen schneller zu studieren, in denen man ihnen nahelegt sich im Zweifelsfall doch dafür zu entscheiden sich irgendwie durch die Kurse zu ringen und sich weniger um einen gründlichen, umfassenden und längerfristig rentierenden Wissenserwerb zu kümmern.
Posted by Wolfgang Kaufmann
in Uni
« previous page
(Page 1 of 1, totaling 3 entries)
next page »