Software Engineering Blog

Früher hatte ich einen Zettel an meinem Monitor, auf dem Stand, daß das kein Touch-Screen ist. Es gab einige Kollegen, die immer gern direkt auf dem Monitor gezeigt haben und ich mußte hinterher... Sie kennen das vielleicht noch selbst, denn bei CRT-Monitoren war das noch störender als heute.

Aber bald werden wir schreiben "Berühr mich!" und werden das ganz ernst meinen. Ich habe ja im letzten Artikel schon geschrieben, daß ich der festen Meinung bin, daß die neue Generation von Touch-Screens unsere Arbeit mit Computern verändern werden. Und für uns Software-Entwickler heißt das auch wieder: Auf zu neuen Ufern. Und dabei haben wir ja das letzte Ufer noch gar nicht richtig erkundet. Aber das ist ein anderes Thema.

Multi-Touch für Java!

Hier ist ein Demo, das sehr gut zeigt, was heute auch im Java-Ökosystem möglich ist.

Das Frauenhofer IAO-Institut hat für Java MT4J entwicklet, auf dem das obige Demo beruht. Also, was hält uns auf! Her mit den neuen Ideen!

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.

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:

Hier ein kleiner Veranstaltungshinweis für alle Berliner. Marion Eickmann von agile42 hat es geschafft Mary Poppendieck für den nächsten Berliner Scrum-Stammtisch am 11. Oktober 2009 zu gewinnen.

Wer gerne am Stammtisch teilnehmen würde, erfährt auf dem agile42-Blog alles dafür notwendige.

Die Bildung verliert gegenüber der Ausbildung. Das ist wohl das einzige Ergebnis, welches uns Master und Bachelor bringen. Hierzu paßt gut der Artikel Die Gelehrten von St. John's auf spiegel.de.

Fähigkeit und Können ist immer ein Querschnitt aus unserem Wissen. Unser Wissen stellt uns die Bausteine für unsere Ideen zur Verfügung. Eine leider einseitig gewordene Ausbildung birgt die Gefahr uns nur auf spezielle Gebiete zu beschränken und beschränkt zu bleiben, weil uns der Blick über den Tellerrand fehlt.

Außerdem ist es doch auch sehr angenehm und interessant Kollegen zu haben, mit denen sich einmal über etwas anderes als IT unterhalten kann.

Vor langer Zeit habe ich einmal eine Vorlesung zum Thema Softwareengineering bei Prof. Schlingloff an der Humboldt-Universität besucht und wir bekamen die Aufgaben gestellt die folgenden Begriff zu ordnen:

• error
• failure
• fault
• bug
• defect
• mistake

Das war damals Anstoß für mich, mich tiefer mit Fehlerursachen in Softwaresystemen zu beschäftigen. Dabei wurden wir auch auf das Standardwerk zur Systemzuverlässlichkeit hingewiesen: J.C. Laprie, A. Avizienis, H. Kopetz: Dependability: Basic Concepts and Terminology. Springer-Verlag (englisch, deutsch, französisch). Bedauerlicherweise zählt dieses Buch zu den etwas teueren Fachbüchern. Bei Amazon in Deutschland wird es für gut 200€ angeboten. Bei Amazon in Amerika kann es schon für gut 100$ erworben werden.

Dank dem großen Google konnte ich ein Paper von Laprie, Avizienis und Randell finden, in dem die wichtigsten Konzepte zur Systemverlässlichkeit zusammengefaßt sind.

Für Menschen die sich auch gerne konzeptionell mit solchen Dingen auseinandersetzen ein Kleinod. Haben Sie schon einmal mit einem Kollegen stundenlang über die richtige Exception-Handling-Strategie gestritten? Dann schicken Sie ihm doch einfach den Link zu diesem Artikel...

Hier kann das Dokument gefunden werden...

Hier noch zwei Querverweise zu meinem letzten Artikel Event Driven Software Development, die ich gefunden habe.

