Software Engineering Blog

Das Software Engineering Blog läuft auf einer inzwischen angestaubten Version von WordPress und es wird langsam Zeit mit der Zeit zugehen. Daher werde ich zwischen den Feiertagen die Zeit für ein Update nutzen. Daher kann es zwischenzeitlich zu Problemen kommen. Aber ein schon angelegtes Vollbackup sollte das Schlimmste verhindern helfen.

Am Montag war der letzte Berliner Scrumtisch in diesem Jahr und Andrea Tomasini sprach über Kanban. Seine Vorstellung von Kanban sorgte unter den wenigen vorweihnachtlichen Teilnehmern für intensive Diskussionen. Vielleicht schaffe ich es ja noch ein paar Zeilen zu meinen natürlich rein subjektiven Ansichten dazu zu schreiben. Ehrlich gesagt, ich habe mich mit Kanban dabei nicht anfreunden können, auch wenn mir einzelne Ideen gut gefallen haben.

Nach dem Vortrag hat mich Tomasini auf das Buch The Fifth Disciplin von Peter M. Senge aufmerksam gemacht. Schon beim ersten Blätter wußte ich, das dieses Buch etwas für mich ist und habe es flugs bei A..... bestellt.

Nach Senger ist die fünfte Disziplin Systemdenken und faßt Personal Mastery, Mental models, Building shared vision und Team Learning zusammen. Das sind die ersten vier Disziplinen. Es geht also darum übergreifend zu denken und zu handeln, um Dinge zu vernetzen und so in Bewegung zu bringen.

Was mir an der Wikipedia-Zusammenfassung zum Buch besonders gut gefallen hat, sind The 11 Laws of the Fifth Discipline, die ich hier einfach einmal reinkopiere...

1. Today's problems come from yesterday's "solutions."
2. The harder you push, the harder the system pushes back.
3. Behavior will grow worse before it grows better.
4. The easy way out usually leads back in.
5. The cure can be worse than the disease.
6. Faster is slower.
7. Cause and effect are not closely related in time and space.
8. Small changes can produce big results...but the areas of highest leverage are often the least obvious.
9. You can have your cake and eat it too ---but not all at once.
10. Dividing an elephant in half does not produce two small elephants.
11. There is no blame.

Ich kann hier nur elf Mal nicken, aber meine Lieblinge sind 1, 6, 7 und last-but-not-least 8.

Statusmails sind ein beliebtes Kommunikationsmittel, um Meilensteine oder wichtige Änderungen an alle Beteiligten zu kommunizieren. Richtig formuliert vermitteln sie schnell die wesentlichen Fakten und helfen uns besser den Stand an auch einen größeren oder nicht immer direkt beteiligten Personenkreis zu vermitteln.

Eigentlich ist das sehr gut, denn wir alle wissen, daß Kommunikation wesentlich über Erfolg oder Mißerfolg, Sieg oder Niederlage entscheidet.

Daher sollte ich eigentlich auch kein Problem mit ihnen haben. Habe ich aber. Das Problem ist, das es Mails sind. Widersprüchlich? Auf den ersten Blick sicherlich, aber ich habe auch mindestens ein gutes Argument dafür: Mails gehen in den Mailboxen ihrer Empfänger verloren.

Zum einen bin ich mir sicher, daß die meisten Statusmails ungelesen in vielen Mailboxen versauern, da die Empfänger gerade mit subjektiv wichtigerem beschäftigt sind. Das in der Mail behandelte Problem betrifft mich jetzt gerade nicht, das kann ich auch später lesen. Irgendwann ist diese Mail kann in der Inbox soweit hinten, daß wir uns gar nicht mehr an sie erinnern.

Was aber noch schlimmer ist, diese Statusmails sind immer nur für die verfügbar, die genau in diesem Augenblick an dem Projekt beteiligt sind. Wer später hinzukommt, hat keine Chance mehr an diese Informationen zu kommen. Und oft sind es aber genau diese Informationen, die Projektneulingen helfen zu verstehen, warum das Projekt jetzt da ist wo es ist und warum dies so und jenes so ist.

Kommunikation zwo.null

Ein Blog bietet hierfür eine wunderbaren Alternative. Chronologisch aufgebaut kann man sich in die Geschichte des Projektes einlesen, da die wichtigen Informationen zentral an einer Stelle gesammelt werden.

