Ist das in der Software-Entwicklung genauso? Die OOP hat sich ja in diesem Jahr auch so ein Motto auf die Fahne geschrieben: people, process, technology. Prüfen wir doch mal: people = mano e mente, process = macinatura, technology = macchina – nanu, wo bleibt miscela, die Mischung, der Rohstoff, aus dem die Software entstehen kann?

Alistair Cockburn hat diese Frage 2006 in einem Artikel beantwortet: “Software engineering … is remarkably like manufacturing, once we shift to view the unvalidated decision as the unit of internal inventory.” Die Mischung besteht also aus den bisher unvalidierten Entscheidungen, die in der Mühle und der Maschine immer weiter verarbeitet werden, bis der Benutzer seine neue Software in Händen hält.

Beispiele für solche unvalidierten Entscheidungen sind:

• Jede Anforderung ist eine Entscheidung, die auf einem bestimmten Geschäftsklima basiert. Wenn sich das Klima ändert, könnte die Entscheidung falsch werden.
• Eine Architektur ist eine Entscheidung, die auf Technologie und Business basiert. Wenn sich die Technologie verändert bevor die Software genügend Wert für das Business eingespielt hat, ist die Entscheidung verschwendet.
• Jede Zeile Code ist eine Entscheidung, basierend auf Anforderungen, Technologie und Ästhetik. Sollte eines davon obsolet werden bevor die Software genügend Geld für die Firma verdient hat, dann war auch das Verschwendung.

Halten wir also am besten die Zyklen kurz und schlank und erzeugen nur so wenig unvalidierte Entscheidungen wie möglich. Über Anforderungen rasch entscheiden, Entwurf und Programmierung zeitnah durchführen, dem Benutzer lauffähige Systeme in die Hand geben, die er sofort validieren kann. So bleibt der Kaffee frisch, weil die Bohnen nicht lange liegen.

Ich lade Sie ein, mit mir auf der OOP einen Kaffee zu trinken!

Anmeldung und Organisation übernimmt SIGS-DATACOM, auf deren Website Sie weitere Informationen über dieses Training finden können.

Ich freue mich, Sie in Köln zu sehen – das Training wird sehr spannend werden!

Ich habe die Konferenz rundum genossen und hoffe, dass Sie alle möglichst viele der neuen Ideen umsetzen werden, die Sie auf der OOP 2009 bekommen haben!

Wenn viele an etwas glauben, nennen wir das Kultur. Wenn wenige an etwas glauben, nennen wir das Kult. Wenn zwei an etwas glauben, nennen wir das Liebe. Wenn nur einer an etwas glaubt, nennen wir ihn verrückt!

Nicht nur, dass sie erstklassigen Content präsentiert, nein, man merkt ihr auch die jahrelange Sprecher-Erfahrung an: Sie spricht langsam, klar, mit Pausen nach den wichtigen Stellen, warmherzig und begeistert. Es ist sehr leicht, Ihr zu folgen und es macht einfach Freude!

Das Tutorial drehte sich um den typischen Fall: Man war auf einer Konferenz, hat neue Ideen bekommen, hat Bücher und Artikel gelesen und möchte nun, dass diese Idee in einer Firma Wirklichkeit wird. Linda beschrieb in ihrem Tutorial, wie man das schaffen kann.

Ich kam ein paar Minuten zu früh in den Konferenzraum – sie nutzte gleich die Gelegenheit, mich in ihr kleines Theaterstück einzubauen: sie setzte mir einen selbstgemachten Hut auf mit der Aufschrift “Innovator”. Anderen Zufrühkommern gab sie ebenfalls solche Hüte mit Aufschriften wie “Evangelist”, “Guru”, “Early Adopter” usw. Wir bekamen dann noch ein Skript und Regieanweisungen, und los ging’s.

Der Evangelist möchte die neue Idee allen erzählen. Zuerst erzählt er davon dem Innovator und bezeichnet die Idee als neu und cool. Der Innovator (also ich) sagte sofort zu, dabei mitzumachen. Den Guru, ein repektables Mitglied der hypothetischen Firma, musste der Evangelist nun mit Fakten überzeugen und ihn bitten, die neue Idee doch in seinem Projekt einmal auszuprobieren.