Feature-Suppe nennt Tom DeMarco das von mir beschriebene Phänomen, wenn einer Software unkontrolliert und nur auf kurzfristigen Nutzen hin ausgerichtet neuen Funktionalitäten hinzugefügt werden. Als Grund hierfür sieht er das Fehlen einer Person, die das große Ganze im Auge hat und unter diesem Aspekt die Entwicklung koordiniert. Nachzulesen ist dieses Anti-Pattern in
Adrenalin-Junkies und Formular-Zombies - Typisches Verhalten in Projekten
.
Technical Debt lautet die Bezeichnung hierfür bei Martin Fowler die Bezeichnung. Im Unterschied zu Tom DeMarco liegt sein Fokus aber auf den technischen Problemen die sich aus kurzsichtigen Umsetzungsstrategien ergeben. Schnell hinzugehackte Funktionalitäten ala „Chef, in drei Stunden ist das fertig! Dafür muß ich nur hier noch kurz …“ freuen zwar manchen und sind sogar manchmal möglich, doch in der Regel werden bei so sogenannte technische Schulden angehäuft, die irgendwann samt Zinsen wieder abgezahlt werden müssen und zwar dann, wenn all die Schnellschüsse in eine saubere und wartbare Architektur oder Konzept überführt werden müssen.

Alles braucht einen Namen und was wir nicht benennen können ist schwer bis gar nicht in unserer Begriffswelt unterzubringen und es fiele auch ziemlich schwer über diese Dinge zu sprechen, die wir nicht benennen können. All das, dem wir einen Namen geben können existiert und wir können es zum Gegenstand unserer Betrachtungen machen.

Ein gutes Beispiel hierfür ist Event Driven Software Development. Als Abkürzung ist EDSD etwas sperrig, ausgesprochen klingt es nach Dynamik und Aktivität, und strotzt nur so vor Energie. Vom Namen her hat Event Driven Software Development her also die absolute Chance zum neuen Shotting-Star der Software-Entwicklung aufzusteigen.

Wir alle wissen, daß sich die Anforderungen an unsere Software schon recht früh ändern können und die Änderungswünsche nicht nur von außen, sondern auch innen, direkt aus dem Team kommen. Im Idealfall erkennen wir Dinge, die anders, besser und effizienter erledigt werden können oder es wird schnell mal eine Funktion eingebaut, die die Sonderkonstellation 4711 wunderbar abdeckt. Dann kommen noch anderen Abteilungen auf uns zu, die für die eine Veranstaltung oder jeden Kunden eine bestimmte Funktion brauchen. Wir als Softwareentwickler verstehen uns natürlich als Dienstleister nach innen und außen und bemühen uns allen gerecht zu werden und jeden Wunsch so gut wie möglich umzusetzen. All dies bezeichne ich als Events auf die wir bei der Entwicklung reagieren müssen und die sich als Change Request auf die Entwicklungsziele auswirken können.

Unsere Aufgabe ist es diese Events zu steuern und ihre potentielen Auswirkungen einzuschätzen und sie zu managen. Je weiter ein Projekt voranschreitet, desto geringer sollten die Änderungen an ihm werden, da wir sonst unser Ziel nicht erreichen können oder es zumindest gefährden. Also ist die Zeit ein wichtiges Kriterium bei der Behandlung von externen Ereignissen, die zu Änderungsanforderungen führen können. Bis hierher wird es sicherlich keinen Widerspruch geben.

Aber kann jede Änderung, die nicht hinsichtlich Zeit unkritisch ist, auch umgesetzt werden? Nein lautet hier die Antwort. Jede Änderung muß auch danach beurteilt werden, wie gut sie sich in das Produkt, also die Software, einfügt und auch zu den Zielen, die erreicht werden sollen, beiträgt.

Letztendlich zeichnen sich gute Produkte auch durch Konsistenz aus. Konsistenz stellt daher auch ein Qualitätsmerkmal dar, daß es im Auge zu behalten gilt. Denn die wirklich guten Produkte sind in sich konsistent.

Bei jeder Änderung muß also auch kritisch gefragt werden:

1. Trägt diese Änderung zum (strategischen) Projektziel bei?
2. Fügt sich diese Änderung harmonisch in das Produkt ein?
3. Kann das durch die Änderung angestrebte Ziel auch anders erreicht werden?
4. Ist jetzt der richtige Zeitpunkt für diese Änderung?
5. Gibt es andere Änderungsanforderungen, die den gleichen Gegenstand haben und zusammen umzusetzen sind oder sich ausschließen?

Diese Fragen müssen jedesmal gestellt und beantwortet werden. Falls diese Fragen zu keinem positiven Ergebniss führen, sollte die Änderung hintenangestellt werden, denn ansonsten sind wir nur am Hin-Und-Her-Springen und verlieren Zeit und Qualität. Diese Punkte, scheint mir, werden zu oft vergessen, denn kurzzeitiges Denken siegt oft über langfristigen Erfolg. Denn die Rechnung kommt erst später, denn je später eine notwendige Korrektur erfolgt, desto teurer ist sie.

