Lukas’ Weblog

Für jeden den es interessiert: Was passiert, wenn man einen Notruf absetzt?

Auf Anraten eines ehemaligen Mitarbeiters ist dieser Beitrag zensiert, da er unter das Berufsgeheimnis fällt. Mein persönliches Statement: Solange wir keine Transparenz schaffen, werden wir weiterhin Monopole, security by obscurity und Feedbacklosigkeit fördern und verkörpern. Meiner Meinung nach der falsche Weg in die Zukunft.

There is too much to nag about. I’m microblogging.

RSS: identi.ca/meisterluk. Twitter may come soon.

Furthermore:

/me became an #Opera user

[abdgo]{3,4} old Firefox times. The main reason for conversion: speed (Opera IS faster here!) and craving for testing alternatives.

Auf der Dienststelle jetzt groß ausgehängt, ist der Artikel aus dem Standard vom 01. August 2010. Gelb markiert ist der erste Satz:

“Natürlich ginge es auch ohne Freiwillige. Aber im Rettungsdienst sind 50 Prozent der Beteiligten Freiwillige, und wir sind der Meinung, dass das auch weiter so sein soll”.

Drunter steht der Satz “Wie bitte” gefolgt von drei Fragezeichen (Wortlaut ist zumindest ähnlich) und unterzeichnet vom Bezirkstellenleiter. Weiters folgt die Frage “Oder wie seht ihr das?”. Meine Sichtweise:

Ich weiß nicht wie es euch geht, aber wenn ich (als ehrenamtlicher Mitarbeiter) höre, dass der Betrieb ohne uns/mich nicht funktionieren kann, stimmt mich das höchst depressiv / nachdenklich. Ich setze mich einmal in der Woche in den Rettungswagen und führe kranke Leute durch die Gegend (manchmal auch ins Krankenhaus). Etwa 3mal die Woche werde ich angerufen, ob ich diesen und jenen Dienst übernehmen könnte. Während mein beruflicher Kollege mit etwa 100 Euro aus der 12-Stunden-Schicht austritt, verzichte ich darauf und gebe mich mit 2 symbolischen Euros zufrieden. Das ist natürlich nicht der Kritikpunkt, sonst hätte ich mich nicht der Freiwilligkeit verpflichtet. Sondern es stimmt mich nachdenklich, dass ich infrage stellen muss, wie dieser “Konzern” arbeitet. Ich setze mich ins Auto, um den Konzern zu unterstützen. Ich hoffe durch die ersparten 98 Euro kann die Kassa etwas aufgebessert werden und Geld für neue medizinische Geräte bereitgestellt werden oder Erste-Hilfe-Kurse wieder gratis angeboten werden. Ich erhoffe mir dadurch dem Konzern unter die Arme zu greifen und ihm die wirtschaftliche Last zu nehmen, um seine 7 Ideale verwirklichen zu können (die im Gegensatz zum wirtschaftlichen Kapitalismus stehen nach dem er arbeiten muss). Doch was muss ich hören? Gäbe es uns freiwillige Mitarbeiter nicht, gäbe es den Konzern gar nicht. Es ist so als wären die 98 Euro fix für das geringe Gehalt von dem Zivildiener verplant, der rechtlich fragwürdige Arbeit leisten muss. Dies stimmt mich höchst nachdenklich. Welch wirtschaftlich ineffiziente Arbeit ist noch akzeptabel? Wie weit darf Geld veruntreuut werden? Wohin fließt das Geld der Krankenkassen? Wenn dem Dargelegtem wirklich so ist, dann sehe ich meine Position als widersprüchlich mit den Idealen selbst und kann diese nicht mehr im Sinne der Gemeinschaft vertreten.

Stellt euch vor Software und Betriebsysteme könnten nur dadurch bereitgestellt werden, dass jeder Programmierer für die Freiwilligkeit programmiert. Für Outsider sei gesagt, dass es im Sinne der freien Softwarelizenz-Modelle zum Vielfachen passiert (Linux hat diesen Hype damals groß ausgelöst). Programmierer schreiben Code um sich fortzubilden, die technischen Entwicklungen voranzutreiben und durch die Eigenwerbung auch eventuell auf eine Arbeit sehen zu können. Die Software selbst bildet nur ein Abfallprodukt von diesem Prozess. Analog ist es mit der Freiwilligkeit beim RK: Ich arbeite freiwillig, um mich fortzubilden, unser Gesundheitssystem zu unterstützen und eventuell bekomme ich auch einmal eine Arbeitsmöglichkeit bei Bedarf. Wenn jedoch “das Abfallprodukt” schamlos ausgenutzt wird und der Entwickler / Arbeiter selbst in den Hintergrund tritt, bleibt es einem in der Softwareentwicklung nur übrig das Lizenzmodell zu wechseln und im RL aus dem Konzern auszutreten. Ja, tut mir leid alte hierarchisch strukturierten Großkonzerne, dass es sich hierbei um “neue” Gesellschaftsmodelle handelt, die ihr scheinbar noch nicht versteht und auszubeuten versucht. Aber auf Dauer werdet ihr es auch verstehen, dass wirtschaftlichen Diskrepanzen begegnet werden muss. In der Softwareindustrie scheint mir der Prozess schon (natürlich bedingt) weit entwickelt zu sein. In der realen Welt sehe ich noch große Defizite. Ich stelle in Frage, ob diese 80er-retro-apokalyptische Vorstellung “die virtuelle Welt wird kollabieren” nicht in ihrem Gegenteil (reale Welt) auftreten wird (im wirtschaftlichen Bereich).