Nach dem Guru erfahren die Early Adopter davon und probieren die Idee ebenfalls aus. Auf einem “Brown Bag” Meeting, bei dem alle ihr Sandwich mitbringen (in den USA kommt das in der braunen Tüte!), erzählt der Evangelist mehr von der neuen Idee und lässt die Early Adopters von ihren Versuchen berichten.

Die Early Majority hört nun von den Erfolgen und probiert es ebenfalls aus. “Wenn meine Freunde und Kollegen es tun, kann ich es ja auch mal versuchen.” Die Idee verbreitet sich im Unternehmen. Die Late Majority macht erst mit, wenn sie muss. Die “Laggards”, das sind die Nachzügler, machen erst mit, wenn sowieso alle anderen mitmachen. Zum Schluss erkennt der Chef die Fähigkeiten des Evangelisten und gibt ihm Zeit, die neue Idee nun offiziell in der Firma weiterzuverfolgen.

Linda stellt eindrücklich dar, welche Maßnahmen man treffen sollte, damit sich dies wirklich so entwickelt. Beispiele:

• Do Food – gib den Leuten etwas zu essen, dann vertrauen sie dir und hören zu
• Ask for Help – bitte die Zweifler um Hilfe und involviere sie dadurch
• Test the Waters – probiere die neue Idee an einem Beispiel aus, um Daten darüber zu gewinnen
• Trial Run – gib den Kollegen die Möglichkeit, die neue Idee in einem bestimmten Zeitraum auszuprobieren, ohne dass sie sie gleich übernehmen müssen
• Whisper into the General’s ear – falls der Chef in Gruppen nicht gern über Neues spricht, greif ihn bei Gelegenheit ab und sprich allein mit ihm über die neue Idee
• Just Do it – mach kein offizielles Pilotprojekt, sondern wende die neue Idee in einem Projekt an, das ohnehin durchgeführt wird

Zum Schluss des Tutorials kam noch eine interessante Wendung: Linda stellte dar, dass diese Patterns nicht nur geeignet sind, Organisationen zu verändern, sondern auch dazu dienen können, bei sich selbst als Individuum eine Veränderung zu bewirken.

Wirklich faszinierend! Danke, Linda!

Zwei tiefgehende Tutorials, am Montag und am Freitag:

• Linda Rising kommt und bringt uns bei, wie wir die ganzen coolen Sachen, die wir auf der OOP lernen, anschließend mutig im Unternehmen umsetzen, wie wir uns dabei Hilfe holen und die Menschen von den notwendigen Veränderungen überzeugen können.

• Alice Heiliger und ihr Team ermöglichen den Managern, die am Workshop teilnehmen, ein Ensemble von Musikern zu dirigieren – keine alltägliche Erfahrung! Es muss völlig faszinierend sein. Die Orchestermetapher für ein Software-Entwicklungsteam ist ja schon länger bekannt, hier wird sie tatsächlich erlebbar.

Acht interessante Vorträge am Dienstag und Mittwoch:

• Professor Gunter Dueck von der IBM wird für Entwickler den Dolmetscher Richtung Management spielen. Wie überzeuge ich jemand, der nicht so tief im Thema steckt wie ich? Herr Dueck wird uns in seiner bewährten satirisch angehauchten Vortragsweise die besten Antworten auf diese Frage vorstellen.

• Gernot Starke erzählt uns, wie wir bei all dem Multitasking, das heutzutage an den Schreibtischen passiert, mit unserer Zeit auskommen. “Zeitmanagement…” – Gernot, was tun wir nur? Du wirst zeigen, wie man etwas managt, von dem ich (ein paar Kaffeepausen später) in meinem Vortrag behaupten werde, dass es gar nicht existiert! Das finde ich richtig spannend!