Event Driven Software Entwicklung ist also ein Anti-Muster und verweist auf eine schwache Steuerung innerhalb eines Projekts und sollte die Frage nach der Projekt oder Firmenkultur aufwerfen.

Meine These lautet: Gute Software ist eine notwendige Voraussetzung für langfristigen Erfolg.

Richtig ist aber auch, daß gute Software ein notwendiger Grund für Erfolg ist, aber kein hinreichender. Nur aufgrund guter Software stellt sich kein Erfolg ein, aber es wird leichter erfolgreich zu sein.

Um mit anderen Leute Erfahrungen auszutauschen, ist es auch heute in der (hoffentlich) bald post-2.0-Ära auch am besten, wenn man sich direkt trifft und frei über alle Themen reden kann, die einen interessieren. Doch oft fehlt es an den notwendigen Orten dafür. Ideal sind Orte an denen man sich nicht nur einmal oder sporadisch trifft, sondern die sich auch fest etabliert habe und somit ein fester Bezugspunkt sind. Solche Orte können als Katalysatoren dienen. Denke man hier nur einmal an die Künstlersalons früherer Zeiten.

Solch ein Ort in Berlin kann der newthinking store in Berlin in Berlin werden, über den ich über die JUG Berlin aufmerksam geworden bin.

Ich zitiere die Homepage:

Der newthinking store ist ein Raum für Präsentationen und Veranstaltungen. Über 800 Veranstaltungen, 30 Webmontage und hunderte Präsentationen aus dem Startup-Bereich fanden hier in den vergangenen vier Jahren statt und bilden eine erfolgreiche Plattform für verschiedenste Player aus dem Web2.0 Umfeld. Programmierer, Designer, Webentwickler, Netz-Aktivisten, politisch Interessierte oder einfach interessierte Laien kommen zu unseren zumeist kostenlosen Events und tauschen sich aus. Wir holen das Prinzip der Freien Software an einen realen Ort:

Ein fester Treff- und Informationspunkt der die Stärken, Vorteile und politischen Gestaltungsspielräume von Freier Software einer breiten Öffentlichkeit nahebringt und so einen Raum für eine lebendige Community bietet. Ihre Community?

Für alle also, die in Berlin einen Raum für Veranstaltungen suchen, der wirklich zentral liegt und das nicht nur verkehrstechnisch, sondern auch im übertragenen Sinne, der sollte sich den newthinking store ansehen. Die Preise sind auch sehr moderat, wie man dem Factsheet entnehmen kann.

Kennen Sie das? Sie möchten eine Software ausprobieren (ich schrecke jetzt vor dem Wort evaluieren mal zurück), laden sich die aktuelle Version als zeitlich- und limitierte Version herunter und haben dann genau 30 Tage Zeit zum Testen. Dummerweise fallen genau in diese 30 Tage verschiedene Aufgaben, die absolut nicht warten können und schwupps, die Testperiode ist rum. Ärgerlich, denn wenn die Lizenzmechanismus einer besseren Sorte ist, reicht es weder die Uhr vor dem Start zurückzustellen noch sonst etwas leicht vertretbares dagegen zu unternehmen. Es ist ja nicht so, daß die Firmen bei Gefallen nicht auch für ihr Produkt bezahlt werden sollen, aber 30 Tage sind in der Arbeitswelt nicht viel.

Vor ein oder zwei Jahren hatte ich mich nach einem UML-Tool für ein Projekt umgesehen und mir dabei auch unter anderem MagicDraw angesehen. Jetzt im Dezember hatte ich dank der Feiertage etwas freie Zeit und habe diese auch dafür genutzt mir MagicDraw noch einmal anzusehen und habe mir natürlich die aktuelle Version downgeloadet und mir eine Lizenzdatei zuschicken lassen. Beim ersten Start war ich dann verblüfft: Evaluierungszeitraum 180 Tage!

Innerhalb eines halben Jahres sollte es möglich sein, sich eine Meinung bei ernsthaften Interesse zu bilden. Wie sicher muß sich eigentlich eine Firma bei der Einschätzung des Mehrwertes ihrer Software sein, um eine solange Testphase zu ermöglichen?

Weiter so!