Ein berechtigter Einwand ist, daß nicht sichergestellt ist, daß das Blog auch gelesen wird, da man es ja explizit aufrufen muß (Pull-Prinzip), man bei Mails aber relativ sicher sein kann, daß jede Mitteilung auch beim Empfänger ankommt. Das stimmt, aber erhalten bedeutet noch nicht gelesen. Ich will damit nicht das Argument entkräften, denn ich teile die Ansicht auch. Doch wie wäre es mit einer Mailschnittstelle, die neue Blogeinträge einzeln oder aggregiert an einen Verteiler schickt? So könnten sinnvoll E-Mail und Blog als Kommunikationsmittel eingesetzt werden, ohne die bestehenden Vorteile zu verlieren.

Abschließend möchte ich aber noch einmal den wichtigsten Punkt hervorheben: Wie in einer Firma oder in einem Projekt kommuniziert wird ist ein Teil der Kultur der Organisation. Und ein Blog bleibt daher stehts nur ein Mittel zu Zweck.

Also, viel Erfolg und auch Spaß am eigenen Projektblog!

P.S.: Da ich nun nicht der erste bin, der sich zum Einsatz von Blogs in Projekten Gedanken gemacht hat, hier ein paar Links zum Thema:

Im PM Blog habe ich einen interessanten Verweis auf einen Vortrag von Jurgen Apello auf der Agile Eastern Europe conference in Kiew gefunden, der nach meiner Ansicht wunderbar die wesentlichen Prinzipien zusammenfaßt, mit der Software-Entwicklungs-Teams geführt werden sollten.

Jurgen Appelo, "So Now You’re an Agilist. What’s Next?", Agileee conference, 2009 from Alexey Krivitsky on Vimeo.

Aus gegebenen Anlaß mal wieder ein Verweis auf einen Spiegel-Artikel. In "Google will die Weltherrschaft" widmet sich Spiegel online den sich immer weiter ausweitenden Aktivitäten von Google. Wie meinte heute ein Freund: "Die Staatssicherheit mußte die Daten noch selber sammeln, heute geben wir sie selber jedem weiter." Tja, leider stimmt das wohl.

Für alle aus dem Raum Berlin und an Scrum-Interessierte dürfte interessant sein, daß die OOSE im nächsten Jahr auch ein Scrum-Master-Seminar mit der Möglichkeit zur Zertifizierung in Berlin durchführt. Für mich auf jeden Fall die Gelegenheit, mich als Scrum Master zertifizieren zu lassen, ohne nach Hamburg zu fahren. Eigentlich aber auch schade.

Hier geht es zur Anmeldung für das Berliner Seminar.

Alle zwei Jahre steht auch bei mir eine Verlängerung des Handyvertrags an und die je nach Anbieter unterschiedlichen Angebote sorgen dafür, daß wohl viele Handys in Deutschland nach zwei Jahren den Besitzer wechseln. Der Erstbesitzer macht einen Technologiesprung und es findet sich doch immer jemand im Bekanntenkreis, der ein (neueres) Handy gebrauchen könnte.

So auch bei mir und daher besitze ich jetzt seit zwei Wochen ein Nokia E71. Sicherlich, nicht das aktuellste Modell auf dem Markt, aber genau das was ich brauche. Zumindest glaube zu brauchen. Es ist klein, handlich und leichter als mein altes E61. Und es hat unerwartete Nebenwirkungen: ich höre jetzt auch Podcasts. Auf dem Laptop war mir das immer nicht bequem genug. Schlimmstenfalls muß man da auch noch zuhören, sich also konzentrieren. Das klappt zwar neben der Arbeit, aber geht auch zu deren Lasten. Jetzt ist das anders. Die Podcasts aktualisieren sich automatisch über mein WLAN und da das Handy praktisch überall dabei ist, findet sich immer irgendwo etwas Zeit für ein wenig Edutainment. Aber nun zur Sache...

So komme ich endlich auch einmal dazu mir Podcasts des Software Engineering Radios anzuhören. So zum Bespiel die Episode 148 mit Dave Thomas zum Thema Software-Archäologie.