• Ebenfalls am Dienstag komme ich mit meinem Vortrag “Gebrauchsanleitung für die Projekt-Matrix“. Haben Sie Matrix gesehen? Wenn nicht, tun Sie’s! Die DVD gibt’s preiswert zu kaufen, und es ist einfach ein genialer Film, auf den ich in meinem Vortrag Bezug nehme. Für die, die den Film schon gesehen haben: Glauben Sie immer noch, dass ein Softwareprojekt real ist? Besser Sie tun es nicht, dann haben Sie es wesentlich leichter, Soft Skills zu erwerben. Warum das so ist und wo der Schlüssel dafür hängt, sag ich Ihnen am 27. Januar.

• Ralf Westphal und Renate Klein räumen mit Mythen der Kommunikation auf. Das ist gut so! Kommunikation ist eine der am meisten missverstandenen menschlichen Fähigkeiten, gleichzeitig die faszinierendste und notwendigste überhaupt, denn die Welt entsteht erst im Dialog, vorher existiert sie nicht.

• Ralph Höfliger und Hans-Jürgen Plewan haben sich das Thema “Kultur” auf die Fahnen ihrer beiden Vorträge geschrieben. Der eine betrachtet das ganze Unternehmen, der andere die Kultur im Projekt. Es geht um die impliziten Regeln, die wir alle bei der Arbeit nutzen und die uns selten bewusst sind.

• Adam Bien, wenn Du es schaffst, mir verständlich zu erklären, wie man Dream Teams baut, dann geb ich Dir einen aus! Es ist immer wieder erstaunlich: Manche Entwickler verstehen in fünf Sekunden, worum es geht, schreiben in 60 Sekunden den richtigen Test dafür, implementieren in den folgenden 300 Sekunden und fragen den Kunden, ob es das ist, was er wollte! Adam, wenn Du diese Leute meinst, werde ich Deinen Vortrag besuchen!

• Elisabeth Heinemann, Professorin für Soft Skills an der FH Worms kommt: Ich bin begeistert, dass es dieses Unterrichtsfach inzwischen gibt! Wenn Sie uns zeigen, wie man die Leute vom Fachbereich leichter versteht, kann das allen unseren Projekten nur gut tun! Die Menschen aus der Domäne sprechen nämlich manchmal so seltsam mit uns IT-Leuten…

Liebe Teilnehmer, Sie sehen schon: Eine runde Zahl von 10 interessanten Veranstaltungen warten allein in diesem Track auf Sie. Als Track Chair verspreche ich Ihnen: Sie werden die Konferenz genießen und viele neue Fähigkeiten mit nach Hause nehmen können!

Not invented here

ist ein Bug im Teamprozess, der im Projekt sehr teuer werden kann. Jemand entscheidet sich, etwas noch einmal zu entwickeln, was es bereits gibt, z.B. Persistenzframeworks, Logging, Caching, usw. nur weil er glaubt, das Fertigprodukt nicht nehmen zu können. Der tiefere Grund liegt darin, dass er den Kick sucht, den die Neuentwicklung einer nicht-trivialen Komponente in seinem Kopf auslöst.

Web 2.0 für Freunde – Googles OpenSocial API

In diesem Vortrag beschäftigte ich mich mit einer neuen Schnittstelle, die Google definiert hat und die nun von mehreren sozialen Netzwerken wie LinkedIn, Hi5, MySpace u.a. implementiert wird. Die Schnittstelle ermöglicht es Anwendungsanbietern, kleine so genannte “Gadgets” zu schreiben, die in einem IFrame auf der Webseite des sozialen Netzwerks ablaufen können. Ich habe als Sample eine in Grails realisierte Schokoladen-Datenbank über das OpenSocial API an ein soziales Netzwerk (Orkut) angebunden. Dadurch wurde es den Mitgliedern des Netzes möglich, ihre jeweilige Lieblingsschokolade zu bewerten und die Bewertungen Ihrer Freunde ebenfalls auf der eigenen Profilseite zu veröffentlichen. Natürlich ist das nur eine Demo, die keinen geschäftlichen Hintergrund hat.

LinkedIn hat eine andere OpenSocial Anwendung veröffentlicht: Man kann als Mitglied des Netzes sehen, welche Events (Konferenzen, Seminare, etc.) anstehen und darstellen, an welchem Event man selbst teilnimmt. Danach ermittelt die Anwendung, welche Freunde am selben Event teilnehmen, so dass man sie treffen kann. Recht sinnvolles Beispiel.

