Software Engineering Blog

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.

Am Rande habe ich Gunter Dueck schon einmal hier im Blog gestreift. Da er seine DD auch als PDF bereitstellt, lade ich sie mir immer "für später", also wenn man mehr Zeit ist, herunter.

Im DD 99 setzt er sich mit Elite, deren Verantwortung auseinander und greift dabei bis auf Platon zurück. Er schließt mit:

Eigentum verpflichtet. Elite verpflichtet. Bildung verpflichtet. Adel verpflichtet, Stärkev erpflichtet.
Wer je das Privileg hatte, oben zu sein, hat damit eine Pflicht auf sich geladen. Elite ist nicht oben sein, sondern unten helfen und führen.

Gut, Dueck hat sein DD bezogen auf die Bundestagswahlen bezogen, aber greift das nicht auch auf Führung von Menschen in Unternehmen? Führung kommt von führen...

Seit Oracle Sun gekauft hat, steht oft die Frage im Raum, welche Sun-Produkte und -Geschäftsfelder Oracle fortsetzen will. Oracles offzielle Stellungnahme kann hierzu unter der URL http://www.oracle.com/ocom/groups/public/documents/webcontent/038563.pdf gefunden werden.

JIRA 4 ist da und wartet mit einer Vielzahl von neuen Features auf, wobei ich mir auch manches langbestehende Manko (JRA-9, JRA-1549) behoben gewünscht hätte. Trotzdem beeindrucken mich auch die neuen Funktionen wie ein neues Dashboards, Activity Streams, die OpenSocial-Integration sowie das allgemein verbesserte UI. Einen Überblick über die neuen Features gibt es bei Atlassian-TV.

Das Killerfeature an sich ist für mich aber die SQL-ähnliche Jira Query Language, mit der sich jetzt endlich auch komplizierte Anfragen bauen lassen, die über das bisherige Interface nicht möglich waren. So kann jetzt beispielsweise nach leeren Feldern gesucht werden, um zu herauszufinden, welchen Issues noch notwendige Felder fehlen. Auto-Completion und Syntaxcheck im Webeditor – was will man mehr? Mehr zur JQL gibt es hier in diesem Atlassian-TV-Beitrag oder in der JIRA-Dokumentation.

Böse Zungen könnten natürlich behaupten, daß es sich bei der JQL nur um eine Query-Translation nach SQL handelt. Vielleicht nicht falsch, aber: "Na und?"

Aus Vertriebssicht ist JIRA 4 auch interessant, da Atlassian das Preismodell für seine Produkte geändert hat und jetzt eine Mischung aus Penetrationsstrategie und Hochpreispolitik (im Vergleich zu den vorherigen Preisen) fährt. Früher gab es drei Versionen mit unterschiedlichen Funktionsumfang: Standard, Professional und Enterprise, wobei die Entprise-Version bei 4.800 Dollar lag. Seit JIRA 4 wird jetzt nur noch der Anzahl der existierenden Benutzern lizensiert. Der Einstieg liegt jetzt bei 10 Benutzern für 10 Dollar. In Hinsicht auf sein Preis-Leistungsverhältnis ein fast unschlagbares Angebot. Auf der anderen Seite muß man für mehr als 100 Benutzer jetzt 8.000 Dollar zahlen und 100 Benutzer sind nicht viel. Wie gesagt, es wird für existierende Benutzer gezahlt und selbst in kleinen Firmen sind 100 Benutzer nicht viel. Man denke nur an Praktikanten und die natürliche Flukturation. Insofern eine doch schon sehr drastische Preiserhöhung.