Thomas führt in diesem Podcasts ein paar interessante Dinge aus. Zum Beispiel, daß er am Code sehen kann, unter welchen Umständen die Software geschrieben wurde. Für mich ist das nachvollziehbar, denn unsere Arbeitsumstände haben einen maßgeblichen Einfluß darauf wie wir arbeiten und was wir erreichen können. Das erinnert mich aber auch an Conways Gesetz… Suchen sie einmal danach im weltweiten Gewebe.

Während des Podcasts wird auch das Thema Lesen von Code behandelt und daß dies eine viel zu stark vernachlässigte Disziplin ist. Das findet absolut meine Zustimmung. Und jeder der in Teams arbeitete weiß wie schwer ist manchmal schon sein kann, zu verstehen, was der Kollege da geschrieben hat und seine Gedankengänge nachzuvollziehen. Wie schwer ist es also erst sich in ein ganz fremdes System einzuarbeiten, eventuell noch auf einer anderen technischen Basis? Neulich habe ich mich mit der Implementierung von Hadoop beschäftigt. Und dabei mußte ich selber wieder erstaut feststellen, daß selbst wenn man im Grunde weiß wie etwas funktioniert, es doch eine Weile dauert ehe man die entsprechenden Teile im Code gefunden hat und zu verstehen beginnt, wie diese zusammenspielen. Am Ende ist es aber auch ein gutes Gefühl nicht nur zu wissen wie etwas ungefähr funktioniert, sondern es genau zu verstehen.

Thomas bemängelt in dem Podcast, daß in der Ausbildung an den Universitäten diese Disziplin nicht gelehrt wird. In anderen Fächern, wie den Geisteswissenschaften etwa, sei es gang und gäbe sich mit der Arbeit von anderen zu beschäftigen, indem deren Bücher und andere Veröffentlichungen von relevanten Autoren gelesen, analysiert und kritisiert werden.

Auch Mediziner lernen die menschliche Anatomie nicht beim ersten Kontakt mit den Patienten kennen, sondern schon bei der Sektion. Stellen sie sich einmal vor, sie kommen zu einem Arzt und hören: „Ah, so sieht das aus. Noch nie gesehen... Darf ich da einmal anfassen?“ Sie würden kopfschüttelnd den Raum verlassen und diesen Arzt für immer meiden.

Also warum nicht, wie Thomas es vorschlägt, Seminare an Universitäten anbieten, die sich nur mit der Analyse von bestehender Software beschäftigen? Nicht nur mit den abstrakten Konzepten, sondern mit deren konkreter Umsetzung durch exisitierende Systeme.

Das ist nicht schwer. Java ist eine leichte Sprache und die Unterstützung durch Entwicklungsumgebungen ist sehr gut. Große quell-offene Softwareprojekte sind im Java-Umfeld frei verfügbar. Ich nenne hier nur einmal die üblichen Verdächtigen: Hibernate, Tomcat, JBoss, …

Jedes dieser Systeme setzt freiverfügbare Standards wie JPA, Servlet, JSP und EJB um. Warum nicht die Umsetzung dieser Standards untersuchen am Beispiel von konkreten Implementierungen. Welche Algorithmen lassen sich finden? Wie sieht die Architektur aus und wird diese auch konsequent umgesetzt?

Davon würde jeder profitieren können. Also, vielleicht gibt es ja einen Leser dieses Blocks, der sich dieser Idee annehmen möchte…

Eine normale Arbeitswoche hat fünf Arbeitstage und zwei Pole. Montag ist der eine Pol und Freitag der andere. Anfang und Ende, Alpha und Omega. Jeder Wochentag hat seine Eigenheiten und von Wochenendarbeiten wollen wir einmal nicht ausgehen.

Montag ist der Tag nach dem Wochenende und das ist wichtig. Wir betreten das Büro ausgeruht und mit neuer Kraft. Probleme die am Freitag unlösbar waren sind über das Wochenende nebenbei gelöst worden. Manchmal einfach nach dem Aufstehen am Samstag und wir fragen uns, warum wir das nicht gleich so gesehen haben. Abstand und Ruhe sind oft die besten Problemlöser.

Am anderen Ende der Woche steht der Freitag. Freitag ist der Tag vor Samstag und Sonntag, also dem Wochenende und das ist wichtig für den nächsten Montag. Siehe oben. Freitags sollten keine harten Nüsse geknackt oder immens wichtige Termine angesetzt werden.