Semantic Web zum Anfassen

Heiko Haller vom Forschungszentrum Informatik (FZI) in Karlsruhe und Felix Kugel von Orientation in Objects in Weinheim stellten das Semantic Web vor. Dabei geht es darum, die im Web vorliegenden, unstrukturierten Informationen mit Semantik zu hinterlegen. Im Vortrag wurden Beispiele vorgestellt sowie Startpunkte für die Suche nach Ontologien gegeben, die sich für EAI via SOA und Web anbieten. Danach wurden Tools gezeigt, die die einschlägigen Standards (RDF, OWL, SPARQL) auf Java-Ebene transportieren.

Beispiel für die Anwendbarkeit von Semantic-Web: Sie suchen in Flickr nach “Jaguar” und bekommen Bilder von Raubkatzen und von Sportwagen. Was wollten Sie wirklich sehen? Nur weil Flickr nicht weiß, was für eine Semantik hinter dem Wort “Jaguar” steckt, stellt es zu viele Suchergebnisse dar. Mit dem Semantic Web könnte man das ändern.

Interessant auch ein weiteres Beispiel: Gegeben eine Datenmenge, in der die Konzepte “Student”, “Institut”, “Universität” und “Stadt” vorkommen. Das Semantic Web könnte die Frage “Wo ist Peter?” beantworten, wenn es weiß, dass Peter ein Student ist, der an einem bestimmten Institut studiert, das zu einer bestimmten Universität gehört, die sich in einer Stadt befindet. Es würde diese Kette “durchdenken” und antworten mit “Peter ist in Karlsruhe”. Man nennt diese Systeme Reasoning Engines, also etwa “Nachdenkmaschinen”. Es gibt sie, ja sie sind sogar schon viele Jahre alt – und kommen erst jetzt so richtig zum Einsatz.

Felix Kugel von OiO zeigte eine Erweiterung für Wikipedia, das semantic wiki. Aus der Grundstruktur von Wikipedia, nämlich “Thema->Link->Thema”, lässt sich mit etwas Semantik etwas anderes machen, nämlich “Subjekt->Prädikat->Objekt”. Damit kommt man zu wesentlich besserer Wartbarkeit der Wikiseiten, es lässt sich Redundanz entfernen, es muss nicht mehr so vieles von Hand an allen möglichen Stellen nachgetragen werden.

Schließlich gaben die Referenten noch einen Hinweis auf einen vor Kurzem online gegangenen, neuen Semantic Web Service: openCalais, powered by Reuters. Die Nachrichtenagentur hat einen Service online gestellt, dessen Anwendung denkbar einfach ist: Man schickt per Webservice Aufruf einen englischen Text an den Service und erhält als Ergebnis ein semantisches Netz mit Subjekten, Prädikaten, Objekten zurück, aus dem man dann selbst per Software weitere Schlüsse ziehen kann. Man darf max. 40000 Calls pro Tag an diesen Service richten.

Organic Programming oder: Wie entwickle ich ohne Entwickler?

Das war zum Abschluss der Jax einer der schärfsten Vorträge, die ich gehört habe. Er hieß “Software ist härter als Hardware”. Dr. Falk Langhammer von der Firma Living Pages Research GmbH bemühte sich redlich, seinen Zuhörern ein neues Konzept klar zu machen. Software muss komplex sein können, ohne kompliziert zu werden, gut OK, das versteht noch jeder. Der Ansatz jedoch, eine Demo zu zeigen, wie das denn umgesetzt werden sollen, scheiterte kläglich. Man schreibt nach dem neuen Vorschlag heute keine Klassen mehr, sondern Ercatons. Ercatons sind Kombinationen aus XML-Dateien für Daten und Java-Dateien für Methoden. Damit soll der Unterschied zwischen Objekten und Dokumenten aufgehoben werden – warum nur? Warum wird Komplexität dadurch leichter handhabbar? Keine Ahnung.

