Lukas’ Weblog

Als ich CRE 028 zum ersten Mal hörte, war ich ziemlich begeistert vor allem, weil ich akut Softwareentwicklungstipps brauchte. Jetzt hörte ich es zum zweiten Mal und bin noch immer begeistert. Mit Extreme Programming (XP) werde ich mich einmal intensiv beschäftigen (müssen ). Agile Softwareentwicklung ftw. Hier habe ich meine Notizen zu dem Thema zusammengefasst. Eventuell ist nicht alles XP-spezifisch, aber der Gastredner Pavel Mayer hat darauf verwiesen.

Basis: Problemen und Ängsten mit Offenheit & Ehrlichkeit begegnen und Unzufriedenheit mit eigenen Softwareentwicklungsstrategien als Motivator zur Veränderung:

Probleme des Entwicklers, Ängste des Kunden:

• Entwicklung hält sich nicht an den Plan und verfehlt das Ziel
• Entwicklung hält sich genau an den Plan und verfehlt trotzdem das Ziel
• Kunde bekommt wenig vom Entwicklungsprozess mit und kann nicht einschätzen, welche Komponenten kostspielig sind
• Kunde möchte vorab Kostenaufwand wissen
• Kunde ändert seine Meinung
• Kunde übergibt die Verantwortung an “fremde Techies”, um größeres Ziel zu erreichen
• Kunde versteht Produkt und auch Dokumentation nicht
• Kunde erhält keine Kritik zu Zielen / Ideen und erkennt erst hinterher Fehler, die Entwickler bereits im Entwicklungsprozess erkannten

Probleme des Kunden, Ängste des Entwicklers:

• Überforderung des Entwicklers
• Unterforderung des Entwicklers
• Inkompetenzen / Selbstzweifel des Entwicklers
• Verwendung von veralterten Herangehensweisen / Methoden / Wissen
• Übermäßige Verantwortung und zugleich fehlende Autorität (zB Zeit einhalten und zugleich beschränkte Entwicklerzahl)
• Qualität opfern um Termine einzuhalten
• Hilflosigkeit / Einsamkeit bei schwierigen Problemen
• Zeitdruck beim Entwickeln (wenn von Anfang an klar ist, dass die Deadline nicht eingehalten werden kann)

Fakten:

• Iterativ und kleinteilig arbeiten. Sehr bald funktionierendes System anstreben
• Funktionierendes System muss ständig verfügbar sein
• OpenSource-Entwicklung relativiert oft Verhältnis zu “Kunde”
• Einarbeitungszeit in XP + großes Softwarepaket beträgt etwa 1-2 Monate. Nach 6 Monate vollwertige Mitarbeiter und können bereits neue Mitarbeiter einschulen
• Einarbeitungszeit in XP nicht groß (Probleme & Ideen kennt jeder Programmierer natürlicherweise, nur konsequente Lösung mittels XP ist das schwierige)
• Es gibt Planbarkeitsgrenzen in Softwareentwicklung. zB 6 by 6 = 6 Leute für 6 Monate. Mehr ist nicht planbar.

Pair-Programming

• ein “Driver” programmiert aktiv und ein “Navigator” überlegt sich Abstraktion der Software, überwacht den Driver und diskutiert mit Driver Problemfälle
• Bei zB Dokumentation ist Pair-Programming unangebracht. PP ist schwierigeren / komplexeren Aufgaben vorbehalten
• PP bricht mit “der einsame Hacker im Keller” und “Know-How-Monopolen”
• Externer, temporärer Experte kann sein Wissen durch Pair-Programming am besten verbreiten / teilen
• Ungerade Entwicklerzahlen vermeiden bzw. klarsetzen, welche Aufgaben einzeln zu erfüllen sind bzw. mehrere Leute gemeinsam ihr Wissen bei einem Teilbereich austauschen sollten
• Durch PP wird Austausch von Wissen gefördert: zu verwendenden Algorithmen, Verwendung von Programmiersprachen, Tricks des Texteditors, …

Standup-Meetings

