Software Engineering Blog

Gerade habe ich meinen Artikel zu Apache Hadoop bei heise Developer abgegeben. Sobald er durch die Redaktion durch ist, werde ich den Link zum Artikel hier posten.

How the Mighty Fall ist ein Buch von Jim Collins, der darin den Aufstieg und Fall von großen Unternehmen beschreibt und das erinnert mich gerade an Toyota.

Zur Erinnerung: Toyota hat diese Woche eine große Rückrufaktion für seine Wagen aufgrung von defekten Gaspedalen gestartet und im Rahmen der Wirtschaftskrise sich auf dem US-amerikanischen Markt übernommen.

Toyota? Die Firma, deren Management- und Produktionsmethoden nicht unberechtigt auch auf die agile Softwareentwicklungsbewegung großen Einfluß ausgeübt hat? Ich möchte hier nur einmal an Scrum und Kanban erinnern.

Wie kann das sein? Toyota wird wie soviele Unternehmen irgendwann seinem Erfolg erlegen sein und wollte in zu kurzer Zeit zu viel erreichen. Den auch in der Softwareentwicklung wissen wir, daß Zeitdruck und der Zwang zum Erfolg meist eine adversen Effekt hat und jedes System nur mit der ihm eigenen Geschwindigkeit wachsen kann.

Auch wenn manche schon vom Ende von Toyota sprechen, wird es dazu nicht so schnell kommen, denn nicht jede Krise bedeutet das Ende. Vielmehr ist die Frage immer, ob aus Krisen die richtigen Schlußfolgerungen gezogen und auch umgesetzt werden.

Alexander Kriegisch von Scrum-Master.de hat dem "Scrum on a Page" von William c. Wake aktualisiert und über seine Homepage uns allen zur Verfügung gestellt.

Scrum-On-A-Page faßt kurz für den täglichen Gebrauch die Scrum-Rollen, den Prozess und die wichtigsten Inhalte der Meetings und die Scrum-Artefakte zusammen.

Hier geht es zum Download...

Wie gestern versproche, habe ich meinen Vortrag zu MapReduce und Apache Hadoop auf Slideshare online gestellt.

Morgen halte ich einen kleinen halbstündigen Einführungsvortrag zu dem MapReduce-Programmiermodell und dem Apache Hadoop-Framework. Die Folien werde ich anschließend über SlideShare online stellen.

Wenn wir mit anderen zusammenarbeiten besteht immer die Gefahr sich gegenseitig zu stören. Wir arbeiten im gleichen Projekt, bearbeiten die selben Klassen, schreiben in die selbe Datenbank, gegen die der Kollege seine Tests fährt, machen Änderungen, die sich gegenseitig ausschließen. Oft stellt das kein Problem dar, wenn es koordiniert oder zumindest mit dem Wissen der Kollegen geschieht. Was ist aber, wenn wir genau das nicht wollen? Wenn wir in Ruhe die nächsten zwei Wochen an einem ganz besonderen Feature arbeiten wollen oder ein größeres experimentelles Refactoring vornehmen wollen? Es geht aber nicht nur um die großen Aufgaben. Auch in unserer alltäglichen Arbeit, sollte die Gefahr mit der Arbeit Anderer zu kollidieren möglichst gering sein.

Wir müssen uns also isolieren können und unsere Entwicklungslandschaft muß das unterstützten, uns dafür die technischen Möglichkeiten geben. Solange es für ein gesamtes Team nur eine Datenbank, auf der alle arbeiten, oder nur einen Application Server gibt, gelingt das nicht. Solche Systeme nenne ich immer scherzhaft Synchronisationssingularitäten, also Punkte, an denen alle Arbeiten zusammenlaufen laufen. Aber was bedeutet jetzt Isolation für eine Entwicklungslandschaft?

Hier meine Definition:

Isolation ist die Fähigkeit einer Entwicklungslandschaft an dem SUD (System Under Development) Änderungen vorzunehmen, ohne dabei von Anderen ungewollt beeinflußt zu werden oder Andere ungewollt zu beeinflußen.

Ein sehr gutes praktisches Beispiel für Isolation unterstützende Werkzeuge in einer Entwicklungslandschaft sind Versionsverwaltungssysteme wie Subversion oder Git, das die Isolation durch seinen dezentralen Ansatz noch weiter vorantreibt als früher CVS oder jetzt Subversion. Aber der Einsatz eines Versionskontrollsystems kann nur ein erster Schritt sein. Abgesehen davon: zeitgemäße Softwareentwicklung ohne Versionskontrollsystem ist ein Widerspruch in sich.

Heute lassen sich die meisten Systeme, die wir für Entwicklung und Test benötigen ohne Probleme für jeden Entwickler bereitstellen. Eine eigene Datenbank auf dem Laptop, ein lokaler FTP- oder Mailserver oder auch Applikation-Server sind immer möglich. Manche dieser Systeme müssen sogar nicht festinstalliert werden, sondern können im Rahmen eines Builds installiert und konfiguriert werden. JBoss, GlassFish und Apache Tomcat können aus ZIP-Archiven vollständig installiert und angepaßte Konfigurationsdateien anschließend generiert werden. Wird eine saubere Installation gebraucht, wird die alte gelöscht und eine neue automatisch installiert. Mit etwas Ehrgeiz ist das durchaus möglich.

Aber Isolation bringt noch weitere Vorteile für die Software-Entwicklung:

• Ruhe und Ungestörtheit, weil es nicht ungewollt zu Konflikten mit den Arbeiten von anderen Entwicklern im Team kommt. Änderungen werden nur noch gewollt zusammengeführt.
• Verbesserung der Reproduzierbarkeit, weil alle positiven und negativen Effekte nur durch mich selber verursacht wurden und beispielsweise Testergebnisse so nicht verfälscht werden.
• Besseres Konfigurationsmanagement und Setup, weil Isolation als Ziel besondere Maßnahmen erfordert, die zwangsläufig auch zu Zielen wie besserer Modularisierung und Konfigurierbarkeit führen.

Wenn wir beim Aufbau unserer Entwicklungslandschaft Isolation konsequent von Anfang an verfolgen und beachten, erhalten wir die Chance besser im Team zusammenarbeiten zu können, weil wir es dann geschafft haben gegenseitige Abhängigkeiten weiter aufzulösen. Gerade für agil arbeitende Teams sollte Isolation immer ein zu erreichendes Ziel sein, den deren Fehlen stört den Arbeitsfluß.

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.