Die Demo zeigte eine Anwendung für die amerikanischen Wahlen. Als Beispiel ein Wahlzettel (Dokument und Objekt gleichzeitig). Als Daten waren drei Integers enthalten, die Stimmenzahlen für Clinton, Obama und McCain, etwa so:

<vote>
<clinton>0</clinton>
<obama>0</obama>
<mccain>0</mccain>
</vote>

Als Methoden gab es jeweils eine, die einen der drei Zähler hochzählt, also drei Stück insgesamt. Aus den Daten wurden gleichzeitig Felder auf einer Webseite, aus den Methoden wurden Buttons, auf die man klicken konnte. Etwa so: Man klicke auf den Button für die Methode voteForObama, dieser Button löst dann eine Action aus, die sieht so aus (die genaue Syntax ist mir entfallen):

<erc:action name=”voteForObama”>
/bin/increment xpath=”//vote/obama”
</erc:action>

Dr. Langhammer versuchte, darzustellen, dass diese Syntax so einfach sei, dass man nicht einmal mehr Software-Entwickler dazu bräuchte. Speziell ausgebildete Leute beim Kunden würden dafür völlig ausreichen. Warum man nun manchmal eine Mischung zwischen XML und Linux-Commandline-Syntax und ein anderes Mal Java-Methoden braucht, blieb unklar.

Besonders trickreich dann die Verwendung von XPath-Expressions im Java-Code: Die Methoden in Java setzen die Daten, die im XML-Dokument definiert sind, per XPath-Expression:

document.setX(“//vote/mccain”, 0);

Na dann, viel Spaß bei der Wartung dieser Kombination – man ändere die Struktur der Daten, und die XPath-Expressions müssen in einer ganz anderen Datei mit angepasst werden. Dafür gibt es leider noch kein Refactoring-Tool, was das macht, doch es entstehen schon große Projekte auf Basis von Ercatons. Mir ein Rätsel, wie man so ein Konglomerat von Sprachkonstrukten jemals stabil bekommen will.

Letztendlich wurde argumentiert, man bräuchte keine Klassen, sondern man schreibt in Ercatons die Instanzen(!) hin. Instanzen kann man klonen und erweitern mit Daten und Methoden. Sicher, das ähnelt z.B. dem Prototype-Konzept in JavaScript, das ja selbst auch keine Klassen kennt. Doch rein syntaktisch finde ich Ercatons zehnmal so kompliziert wie JavaScript, und ich dachte, man wolle komplizierte Sachen vermeiden? Außerdem, wie geht das denn, wenn ich zehn Millionen Adressen verwalten will, schreibe ich die dann alle in Ercaton-Instanzen? Nein, sie kommen in eine relationale Datenbank, hieß es. Naja, wie denn nun, Dokumente, Objekte oder relationale Daten – wir nehmen das, was uns grad passt, rühren kräftig um und heraus kommt eine Anwendung?

Liebe Leute, ich rege mich sonst nicht gleich so auf, aber das war wirklich abenteuerlich, was Ihr da gezeigt habt! Auf jeden Fall, ein echt heißer Abschluss dieser Jax, ich komme im nächsten Jahr gerne wieder.

On Tuesday, I gave a talk about the new QVT standard in MDA, today I’ll give another talk about the role of software architect in today’s projects.

It was good to meet Axel Uhl from SAP as well as Markus Voelter, Bernd Kolb and other people from the open source MDA/MDSD community here in Europe. We discussed advanced subjects on which I can base strategic decisions how to target AndroMDA towards serious large scale applications. Requirements to AndroMDA are increasing and we (andromda.org) have to cope with that using rock-solid concepts. I’ll explain that in more detail at http://forum.andromda.org . Bernd Kolb helped me to set up the Eclipse colorer profiling tool on my machine to track down a performance problem when loading UML2 models.

The 3 hour show will be quite exciting, I am pretty sure. There will be two iterations with requirements, application design, implementation and test, separated by a break. Peter Friese from Lufthansa Systems and I will pair on stage, each one modeling, generating and implementing certain parts of the new application.
We’ll use AndroMDA as the code generator of choice, of course.
Come and enjoy! You’ll find more info at http://www.openarchitecture.de/. You can also register there, using the online form.