Übrigens sehe ich diesen Blogeintrag nicht im Widerspruch mit der neuen Social Media Policy des RKs. Ich bin wohl “durch die Feedbackkanäle auf alle verschiedenen Anspruchsgruppen unserer Organisation” eingegangen, doch dieser Blogeintrag untersteht wohl keinem “Copyright” (siehe SMP). Jedoch dem Urheberrecht und der CC Attribution-ShareAlike 3.0 Austria. Tut mir leid, dass ich so viele versteckte Anspielungen machen musste, doch wer sich Gedanken über Wirtschaft und unseren Lebensstil gemacht hat, wird diese Probleme sehen und auch die erwähnten Lösungsansätze neugierig verfolgen. 90% der freiwilligen Mitarbeiter hören es wohl gerne, dass sie “unersetzbar” für den Konzern sind. Tut mir leid, dass ich wieder aus der Masse heraussteche.

Siehe auch: Zivildienst – mein Erlebnis (PDF)

Kommentar einer Patientin: “Ich wusste ja gar nicht, dass die jungen Leute so nett sein können”
Kommentar einer Passagierin: “Ja, der Wörthersee ist wunderschön, aber die Jugend möchte immer Urlaub woanders machen”

Liebe Leute, bitte erzeugt nicht Probleme, wo keine sind. Wieso sollte alles Neue/Junge schlecht sein und auf wen sind bitte Reiseunternehmen ausgerichtet? Die Schüler/Studenten fahren mit den Eltern, die Eltern mit kleinen Kindern organisieren am liebsten alles selbst und die Pensionisten fahren am liebsten weit weg, wo sie ihre Ruhe haben und sich um nichts kümmern müssen. Die Ersteren fahren dorthin, wo es ihnen vorgegeben wird. Die Zweiten bleiben möglichst nahe in der Heimat (sofern es kulturell möglich ist). Die Generationsprobleme sind IMHO zum Großteil nicht existent. Bitte macht die Augen auf. Erst dann beurteilt die Welt. Das erspart mir manch unliebsame Smalltalk-Diskussion, in der ich den Kontrapunkt spielen muss. Danke.

1. Do not answer until you have something useful to answer
2. To copy the email, use the CC-Header to show all others all email-addresses and who else has received it

Damn you.

The best and truest quotes (imho, because I have experienced them myself):

Adults can’t avoid seeing that teenage kids are tormented. So why don’t they do something about it? Because they blame it on puberty.

Because I didn’t fit into this world, I thought that something must be wrong with me. I didn’t realize that the reason we nerds didn’t fit in was that in some ways we were a step ahead. We were already thinking about the kind of things that matter in the real world, instead of spending all our time playing an exacting but mostly pointless game like the others.

Teenagers seem to have respected adults more then, because the adults were the visible experts in the skills they were trying to learn. Now most kids have little idea what their parents do in their distant offices, and see no connection (indeed, there is precious little) between schoolwork and the work they’ll do as adults.

And if teenagers respected adults more, adults also had more use for teenagers. After a couple years’ training, an apprentice could be a real help. Even the newest apprentice could be made to carry messages or sweep the workshop. Now adults have no immediate use for teenagers. They would be in the way in an office. So they drop them off at school on their way to work, much as they might drop the dog off at a kennel if they were going away for the weekend.

In almost any group of people you’ll find hierarchy. When groups of adults form in the real world, it’s generally for some common purpose, and the leaders end up being those who are best at it. The problem with most schools is, they have no purpose. But hierarchy there must be. And so the kids make one out of nothing.

Paul Graham’s “Why Nerds are unpopular”
Recommended for all interested people in topics of nerdism and american education. Just a nice Saturday night lecture.

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).

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.

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:

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.