Was wir am Montag und Freitag tun, aber nicht sollten

Den Montag sollten wir uns für die Dinge vorbehalten, die wir mit ausgeruht angehen wollen, die uns vielleicht schon seit einiger Zeit unter den Nägeln brennen oder letzte Woche liegen geblieben sind. Oft wird der Montag aber gleich mit Meetings vollgekleistert, die sich damit beschäftigen, war in dieser Woche zu erledigen ist. War das nicht schon letzte Woche klar, was ansteht? Die Woche hat doch schon begonnen und über das Wochenende hat sich meistens wenig geändert.

Dafür wird am Freitag oft versucht noch das zu schaffen, was noch vor Montag umgesetzt sein muß. Das beste Beispiel hierfür sind Deployments, die noch „schnell“ am Freitag live gehen müssen. Schauen Sie an solchen Tagen mal in das Gesicht Ihrer Kollegen, die sich gerade überlegen, was alles schief gehen könnte und überlegen, wie wahrscheinlich es ist, spätestes um 18:00 Uhr das Büro verlassen zu können.

Wie wir es besser machen können

Aber wie können wir es besser machen? Hier sind meine Tipps:

• Planen Sie ihre Woche in der vorhergehenden Woche. Ideal sind Donnerstag und Mittwoch, Freitag geht auch. Wenn Sie jetzt einwenden, daß das zu früh ist, um zu planen, sollten Sie daran denken, daß wir die ganz kleinen Dinge sowieso nicht planen können.
• Lassen Sie den Montag frei und geben Sie sich die Möglichkeit Dinge anzugehen und zu lösen, die liegengeblieben sind oder zu denen Sie über das Wochenende Lösungen gefunden haben.
• Fangen Sie am Freitag keine Aufgaben an, die nicht über das Wochenende liegenbleiben können. Oder möchten Sie am Wochenende das Produktivsystem fixen?

So, Sie müssen ja nicht einverstanden sein mit meinen Ansichten zur Einteilung der Woche, aber vielleicht habe ich Ihnen ja einen Anstoß zum Nachdenken über Ihre Woche gegeben.

Das Apache-Projekt hat sich unübersehbar zu wohl dem OpenSource-Software-Ökosystem entwickelt. Wer auf eine leichte Art und Weise sich darüber informieren will, welche neuen Projekte und Versionen das Apache-Projekt hervorbringt, der sollte ich auf der Announcement-Mailingliste der ASF eintragen.

Es gibt keinen leichteren Weg, sich über neue Entwicklungen im ASF-Ökosystem zu informieren, ohne dabei viel Aufwand zu betreiben, und dabei auch noch auf so manch kleine Perle wie commons compress zu stoßen.

Vor einiger Zeit habe ich mit der Serie Thunderbird aufrüsten begonnen und als erstes Thunderbird-Plugin Nostalgy vorgestellt. Mit Quicktext will ich jetzt diese Reihe fortsetzen.

Quicktext erlaubt es Templates zu definieren, die über Menüeinträge oder freidefinierbare Tastenkürzel in Mails eingefügt werden können. Schön dabei ist, daß die Templates über Variablen auch parametrisierbar sind und sich so leicht Informationen wie Nachname des Empfängers, die aktuelle Uhrzeit oder der Dateiname eines Attachments in Templates verwenden lassen.

Um mir das Schreiben von Anreden und Grußformeln zu erleichtern, habe ich mir beispielsweise die in der unten stehenden Tabelle aufgeführten Templates definiert, die ich über Tastaturkürzel abrufen kann.

Für alle die, die weitere Features brauchen, gibt es eine Professional-Version mit Scripting-Support.

Und was hat das ganze jetzt mit Software-Engineering zu tun? Quicktext ist ein gutes Beispiel für die Automatisierung von Standardaufgaben und damit die Entlastung des Anwenders. Solche Dinge würde ich mir in mehr Programmen und Systemen wünschen.

Fazit: Mit Quicktext kann eine Standardaufgabe wie das Schreiben von Mails wesentlich erleichtert werden und wer keine Lust hat, sich ständig wiederholende Phrasen mehrmals am Tag zu tippen, der sollte sich Quicktext installieren.