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!

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.

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:

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

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.

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

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.

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.

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.