• Paarungen beim Pair-Programming werden beim Standup-Meeting festgelegt
• Standup-Meetings werden am Beginn des Projekttags gehalten.
• Jeder steht (damit Meeting nicht zeitlich ausufert).
• Jeder erzählt von Aktivitäten & Problemen des Vortags und erzählt Pläne für heute. Redner sucht sich Partner für “Aufgaben des Tages”. Q: “Kannst du mir helfen?” Vorgeschriebene Antwort: “Ja”
• Durch PP und Standup-Meetings ist klar, was jemand wann gemacht hat und Mitarbeiter werden für Urlaubszeiten oder Entlassungen ersetzbar

Source Code Management:

• “Collective Code Ownership”: Jeder kann auf den ganzen Quelltext zugreifen und ihn verändern (zentrales Softwarerepository).
• … bricht mit “wenn der Programmierer im Urlaub ist, ist sein Code auch im Urlaub”

Unittesting:

• Sicherung der Softwarequalität mittels Unittests
• Unittests erzeugen auch den (positiven?) Nebeneffekt, dass sich der Programmierer die API zuvor überlegen muss
• Unittests sollten vor der Implementierung geschrieben werden und decken normale Fälle, Grenzfälle und Fehlerbehandlung ab
• Es sollte ein Unittestframework genommen werden, welches den Automatisierungsprozess sehr vereinfacht und sich die Entwickler damit auch wohlfühlen

Dokumentation der Softwareentwicklung:

• “User stories” in Form eines “Storyboard” niederschreiben – Details des Auftrags dokumentieren und Systemverhalten beschreiben
• Priorisierung der Teilkomponenten (“musts”, “importants”, “nice to have”)
• “musts” müssen vor den “nice to have”s erledigt werden, wobei zweitere mehr Spaß machen (dieser Widerspruch zu “agil” lässt sich nicht vermeiden)
• Balance der Priorisierung muss gehalten werden (ein must mehr bedeutet ein vorhandenes must muss abgewertet werden)

Personal:

• Alle Mitarbeiter mit XP vertraut machen und ein Leader muss Softwareentwicklung-Techniken überwachen / überblicken
• Im Idealfall steht ein Vertreter (autorisiert & qualifiziert) der Interessengemeinschaft des Kunden durchgehend zur Verfügung (“Produktmanager”)
• Für 1-2 Leute ungeeignet. Ideal für 5-6 Leute. Maximal 10 Leute in einer Gruppe.
• Ab 10 Leuten lieber 2 separate Gruppen bilden und Mitglieder regelmäßig tauschen, damit Gruppen Anschluss zur anderen nicht verlieren.

Iterations-Zyklen & Engineering Tasks:

• Sprecher empfiehlt 2-Wochen-Zyklus (“Iterations-Arbeits-Planung”) (Arbeit langfristig für 2 Wochen planen)
• Jeder Entwickler hat “Engineering Tasks” und muss diese im Laufe des Projektes erfüllen. Die einzelnen Partner können dabei helfen.
• In der Iterations-Arbeits-Planung müssen “Engineering Tasks” festgelegt werden
• Ein ET umfasst etwa 1-3 Tage Arbeit. Alles darüber hinaus wäre nicht mehr zuverlässig abschätzbar.
• Iterationen sollen Gefühl von Erfolge vermitteln und Zeit abschätzen beibringen
• ET: Jeder schätzt Zeit die er für etwas braucht selbstständig
• “Engineering-Task-Karten”: Definieren einzelne klare Arbeiten. Umfassen max. 1-2 Tagesarbeit
• zB 2-4 Karten pro Entwickler pro 2 Wochen
• ET werden nach Innovations- und Komplexitätsgrad definiert. Anhand der Grade kann mittels Metriken Zuverlässigkeit festgestellt werden
• Reihenfolge der Kartenabarbeitung soweit irrelevant

Crunchtimes & Überstunden:

• Crunchtimes (extreme Phasen vor dem Projektende um Zeitplan einzuhalten) vermeiden bzw. abbauen
• Überstunden sind verboten, da sie Crunchtimes verursachen
• Überstunden sollen nicht erwartet oder honoriert werden.
• Begeisteter Programmierer darf noch freiwillig an Features/Off-Topic-Sachen arbeiten, aber dies wird nicht als Überstunde angerechnet.

Dokumentation:

• Alles muss automatisiert laufen
• Online-Dokumentation muss auch automatisiert aktuell gehalten werden

Technische XP-spezifische Werkzeug:

