At Work

"Adding manpower to a late software project makes it later." -- Fred Brooks, 1975

The Mythical Team-Month ist eine großartige Präsentation von Justing Searls (u.a.) über erfolgreiche Teams und schnellere Feedbackzyklen in der Softwareentwicklung. Die Folien stehen für sich alleine und sind aufgrund der angeschlagenen Audioqualität fast besser als die die 40minütige Aufzeichnung der Präsentation (siehe unten):



Hier die Videoaufzeichnung:

The Mythical Team Month from Justin Searls on Vimeo.

"Cuz if I didn't write it, the code obviously sucks."

JavaScript marschiert unaufhaltsam auf seinem Weg Richtung Weltbeherrschung. Während die einen noch über Prototype Inheritence jammern, haben es die anderen längst verstanden und bauen moderne large-scale Webapplications der nächsten Generation.

Devon Govett berichtet auf Badass JavaScript regelmässig über beachtenswerte Projekte und Neuigkeiten rund um JavaScript. In 2011: A Badass JavaScript Year In Review gibt er einen Rückblick auf einige der Projekte die im vergangenen Jahr herausstachen.

Allen voran auf der Liste natürlich jslinux von Fabrice Bellard, dem französischen Überhacker dem nach:

• LZEXE, dem ersten weitverbreiteten MS DOS EXE-Packer mit dem man Executables kompromieren und ausführen konnte ohne sie vorher wieder dekompromieren zu müssen
• einer Java Virtual Maschine und einem Java Bytecode nach C Compiler (Harissa)
• QEmacs, einem schnellen Emacs Klon
• einem kleinen und sehr schnellen ISO C99 kompatiblen C Compiler (TCC)
• FFmpeg, dem digitalen Video-/Audio-(De)kodierungsherzstück von MPlayer, VLC, Xine, HandBrake und Co
• der Virtualisierungssoftware QEmu
• dem mehrmaligen Gewinn des International Obfuscated C Code Contests
• und dem Weltrekord in Pi Nachkommastellen berechnen

mal wieder etwas fad war und deshalb jslinux, einen (32 Bit x86) PC Emulator in JavaScript der Linux bootet, gehackt hat. D.h. wer mal qemacs oder tcc ausprobieren möchte, das geht jetzt auch im Browser

Ein anderes eindrucksvolles Beispiel für "da-tut-sich-was!" ist pdf.js, einem PDF Parser und Renderer in JavaScript der ohne nativen Code auskommt, von Mozilla Labs.

Und das sind nur zwei von vielen spannenden Projekten im JavaScript Umfeld von 2011 und Projekten wie CoffeeScript, Node.js, diversen JavaScript MVC/MVVM Frameworks wie Knockout.js oder auch Emscripten, dem LLVM-to-JavaScript Compiler, die schon ein wenig älter sind.

Einführende Videos über Scrum gibt es viele. Dieses hier zählt definitiv zu den Besseren. Gerade mal acht Minuten braucht Hamid Shojaee um seinen Zusehern viele Kernelemente von Scrum gespickt mit einigen persönlichen Erfahrungen zu vermitteln.



Klar, so manches Scrum -Artifakt oder -Meeting kommt in einem 8minütigen-Crash-Course zwangsläufig etwas zu kurz, aber dennoch ein gutes Video. Bemerkenswert finde ich neben der Gleichsetzung von ScrumMastern und Projektmanagern vorallem seine Einstellung zu Daily Scrums:

"The idea behind a standing meeting is that if everyone is standing nobody will waste time and therefore meeting will be short. And by meeting daily you can feel confident that everyone is on top of their tasks. The daily scrum is a great idea and especially useful in less experienced teams but I wouldn't call it a core or essential part of scrum. Insisting on these meetings in an already efficient and experienced team, especially teams that work in close proximity with one another could actually backfire by lowering team morality. Keep that in mind when deciding on having daily scrums." -- Hamid Shojaee über Daily Scrum