Mit einem Einstiegsspreis von 10 Dollar sollen ganz klar weitere Marktanteile erobert werden. Gerade kleinere Firmen werden hier sicherlich einsteigen und bei entsprechender Zufriedenheit aufrüsten (müssen). Abgesehen von Opensource-Produkten wie Bugzilla, wird diese Preispolitik anderen Anbietern das Leben in den unteren Preissegmenten erschweren, auch wenn das richtige Geld in den oberen verdient wird. Das Positive daran ist aber auch, daß auch in der kleinsten Ausbaustufe der komplette Funktionsumfang bereit steht und bei Bedarf nur die Anzahl der Benutzer erhöht werden muß.

Mein Fazit: Trotz des effektiv erhöhten Preises ist es das beste JIRA bis jetzt, da es nicht nur kosmetische Änderungen gab, sondern neue interessante Features, die die Arbeit erleichtern und angenehmer machen.

An diesem Wochenende haben wir uns Karten für das Berliner Gorki-Theater gekauft, um uns Anna Karenina von Lev Tolstoj anzusehen.

Um halbwegs vorbereitet in das Stück zugehen, wollte ich mir die wichtigsten Fakten zur Geschichte zusammengooglen, da der Roman mehr als nur einen Handlungsstrang hat und ich im Theater nicht in Gefahr kommen wollte, den Überblick zu verlieren.

Tolstoj leitet seinen Roman mit dem Satz ein: "Alle glücklichen Familien sind einander ähnlich; aber jede unglückliche Familie ist auf ihre besondere Art unglücklich." Daraus wird abgeleitet, daß für das gemeinsame Glück mehrere Dinge notwendig sind, die auch erfüllt sein müssen. Fehlt es an einem, kann es kein Glück geben.

Verallgemeinert bedeutet das:

• Für das Gelingen einer Sache sind immer mehrere Faktoren zu erfüllen.
• Fehlt einer der Faktoren, kann die Sache nicht gelingen.

Dieses Prinzip kennen wir aus unserere eigenen Erfahrung und es erklärt sehr einfach, warum Dinge wie zum Beispiel Projekte trotz vieler Erfolge und größter Anstrengungen an Kleinigkeiten scheitern können.

Jetzt endlich habe ich dafür einen griffigen Namen...

Diese Tage findet in Berlin eine Konferenz zum Thema agiles Softwaretesting statt, wodurch der Berliner Scrum-Stammtisch die Möglichkeit hatte Mary Poppendieck einzuladen und ich Marry Poppendieck kennenzulernen.

Marry Poppendieck ist durch ihre Arbeiten zu Lean Software Development mit Büchern wie Lean Development Software: An Agile Toolkit for Software Development Managers und Leading Lean Software Development: Results Are Not the Point bekannt geworden. Dementsprechend war das Thema des Abends gesetzt: Lean Software Development – What Lean Brings to Agile. Die Vortragsfolien können im Blog-Eintrag von agile.42 gefunden werden.

Inhaltlich kann ich dem an diesen Abend gesagten voll zustimmen, auch wenn es mir auf den ersten Blick schwerfällt, Lean von Agile im praktischen Leben abzugrenzen, den die Schnittmenge zwischem beiden dürfte in der Realität, dort wo Agilität wirklich gelebt wird, sehr hoch zu sein. Höchtens vielleicht so: Agile sagt uns wie wir etwas tun können, Lean sagt uns, was wir zu tun haben. Oder auch umgekehrt.

Die Ähnlichkeit zwischen Lean und Agile wird an Poppendiecks vier Lean-Merkmalen deutlich:

Lean in a Nutshell

1. System Thinking - Customers don’t want software.
2. Technical Excellence - Correctness can be proven at any time.
3. Reliable Delivery - Design the system to meet the constraints.
4. Relentless Improvement - Learn how to learn.

Wie Lean funktionieren kann, hat Marry Poppendieck sehr gut am Beispiel des Empire State Buildings dargelegt, das in weniger als eineinhalb Jahren gebaut wurde.

Insgesamt ein sehr interessanter Abend, von dem ich viele Denkanstöße mitnehmen konnte und bereits gewußtes in meinem Kopf wieder freigelegt wurde.