• Gutes Build-System
• Zentrales Repository
• Automatisches Unittesting
• Regressionstests

Zusatzideen:

• Große Projekte: Alle 2 Monate größeres Release-Planungs-Treffen
• Bei Google darf eine Zeitspanne lang komplett frei an einem beliebigen Projekt gearbeitet werden, solange man es danach präsentiert
• “Infrastructure-Friday”: Halber Tag, in dem Werkzeuge im Vordergrund stehen und verbessert werden

Kernfeatures (wichtigste Komponenten) des XP:

1. Iteratives Vorgehen
2. Pair-Programming
3. Automatische Tests
4. Ehrlichkeit & Offenheit

Kritik an XP:

• Idealer Kunde (wie er in Beispielen / Anleitungen) existiert nur selten
• Gegenüber Anforderungen wie Pflichtenheft unflexibel
• Manche Entwickler fühlen sich beim Pair-Programming unwohl und können erforderliche Offenheit & Ehrlichkeit nicht zur Verfügung stellen
• Nicht gut für jede Projektgröße und für jede Entwicklergruppe

Empfohlene Literatur: Von XP-Experten Kent Beck (EN) und Frank Westphal (DE).

Just another fanstuff project: brainrules

It provides a cheatsheet for John Medina’s twelve brain rules, because I was not happy about the official one. Done using GIMP, OpenOffice Presentation and gedit.

1. Damn you, OOo.
2. Damn you, missing directory listing.
3. Damn you, non-SVG graphics in PDF.
4. Love you, Free TrueType Fonts.

user@sys001 ~ % passwd
Changing password for user.
(current) UNIX password:
passwd: Authentication token manipulation error
passwd: password unchanged

Angenehm… nachdem ich das Passwort per GUI (ubuntu 9.10) ändern wollte, musste ich das alte Passwort “Authenticate”n. Dabei stürzte das Programm ab. Der normale Close-Button ließ sich jedoch ohne Fehlermeldung bedienen. Danach folgte die obrige Konsole-History. Jetzt ist das Passwort zerschossen und weder das alte noch neue Passwort geht. Mal schauen, was chroot ausrichten kann.

Is it just my way of thinking as a programmer or does really every second software suck generally? I mean bad UI and lack of features are the two main things I come across regularly.

IMHO especially commercial software for Windows, which does not have a large group of geeks for feedback. Even small OpenSource projects of programming beginners are better than that.

Der Stoff ist zwar super genial auf die praktische Anwendung ausgerichtet (wenig unnützes Zeug zu lernen, was man ja inzwischen richtig ungewohnt ist), aber die gestellten Fragen sind gleich schrecklich fehlerhaft formuliert oder fehlerhaft wie überall sonst. Hier sind die Beispiele, die ich mir notiert habe:

what a nice present before Graz

Bis zur Chaosradio-Sendung #126 dauerte eine Sendung 3h. Danach wurde es auf 2h gekürzt.

33*3 + 21*2 = 141h

Unter der Annahme, dass eine durchschnittliche Chaosradio-Express-Sendung 2.1 Stunden dauert, ergibt sich für CRE die Summe:

30*2.1 = 63h

Insgesamt kann ich also nachweisen, dass ich 204 Stunden Chaosradio (Express) gehört habe. Nachweisen kann ich es mittels entsprechender Aufzeichnungen von Stichwörtern, die mir zum Podcast einfallen. Abgesehen von den kleinen Podcasts (zB Chaosradio International) und den ärgerlichen Momenten, wo der iPod an den Anfang zurückspringt und ich eine halbe Stunde CR[E] höre, bevor ich dann doch etwas anderes höre, komme ich auf umgerechnet 8.5 Tage non-stop hören, 5 Wochen während einer 40-Stunden-Woche Arbeit oder eben 204 Tage im Jahr mit 1 Stunde Hören pro Tag. Podcasts hören mache ich seit etwa einem Jahr.

Hackerfunk vom CCC Zürich ist auch unterhaltsam: “Entwicklungsumgebung” wird im Schwizerdütsch zur “Intwicklungsumgabigr”

Zur Erinnerung: Chaosradio immer am letzten Mittwoch im Monat (außer Dezember) auf Fritz in Berlin.

Die genialste Chaosradio-Sendung, die ich bisher gehört habe.