Heißt das also "Erfahrenes eingespieltes Team + aufrechter Kommunikationsfluss innerhalb des Teams" == "Daily Scrum kontraproduktiv"?

Auf keinen Fall! Schließt dieser aufrechte Kommunikationsfluss auch den Product Owner und vor allem auch den Scrum Master mit ein? für beide ist das Daily Scrum von wesentlicher Bedeutung. für den SM ist es ein Kanal um Impediments klar aufgezeigt zu bekommen, die zuvor vielleicht einem einzelnen Teammitglied aber nicht der ganze Gruppe bewusst waren. Blockaden die vielleicht bisher einfach nie angesprochen wurden. Außerdem ist das Daily Scrum nicht nur für das Team da. Es bietet auch Außenstehenden – allen Interessierten, wie etwa Marketing, Geschäftsführung, Kunden, potentiellen Nutzern... - eine Möglichkeit in ein Team und in ein Projekt hinein zu sehen.

"It's the meeting to end all meetings." -- Jonathan Rasmusson

Vor allem aber sollte das Daily Scrum natürlich seinen Teammitgliedern (und dem Projekt!) dienen. Es sollte Teil einer gefestigten Routine sein, die den (Tages-)Rhythmus vorgibt. Es ist mehr als ein Synchronisationsmeeting um sich über den Stand der Dinge zu informieren, es ist vor allem auch eine Gelegenheit ein Team noch enger zusammen zu schweißen und zu motivieren!

Aber es stimmt, einerseits sind auch erfahrene eingeschworene Teams die seit langem zusammen arbeiten, co-located sind, sich permanent austauschen und mit Scrum beginnen nicht vor schlechten Meetings sicher. Anderseits kann bei agilen Teams die tägliche taktische Planungskomponente (wer übernimmt welche Aufgaben?) mit der Zeit an Reiz verlieren kann. Oftmals begleitet von zusätzlichen Lästigkeiten, wie z.B. dass sich das Meeting verzögert, weil immer irgendjemand noch schnell irgendetwas fertig machen möchte. "Einen Moment noch! Muss nur noch schnell diese eine E-Mail fertig schreiben, dieses eine Telefonat führen, den Server neustarten, den Buildprozess anstoßen... (und dann unvorbereitet zum Daily Scrum)"

In solchen Fällen könnte ein Funkwecker im Teamraum helfen oder das automatisierte Abspielen eines bestimmten Songs, wie z.B. die Anfangssequenz von The Final Countdown von Europe oder irgendeinem anderen Song aus Rocky.

Aber klar, wenn jemand gerade im Flow ist, ist jede Unterbrechung schlecht.

"The purpose is not to meet... it is to improve." -- Joe Ely

Ein weiterer positiver Aspekt von Daily Scrums: Wenn man als Entwickler morgens beim Daily Scrum seinem Team - quasi öffentlich - erklärt, dass man die Funktion »Speichern« bis zum nächsten Daily Scrum liefern wird, dann erhöht das auch die Chance, dass das Feature tatsächlich geliefert wird (=commitment/forecast to each other). Jeder Mensch möchte stolz auf sich sein, möchte von anderen wertgeschätzt werden und niemand möchte seine Kollegen enttäuschen. Dieses Verhalten und der Wunsch etwas Qualitatives zu liefern ist meiner Erfahrung nach unter Softwareentwicklern besonders ausgeprägt.

Abschließend ein Tipp aus Jason Yips Artikel: It's Not Just Standing Up: Patterns for Daily Standup Meetings

"Instead of thinking of the daily stand-up as a ritual for the people, think of it as a ritual where the Work Items Attend (e.g., User Stories in an Agile context) and the people attend only to speak for the work items... since obviously the work items can't actually talk." -- Jason Yip

[...] How computer programmers store the vital product of their labours – source code. The (for now) final end product seems incredibly obvious.

[...] Yet it took decades of iterative innovation, from some of the cleverest minds in the field, to make something so apparently simple yet powerful.

Francis Irving, der Autor von TortoiseCVS, über die Meilensteine in der Geschichte von Versionskontrollsystemen.

Wer sich ein bisschen bishin zu sehr viel mit Softwareentwicklung - und Scrum im Besonderen - beschäftigt, aber den Scrum et al. Talk von Ken Schwaber auf Google Video noch nicht gesehen hat: Halt! Sofort anschauen und heute noch etwas Neues lernen oder im schlechtesten Fall: von einem Ex-Marine gut unterhalten werden.

Scrums assumption is that you are intelligent or at least as intelligent as you'll ever be and that you will use that intelligence and your experience to come up with the best solution for whatever circumstance you're in right then.

When we first [...] announced Agile, 2001 there were a number of comments that agile was really, really good. This way from [...] people who were kind of a little troubled with Agile. They said really, really good if you have a team of outstanding engineers that are using excellent engineering tools, have engineering practices down pat, understand the business domain, the technology domain inside out and aren't interrupted and have all the resources they need, then you can use Scrum. While it's true that people like that can build an increment of software every iteration. That's good.

However, Scrum works with idiots. You can take a group of idiots, that maybe didn't even go to school, don't understand computer science, don't understand software engineering techniques, hate each other, don't understand the business domains, have lousy engineering tools and uniformly they will produce crap every increment. This is good!

You want to know - at the end of every iteration - where you are. And part of the point of Scrum [...] is transparency. So that everyone knows where you are all the time. -- Ken Schwaber

"A language that doesn't affect the way you think about programming, is not worth knowing." -- Alan Perlis, Epigrams on Programming

Die Frustration beim Debuggen einer Webapplikation in der Umlaute trotz vermeintlich korrekter Konfiguration vermurkst wurden, trieb mich unlängst in die Innereien von Jetty einem leichtgewichtigen Java Servlet Container und Webserver. In der aktuellen Release-Version, immerhin bereits Version 6.1.11 (!), lies mich der folgende Code erleichtert aufatmen.

jetty-6.1.11/modules/util/src/main/java/org/mortbay/util/UrlEncoded.java:
 405 / -------------------------------------------------------------- /
 406 /** Decoded parameters to Map.
 407   @param in the stream containing the encoded parameters
 408  */
 409 public static void decodeTo(InputStream in, MultiMap map, String charset, int maxLength)
 410   throws IOException
 411 {
 412   if (charset==null || StringUtil.__UTF8.equalsIgnoreCase(charset) || StringUtil.__ISO_8859_1.equalsIgnoreCase(charset))
 413   {
 414     decodeUtf8To(in,map,maxLength);
 415     return;
 416   }
 417 
 418   if (StringUtil.__UTF16.equalsIgnoreCase(charset)) // Should be all 2 byte encodings
 419   {
 420     decodeUtf16To(in,map,maxLength);
 421     return;
 422   }

Danke, keine weiteren Fragen Eurer Ehren! Zum Vergleich die korrigierte Version von decodeTo in der aktuellen SVN HEAD Revision:

  / -------------------------------------------------------------- /
  /** Decoded parameters to Map.
    @param in the stream containing the encoded parameters
   */
   public static void decodeTo(InputStream in, MultiMap map, String charset, int maxLength)
   throws IOException
   {
   if (charset==null || StringUtil.__ISO_8859_1.equals(charset))
   {
     decode88591To(in,map,maxLength);
     return;
   }
   if (StringUtil.__UTF8.equalsIgnoreCase(charset))
   {
     decodeUtf8To(in,map,maxLength);
     return;
   }
   if (StringUtil.__UTF16.equalsIgnoreCase(charset)) // Should be all 2 byte encodings
   {
     decodeUtf16To(in,map,maxLength);
     return;
   }