Mag vielleicht daran liegen, dass ich momentan voll auf Programmiersprachen, Paradigmen, Compilerbau und Abstrakte Syntaxbäume stehe, aber die Sendung hat mir wirklich gut gefallen. Empfehlenswert für alle, die Ahnung von Programmiersprachen haben und auf der Metaebene nochmals etwas hören wollen. Meine proj.txt hat jetzt zahlreiche Projekte mehr auf der Liste

Meine Stichwörter (gekürzt): Dylan, Loops formalisiert, Compiler = Programm zur Transformation von Quelltext in maschinenlesbaren Code, Parser und Lexer, 2D (Programmiersprache), AST: Reservierte Wörter und Operatoren als Knotenpunkte, Noam Chomsky, Haskell ersetzt Schleifen durch Rekursion, Zwischencode funktionaler Sprachen haben einfachen Zwischencode basierend auf dem Lambda Kalkül, Objekt-Kalkulus, Eigenschaften von funktionalen Sprachen, Seiteneffekte = Determinismus, Monaden helfen state zu verstecken, wohl typisiert, C++ erreicht funktionalen Programmieransatz durch Templates, “Lambda ist die anonyme Funktion. Das Lambda abstrahiert über beliebig viele Variablen”, Variablen + Abstraktion + Applikation, Airbags, Ada, Objektorientierung, parametrische und Datenpolymorphie, Typisierung, dynamischen Programmiersprachen speichern Typmetadaten mit, strongly vs weakly typed, Typenannotation, Typeninferenz, generische Funktionen, gcc und llvm stellen Werkzeuge zur Typenverarbeitung zur Verfügung, MacRuby, Oliver Steele, static vs dynamic languages, Benjamin Pierce, subtyping, Type-based race detection for Java, Ken Thompson 1984: Reflections on Trusting Trust, Backdoors im Compiler, expression problem, operator overloading, für Interessierte – versch. Programmiersprachen mit versch. Paradigmen lernen, lambda-the-ultimate, Beweissysteme mit Programmiersprachen verbinden, PLOT – Programming Language for Oldtimers, Makrosystem von PLOT, Compiler sind großteils in C implementiert
Bewertung:
Weitere Referenzen: Wikipedia Compilerbau, Chaosradio Wiki: CRE 122

Naja, ich freue mich mal auf den morgigen Vortrag auf der Uni über Compilerbau

Awesome lecture about motivation… I believe it. It’s just my own experience.

Youtube: RSA Animate – The surprising truth about what motivates us

Since 16th of May, I’m user of the Neo Keyboard Layout. The main reason for this major change is ergonomics and typing speed. Neo seems to be nice due to it’s strong geek community (wiki, mailinglist, development and releases like an Open Source project), it’s good support for math symbols and nice collection of drivers. Nordtast-Layout seems to be nice too, but lacks in support of all the features mentioned before. Dvorak is not intended to be for programmers. Other keyboards layouts did not create a good first impression or included some terms like copyright, patent or property.

First positive experiences:

• The first impression is very positive. Feeling good.
• (it’s true) a lot things have to be typed using the baseline
• Using Windows’ (Ctrl+A, Ctrl+C, …) keyboard shortcuts is not that bad like in other alternate layouts
• the letter J is less difficult to find than expected

First negative experiences:

• Try to make a happy smiley
• the letter L typed using the right hand would be more comfortable
• less rhyme when typing personal frequent strings like my domain or unix commands
• html is going to be terrible difficult to code
• vim usage is much more complicated, because it’s optimized for QWERTY (thinking about using :map)
• Linux sucks. Since Neo, qwertz’s superkeys are no longer available. I cannot even type inequality signs for HTML

But all in all, zsh tab completion and google auto completion is making me lazy

The first main problem was my habit to note every small thought. Because I was too slow to note it, I forgot a lot of things. And it seems to be I’m the only one person alive having no on-the-fly-switch to other keyboard layouts (I have to reboot for that). Whenever I had to do productive stuff (= programming), I had to fall back to qwerty. Actually every fourth day, I was using Neo. But now I begin to make real exercises (of course, starting with the baseline) to learn Neo. neo-layout.org provides lot of nice learning tips. So let’s check out the learning progress:

Day 1:
You type 86 characters per minute
You have 15 correct words and
you have 0 wrong words