Clean Code Developer - Ein Weg zu mehr Professionalität [OOP 2009]

Softwareentwicklung ist zwar eine Profession - aber läuft sie auch immer professionell? Ich glaube - oder besser: Stefan Lieser und ich glauben, dass das leider nicht der Fall ist. Die Gründe dafür sind vielfältig.

Da ist zum einen die Jugend unserer Branche: in nur 60 Jahren hat sich bisher kaum ein Konsens herausbilden können, was denn nun wirklich professionelle Softwareentwicklung ausmacht.

Da ist zum anderen der ewige Fachkräfte-Notstand: weil soviele Softwareentwickler immer noch oder immer wieder fehlen, gibt es keine einheitliche Ausbildung. Unternehmen stellen ein, wer halt irgendwie demonstrieren kann, dass er es mit der Softwareentwicklung ernst meint.-

Und schließlich brodelt es bei den Technologien ständig so, dass es wichtiger scheint, etwas Neues zu lernen, als sich auf etwas als Branche einzuschießen. Objektorientierung und Agilität sind zwar gewisse Konstanten, doch von einem Konsens im Sinne von "So tut man es und nicht anders!" sind wir dennoch weit entfernt.

Wir meinen nun, dass solcher Konsensmangel bei allem Verständnis für seine Ursachen, immer kontraproduktiver wird. Denn da der Fachkräftemangel wieder einmal nach einer Zeit der Ruhe ganz offensichtlich ist, stellt sich ja auch die Frage ganz dringlich: Wer ist denn ein guter, ein wirklich professioneller Softwareentwickler?

Dazu kommt die Erkenntnis, dass Ausbildungen auf einer Plattform wie .NET oder Java oder in einem Paradigma wie der Objektorientierung eben nicht zwangsläufig auch zu gutem Code oder hoher Produktivität führen.

Gelegentlich der Lektüre des Buches "Clean Code" von Robert C. Martin sind Stefan und ich deshalb auf die Idee gekommen, es als Ausgangspunkt für eine Bewegung für mehr Professionalität zu machen.

Die dortigen Empfehlungen sowie einige andere scheinen uns so grundlegend, dass sie konsensfähig sind/sein könnten. Wir trauen uns also einfach mal, eine Reihe von Prinzipien, Regeln und Praktiken zusammenzustellen, von denen wir meinen, alle - ja, alle! - Softwareentwickler können und sollen sie beherzigen. (Naja, mit Ausnahme des einen oder anderen Prinzips, das doch eher mit der Objektorientierung zu tun hat. Dem mag dann ein C-Entwickler nicht folgen. Aber das ist unerheblich.)

Den, der diese Prinzipien, Regeln und Praktiken fleißig befolgt in seiner Arbeit, den nennen wir dann Clean Code Developer (CCD) als Hommagè an Roberts Buch.

Und was gehört zu unserem Kanon? www.clean-code-developer.de gibt Auskunft. Dort haben wir in den vergangenen Wochen unser Wertesystem, wie wir es nennen, zusammengetragen. Eine Übersicht zeigt diese Seite: http://www.clean-code-developer.de/wiki/CcdWertesystem. Detailseiten führen dann aus, was wir unter den einzelnen "Werten" verstehen.

Der Trick dabei: Wir haben unser Wertesystem in "Module" verpackt. Ganz nach Manier der Budo-Sportarten definieren wir Grade, die unterschiedliche Entwicklungsstufen bei der Einarbeitung in das Wertesystem beschreiben. Damit wollen wir keine besser-schlechter, schlauer-dummer Hierarchie aufstellen, sondern nur im Sinne iterativen Lernens "Meilensteine" setzen. Dass einer das ganze Wertesystem von jetzt auf gleich einfach beherzigen kann, glauben wir nicht. Also lieber Schritt für Schritt vorgehen. Ein Grad nach dem anderen. Ganz locker und unbürokratisch. Niemand muss dafür ein Fomular ausfüllen oder eine Prüfung machen. Wir appellieren an die Ehrlichkeit des Adepten. Zumindest sie sollte ja auch zur Professionalität gehören ;-)

Wer sich solcher Mühe unterzieht, soll natürlich auch stolz darauf sein. Deshalb haben wir uns - auch angeregt durch Robert C. Martin - überlegt, dass wir Armbänder tragen könnten. Sie sind in der Form Ausdruck des Willens zu mehr Professionalität und in der Farbe ein Hinweis auf den Grad, an dem ihr Träger arbeitet. Eine dezentes wie auch effektives Berufsabzeichen, wie wir finden. Aber: auch das ist kein Zwang, sondern nur Angebot. Wir fänden es allerdings toll, wenn wir bei den nächsten Entwicklerveranstaltungen eine wachsende Zahl von CCD-Armbandträgern träfen :-) (Für eine Kostenerstattung schicken wir Interessenten gern ein Armband zu; einfach hier den Bestellknopf drücken: http://www.clean-code-developer.de/wiki/CcdArmband)

Wie gesagt: Das CCD-Wertesystem ist nur ein Vorschlag. Wir hauen einfach mal einen Pflock in den Boden. Während Microsoft über zukünftige Technologien sinniert und die Ausbildungen in den vergangenen Technologien verharren, sammeln wir einfach mal, was wir für zeitlos und unverbrüchlich halten. Ganz technologieneutral und paradigmenfern. Wer meint, dass wir dabei etwas vergessen hätten oder zuviel des Guten täten, der kann das mit uns gern diskutieren. Dafür haben wir ein Clean Code Developer Forum aufgesetzt: http://groups.google.de/group/clean-code-developer.

Nach den Wochen der Ausarbeitung bin ich nun ganz gespannt, wie die Community unsere Idee aufnimmt. Gebt uns Feedback!

Aber noch besser: Fangt mal mit dem roten Grad an. Ist gar nicht schwer. Das kann eigentlich jeder .NET-Entwickler aus dem Stand. Vielleicht ist so ein Armband ja auch ein Mittel, um dem Chef mal zu vermitteln, dass zur Softwareentwicklung mehr gehört, als Kundenanforderungen irgendwie zu erfüllen?

PS: Wer nach Durchsicht des CCD-Wertesystems einen Vorschlag zur Verbesserung hat oder eine Frage oder einfach nur seine Meinung äußern möchte, der möge das am besten gleich im CCD-Diskussionsforum tun. Da ist mehr Raum, um wirklich darüber zu sprechen. Mit den Kommentaren hier ist das eher hinderlich und leistet am Ende einer Verletzung des DRY-Prinzips Vorschub ;-)

Twitter - Nur Versuch macht kluch [OOP 2009]

Früher war Brief. Dann war Telefon. Aber noch mein Vater hatte immer einen Blick darauf, dass niemand im Haushalt zu lange telefonierte. Dann Handy, SMS, Email - oder war die Reihenfolge anders? Schließlich Instant Messaging (IM), Blog, Wiki, XING. Alles habe ich bisher mitgemacht. Manches früher, manches später. Mit allem fühle ich mich wohl. Aber Twitter? Muss das sein?

Keine Ahnung. Aber es heißt ja, dass "die jungen Leute heute" inzwischen schon Email für "old fashioned" halten. Wenn ich also nicht frühvergreisen will... dann muss ich mich wohl mal mit Twitter beschäftigen. Eine Gelegenheit, bei der ich das Motto vom "lebenslangen Lernen" endlich mal gegen meine Neigung oder ein Verständnis für den unmittelbaren Nutzen leben kann.

Also Twitter: Ein Dienst, bei dem "man" mit kurzen Nachrichten (s)einen "Zustand" veröffentlichen kann. Andere können diese Zustandsmeldungen abonnieren, "man" kann die Zustände anderer abonnieren. Hm... Wo ist der Unterschied zu anderen Medien?

Twitter ist ein asynchrones Medium. Wer publiziert, erwartet keine Antwort, ja noch nicht einmal einen Leser. Insofern ist Twittern Monologisieren. Ohne konkreten Adressaten ähnelt Twitter einem Blog. Es ist eine Broadcasting-Plattform.

Die Kürze der Nachrichten jedoch macht es ähnlich SMS oder IM. "Romane" lassen sich mit Twitter nicht veröffentlichen - zumindest nicht in der traditionellen Form. (Allerdings: Ein Autor könnte eine Figur erschaffen, der er ein Twitter-Konto gibt. Der "Roman" ließe sich dann als Folge von Twitter-Updates spinnen, in denen die Figur ihre Erlebnisse protokolliert. Bram Stokers "Dracula" war seinerzeit hochmodern, weil die Figuren leading edge technology benutzten, um ihn zu spinnen: z.B. Schreibmaschine und Telegraph. Twitter & Co für heute zeitgemäße Literatur zu benutzen, wäre also angezeigt. Einige Alternate Reality Games versuchen sich daran ja auch schon.)

Kurze Statusnotifikationen in die Welt geworfen: Was kann das nützen? Ich denke, zwei Seiten sind zu unterscheiden: Twittern als Monolog und Twittern als Dialog.

• Als monologisierender Autor könnte der unmittelbare Nutzen darin liegen, dass Twitter mir unmittelbar hilft, meinen Tag zu strukturieren und zu protokollieren. Twitternachrichten als kontinuierlich fortgeschriebenes Tagebuch. Termine im Kalender sind Planung und Blick in die Zukunft. Ein Twitterprotokoll hingegen ist Retrospektive. Indem ich bei einer "Zustandsänderung" (z.B. Tätigkeit, Ort) ein Twitterupdate schreibe, halte ich einen Moment inne. Das gibt Reflektionen raum und trägt womöglich zur Entschleunigung bei.
• Sobald ich mich als Autor nicht mehr allein sehe, sondern als Knoten in einem Netzwerk, kommt weiterer Nutzen hinzu. Dann haben meine Twitterupdates nicht nur einen Effekt für mich. Wenn andere sie lesen, kann ich ihnen auch eine Botschaft mitgeben. Ich kann Aussagen machen (z.B. über Werkzeuge, die ich gerade benutze, oder Themen, die mich beschäftigen) oder Fragen stellen. Meine Aussagen mögen andere anregen, meine Fragen mögen mir Antworten bescheren. Einmal kann ich mich als Person oder gar Kompetenzträger darstellen, ein andermal als Hilfesuchender. Ganz zwanglos. Ohne Garantie auf "Erfolg". Aber eben auch mit quasi vernachlässigbarem Aufwand.

Twitter scheint mir damit ein Werkzeug zur Selbstorganisation wie auch zur Kommunikation. Mit Twitter können man sowohl nach innen wie nach außen gehen. Geradezu esoterisch mutet das an, denn der Strom meiner Twitternachrichten ist ja quasi ein "stream of consciousness", ein Gedankenstrom, und also ist Twitter ein Gedankenlesewerkzeug. Besser als bei der herkömmlichen Telepathie behalte ich die Veröffentlichungshoheit über meine Gedanken. Sie werden mir nicht "herausgelesen", sondern ich gebe sie freiweillig preis.

Es stellt sich also die Frage: Was kann sich alles entwickeln, wenn wir unsere Gedanken lesen können?

Wie Briefe und Telefon war Big Brother auch früher. Früher hatten viele Menschen Angst, sie würden ausgespäht. Heute hingegen muss sich niemand mehr die Mühe machen. Die Informationen über die Menschen liegen auf der Straße, weil sie sie selbst dorthin werfen. Twitter ist ein weiteres Medium dafür.

Aber ist das schlimm? Nein, ich finde, nicht. Im Gegenteil! Wer sich vor Big Brother fürchtet, macht zu. Wer sich zu macht, reduziert seine Kontaktoberfläche, seine Verbindungen. Wenn eines aber wichtig heutzutage ist, um in einer komplexen Welt fortzuschreiten, dann sind es mehr Verbindungen, einfachere Verbindungen. Dafür müssen wir aber offen sein, kontaktfreudig. Und das beginnt mit Angeboten, die wir machen. Bei der persönlichen Begegnung ist ein Lächeln ein Angebot. In der virtuellen Welt können es "Broadcasts" sein wie Blogs oder eben Gedankenströme in Twitter. (Dass dann solche Gedankenströme nicht einmal von einem Menschen, sondern von einer Software stammen können, ist womöglich zu vernachlässigen. Am Ende geht es um "Entitäten", um Informationsquellen, die für mich wertvoll und vertrauenswürdig sind. Das können auch Twitter-Bots sein, die die "Gedanken" eines Unternehmens "senden".)

Soweit ein paar Überlegungen zu Twitter. Ob und inwiefern sie mit der Realität zu tun haben, weiß ich allerdings noch nicht. Ich muss sie versuchen zu verifizieren. Am besten im Selbstversuch. Denn nur Versuch mach kluch. Also öffne ich mal meinen Kopf und eröffne einen Blick auf meine "Zustände". Zum Glück ist das mit Twitter weniger schmerzhaft als bei früheren Trepanationen ;-)

Wer mit auf meinen Gedankenströmen schwimmen will, kann sich als "Follower" bei mir in Twitter anmelden. Mein Twitter-Konto ist: http://www.twitter.com/ralfw.

Softwarearchitektur kompakt - prio.conference 2008

Als wie relevant das Thema Softwarearchitektur inzwischen in der Community wahrgenommen wird, hat die prio.conference der dotnetpro am 10./11. November gezeigt: mehr als 260 Teilnehmer hatten den Weg nach Baden-Baden ins Kurhaus gefunden. Das ist eine Zahl, die mich als Content Manager der prio sehr gefreut hat - und ich hoffe, dass nicht nur das Oberthema im Großen, sondern auch meine Auswahl von Vortragsthemen und -referenten im Kleinen dazu einen Beitrag geleistet hat.

Erstes Feedback stimmt mich da aber positiv. So ist zum Beispiel die Keynote des (wahrscheinlich) einzigen wirklichen Architekten vor Ort sehr gut angekommen. Prof. Dr. Christian Kühn aus Wien hat einen interessanten Bogen von seinem Metier der Bauarchitektur zur Softwareentwicklung geschlagen. Denn wenn sich schon die Pattern-Bewegung der Softwareentwicklung auf bauarchitektonische Patterns bezieht, ist es angezeigt einmal zu beleuchten, welche Relevanz die denn eigentlich haben. Und so haben die Anwesenden nicht nur erfahren, wie die Patterns schon vor Erich Gamma et al. ihren Weg in die Softwarebranche gefunden hatten, sondern auch, wie Prinz Charles mit Patterns verbunden ist.

Nach solchem Blick über den Tellerrand ging es dann aber mit "echten" Softwareinhalten los. In 30 Sessions haben die Referenten den Bogen vom Konzeptionellen wie der Definition von Architekturrollen und Dokumentation über eher unbekannte Technologien wie Microsofts CCR oder PostSharp bis zu handfesten Tipps zum Transport von veränderlichen Objekten per WCF gespannt.

Besonders haben mich die Kommentare zum Thema Jabber gefreut. Die Teilnehmer waren hocherfreut zu erfahren, dass es solch coole Kommunikationstechnologie gibt - und gleichzeitig erstaunt, dass sie bisher davon noch nichts gehört hatten. Denn Jabber kann vieles schon lange, was Microsoft erst heute mit seinem Communication Server anfängt zu realisieren. Und dabei ist Jabber bzw. seine Server und Clients vielfach kostenlos und reifer.

Ebenfalls über den Horizont der vielfach Microsoft-lastigen Welt der .NET-Community hinaus hat Referent Markus Völter mit seinen Vorträgen zum Thema Domänenspezifische Sprachen (DSL) geblickt. Er hat vorgeführt, wie auf der Basis der oAW Plattform mit Eclipse (!) schon heute eigene textuelle Sprachen inkl. Codegeneratoren realisiert werden können. Wer also nicht auf Microsofts Oslo warten will, der kann jetzt loslegen.

Die prio hat somit nicht nur viele Facetten des Themas Softwarearchitektur beleuchtet, sondern bewusst weiter geblickt als die üblichen Microsoft-lastigen Events. Softwarearchitektur hat zwar immer mit Entwicklungsplattform zu tun, sollte sich von ihr aber nicht unnötig beschränken lassen. Relevante und interessante Entwicklungen gibt es jenseits von Linq, Entity Framework, WPF, Silverlight oder dem sich schon zur Welle hebenden OsloAzureWindows7.

Aber nicht nur das Fachliche hat Spaß gemacht. Der Abend stand wieder ganz im Zeichen der Heimat der dotnetpro: alle Teilnehmer trafen sich im Löwenbräu zu einem nah ans Oktoberfest-Original heranreichenden bayrischen Abend. Der war ausnehmend gemütlich - auch wenn er Sprecher und Veranstalter sich nicht nur entspannen konnten. Wie schon im Vorjahr galt das Motto der englischen Offiziersakademie Sandhurst: serve to lead - dienen, um zu führen. Und so bedienten Sprecher und Chefredakteur die Teilnehmer vor und hinter dem Thresen.

Das hat Laune gemacht und wieder ganz neue Einblicke in die Community gegeben :-)

Im nächsten Jahr wird die prio solche Gemütlichkeit jedoch nicht mehr "exportieren" müssen. 2009 findet die prio.conference in der dotnetpro Heimatstadt München statt. Das Thema steht auch schon fest. Es wird um "User Interfaces" gehen. Und es wird natürlich wieder technisch und praktisch und konzeptionell werden. Von Usability bis DataBinding Best Practices gibt es viel zum Thema zu sagen. Immerhin sind User Interfaces das Aushängeschild unserer Anwendungen.

Aber zur Softwarearchitektur wird die dotnetpro bis dahin sicher auch nicht stumm bleiben. Stay tuned!

Interrupt? Nein, danke! [OOP 2009]

Es ist schon erstaunlich, wie unterschiedlich Menschen sein können:

Situation 1: Auf der Straße unterhalte ich mich mit einer Nachbarin. Die hat ihren 5-jährigen Sohn dabei. Nach 2-3 Minuten Plauderei ruft der plötzlich "Mama, Mama, ich würde gern...". Die Mutter daraufhin sofort: "Nicht jetzt! Ich unterhalte mich gerade. Gleich bin ich aber für dich wieder da."

Situation 2: Im Café sitzen neben mir zwei Frauen ins Gespräch vertieft. Da klingelt plötzlich das Handy der einen. Sie zögert nicht, nimmt ab und plaudert mit dem Anrufer mehrere Minuten. Die andere blättert derweil klaglos zur Überbrückung in einer Zeitschrift.

Situation 3: Während eines Beratungsauftrags sitze ich mit einem Entwickler über einem Architekturproblem in seinem Büro. Plötzlich geht die Tür auf und der Projektleiter fordert ihn auf, sofort einem Kollegen bei der Lösung einer Aufgabe zu helfen.

Hm... was haben diese Situationen gemeinsam? Da sind Menschen in etwas vertieft und es tritt eine plötzliche Störung durch einen Dritten ein.

Und was unterscheidet diese Situationen voneinander? Nur in einem Fall entscheiden sich die ins Gespräch vertieften zu einer Abwehr der Störung. Nur das Kind wird als Störenfried in seine Schranken verwiesen. Die Mutter macht ihm klar, dass es nicht jederzeit Zugriff auf sie hat, sondern darauf achten muss, ob Mutter gerade offen für eine Ansprache ist. Sieht es hingegen, dass Mutter anderweitig beschäftigt ist, soll es sich gedulden.

Daran ist grundsätzlich nichts auszusehen, würde ich sagen. Es ist höflich, nicht zu unterbrechen. Das sollte ein Kind lernen.

Wie ist solche Lehre aber zu vereinbaren mit dem Verhalten der beiden Frauen im Café? Sie lassen sich ganz einfach durch einen Anruf unterbrechen. Sie nehmen das nicht nur in Kauf, sondern provozieren es geradezu, indem sie ihre Handys angeschaltet lassen. Dass sie Ärztinnen oder Bestatterinnen sind, die jederzeit auf Abruf zu erreichen sein müssen, war allerdings nicht zu erkennen.

Warum lassen sich erwachsene Frauen die Unterbrechung von einem Kind nicht gefallen, aber von jedem anderen, der noch nicht einmal anwesend ist? Hm... darüber kann man einen Moment nachdenken. Doch über die wahren Beweggründe für diese Unterbrechungstoleranz will ich hier gar nicht reden. Mir fiel angelegentlich dieser Situation nur die Diskrepanz zwischen Anspruch und Wirklichkeit auf.

Denn der allgemeine Anspruch ist ja, dass man nicht gestört werde, wenn man in etwas vertieft ist. So lautet die pädagogische Reaktion der Mutter. Auf der anderen Seite tolerieren oder provozieren wir jedoch die Unterbrechung. Im privaten Umfeld mag das auch unproblematisch sein. Im geschäftlichen jedoch wird das schnell teuer.

Wissensarbeit wie in Situation braucht nämlich eines: Konzentration. Um gute Wissensarbeit - und nichts anderes ist Softwareentwicklung - leisten zu können, müssen sie sich fokussieren können. Sie brauchen Störungsfreiheit. Entwickler durch "Chefanfragen" immer wieder in ihrer Arbeit zu unterbrechen, ist daher kontraproduktiv. Sie müssen ihren Fokus verlassen und später wieder aufbauen. 15min "Umschaltzeit" sind dabei durchaus keine Seltenheit.

Im Grunde wissen das auch alle vom Wissensarbeiter bis zum Top-Manager. Multitasking funktioniert nur sehr begrenzt. Dennoch verhalten sie sich aber alle anders.

Obige Situation 2 hat mir nun klar gemacht, woran das liegt. Das Unterbrechungsproblem in der Arbeitswelt kann nicht besser werden, solange wir es nicht konsequent umfassend angehen. Wer sich im privaten Bereich gern unterbrechen lässt, das Handy immer auf Empfang hat und verständnisvoll-verzeihend nickt, wenn andere angerufen werden, der darf sich nicht wundern, wenn am Arbeitsplatz auch immer wieder unterbrochen wird.

Die Gründe für solche Ambivalenz mögen verständlich sein. An den weitreichenden Auswirkungen der Ambivalenz ändert das jedoch nichts. Wer sich einem Kind gegenüber die Unterbrechung verbittet, sie aber im Freundeskreis toleriert oder gar erwartet, darf sich nicht wundern, wenn er dann am Arbeitsplatz keine "produktive Unterbrechungskultur" etablieren kann.

Ich möchte nicht ohne Handy, SMS, Email, IM usw. leben. Aber wichtiger als diese Medien ist mir immer noch mein Fokus. Und so habe ich kein Verständnis mehr für Unterbrechungswilligkeit. Ich schalte (spätestens ab heute) meine "Unterbrechungsmedien" ab, wenn ich im Gespräch bin. Und ich werde sonstige Unterbrecher höflich, aber bestimmt auf die Kontraproduktivität ihrer Unterbrechung hinweisen. Kinder und Manager machen da für mich keinen Unterschied. Das halte ich vielmehr für eine Grundlage höflichen und respektvollen Umgangs miteinander.

NETZ it! - Komponentenorientierte Software ausliefern leicht gemacht

"Soooviele Assemblies???" ist der ungläubige Ausruf, den ich oft höre, wenn ich ich über Komponentenorientierung spreche. Denn damit komponentenorientierte Entwicklung wirklich ihre Vorteile ausspielen kann, ist es nötig, Software nicht nur logisch in Komponenten zu zerlegen, sondern die auch noch physisch getrennt zu implementieren. Das bedeutet, jeder Komponentenkontrakt und jede Komponentenimplementation wird zu einer eigenen Assembly. Die Zahl der Assemblies einer Anwendung ist also immer mindestens doppelt so groß wie die ihrer Komponenten.

Das hört sich viel an. Oder zumindest ungewohnt. Schon bei 3 Komponenten kommen 5 oder 6 Assemblies zusammen, wie die nebenstehenden Beispielanwendung zeigt. Und größere Anwendungen bestehen schonmal aus 50 oder 100 Komponenten und damit 100 oder 200 Assemblies.

Einen "materiellen" Nachteil hat das jedoch nicht. Der .NET Framework kommt damit ganz gut zurecht. Nur Visual Studio nicht. Es macht keine Freude, in einer Visual Studio Projektmappe mehr als vielleicht 10 Projekte zu verwalten. Aber das soll man ja auch nicht.  (Insofern entspricht die Abbildung links nicht dem Ideal; ich habe die Projekte nur für eine einfachere Darstellung so zusammengefasst.)

Echte Komponentenorientierung bedeutet vielmehr, dass alle Komponenten in je eigenen Projektmappen entwickelt werden. Wenn Sie an einer Komponente arbeiten sollen Sie nicht abgelenkt werden durch Implementationsdetails anderer Komponenten, die in derselben Projektmappe liegen.

Doch auch wenn es keinen "materiellen" Nachteil hunderter Assemblies für eine Anwendung gibt, verstehe ich, dass sie dazu angetan ist, den Überblick zu verlieren. Vor allem wollen Sie womöglich dem Kunden gegenüber solche Detailfülle nicht offenlegen. Die Abbildung rechts zeigt, wie ich die Beispielanwendung eigentlich ausliefern müsste: als "Sack von Assemblies". Das ist zwar einfach, aber mag sich eben zumindest merkwürdig anfühlen.

Krücke ILmerge

Nun habe ich aber noch nie behauptet, dass die Zahl der Assemblies zur Entwicklungszeit der zur Zeit der Auslieferung gleich sein müsse. Immer schon habe ich auf die Möglichkeit hingewiesen, sie mit Microsofts ILmerge zusammenzufassen. Aus den 7 zur Anwendung gehörenden Assemblies (inkl. DI Framework Infrastruktur) rechts im Bild könnte mit ILmerge ganz leicht eine werden.

Sie anders zusammenfassen, wäre allerdings nicht unproblematisch. Zum Beispiel könnten Sie nicht nur alle Kontrakt-Assemblies vereinigen, weil Sie damit die Referenzen darauf in den Komponentenimplementationen invalieren würden. Die beziehen sich ja auch konkrete Assemblynamen, die es dann nicht mehr gäbe.

ILmerge funktioniert zwar grundsätzlich. Ist aber letztlich nur eine Krücke, weil es nicht genügend Freiheitsgrade bietet. Außerdem mag es nicht jedem schmecken, dass ILmerge den IL-Code "anfasst". Zugegebenermaßen ein Vorgang, bei dem mehr falsch laufen könnte, als wenn man Assemblies, so wie sie sind, irgendwohin kopiert.

NETZ to the rescue

Aber diese Zeit der Krückenlösung ist nun vorbei! Durch einen News-Schnippsel in einer Entwicklerzeitschrift bin ich auf das Open Source Tool NETZ gestoßen. Das ist echt cool für die komponentenorientierte Entwicklung! Und es ist auch noch eines aus deutschen Landen - ein seltener Umstand bei Softwareentwicklungstools.

Was bietet NETZ? Zusammenfassung und Kompression von Assemblies. Mit NETZ können Sie Assemblies wie mit ILmerge zusammenfassen, allerdings ohne Eingriff in den IL-Code. NETZ verpackt die Assemblies einfach nur als Ressourcen in eine von ihm generierte.

Für die Komponentenorientierung unwichtig, aber für Sie dennoch vielleicht interessant, komprimiert NETZ die Assemblies während der Zusammenfassung auch noch. So kann der in den Ressourcen steckende IL-Code nicht mehr so einfach decompiliert werden. Ohne Obfuscation erhalten Sie also einen ersten Schutz gegen beiläufige Ausspähung von Implementationsdetails.

Die obige Beispielanwendung in eine Assembly zusammenzufassen, ist mit NETZ ganz einfach. Eine Kommandozeile wie diese reicht (sie ist nur der Lesbarkeit wegen hier in mehrere Zeilen geteilt):

netz -z -s
  frontend.exe
  -d logic.dll dataaccess.dll
       contracts.logic.dll contracts.dataaccess.dll
       Microsoft.Practices.Unity.dll Microsoft.Practices.ObjectBuilder2.dll

Mit ihr verpackt NETZ alle Assemblies in eine neue Assembly (-s), die auch eine DLL zur Dekompression enthält (-z). Alle Assemblies können auch dynamisch geladen werden (-d) - das ist für die Nutzung eines DI Frameworks nützlich sein mag. Das Resultat: eine Assembly mit Namen frontend.exe und einer Struktur wie in der nachstehenden Abbildung. Der Start-Code wurde komplett durch NETZ generiert (Methoden auf der linken Seite), die Anwendungsassemblies sind zu Ressourcen geworden (rechts). Der NETZ-Code sorft dafür, dass beim Laden einer Assembly, die die CLR nicht selbst findet, die Ressourcen herangezogen werden.

Schon bis hierhin bietet NETZ also mehr als ILmerge. Nicht nur Zusammenfassung von Assemblies, sondern gleichzeitig Kompression - und das ohne Eingriff in den Assembly-IL-Code.

NETZ kann aber noch mehr! NETZ kann die Assemblies auch in externe Ressourcen verpacken. So können Sie sie beliebig gruppieren. Auf die Referenzen hat das keinen Einfluss. Bilden Sie also beliebige Gruppen von Assemblies. Die Beispielanwendung habe ich z.B. einmal so zusammengefasst wie rechts zu sehen. In frontend.exe steckt die ursprüngliche EXE mit den Microsoft Unity DI Infrastruktur-Assemblies. Die contracts-Ressourcen enthalten die Kontrakt-Assemblies, die components-Ressource die Implementationen. Ganz einfach ist damit einem Batch wie diesem:

netz -z -s frontend.exe Microsoft.Practices.Unity.dll Microsoft.Practices.ObjectBuilder2.dll
netz -xr contracts contracts.logic.dll contracts.dataaccess.dll
netz -xr components dataaccess.dll logic.dll

move *-netz.resources frontend.exe.netz

Der -xr Switch weist NETZ an, die Assemblies nicht zu einer EXE, sondern zu einer externen Ressource zusammenzufassen. Der NETZ-Start-Code sucht in solchen Ressourcendateien im selben Verzeichnis sogar zuerst nach Assemblies.

Lassen Sie sich durch 50 oder 100 Assemblies nicht in Bockshorn jagen. Fassen Sie sie für´s Deployment mit NETZ einfach so zusammen, wie Sie es möchten: alle zu einer großen Assembly oder Kontrakte und Implementationen getrennt oder Kontrakte zusammen mit ihren Implementationen oder alle Assemblies einer Kategorie (z.B. alle Domänenlogik-Assemblies getrennt von allen Aspekt-Assemblies). Mit NETZ ist das alles sehr einfach möglich. Und kostenlos dazu! Mein herzlicher Dank gilt Vasian Cepa, dem Entwickler! (Der ist übrigens sehr bemüht; innerhalb eines Tages hatte er eine Verbesserung eingebaut, auf die ich ihn angesprochen hatte.)

Ich arbeite jetzt nicht mehr ohne NETZ in meinen komponentenorientierten Projekten.

Qualität hat keinen Preis mehr - so scheint es

Zwei symptomatische Geschichte:

Es ruft ein Kompetenzträger bei einem Konferenzveranstalter an und fragt, ob der für die nächste Konferenz an Vorträgen zu einem Thema interessiert wäre. Der Veranstalter freut sich nach Rücksprache mit dem Content Management mitteilen zu können, dass die angetragenen Vorträge gut ins Programm passen würden. Eine Kleinigkeit sie vorher allerdings noch zu klären: der Umfang des Sponsorenpaketes, das der Kompetenzträger buchen möchte.

Ein andermal ruft die Redaktion eines unserer Fachmagazine zur Einreichung von Artikelvorschlägen auf. Auf Nachfrage, wie hoch denn das zu erwartende Autorenhonorar sei, antwortet man, dass ab der dritten Heftseite eines Artikels 40 EUR/Seite gezahlt würden. Für die Seiten 1 bis 3 sei den Autoren jedoch ein sehr warmer, in nicht näher spezifizierten Naturalien ausgedrückter Dank des Verlages gewiss.

Zwei Geschichten, eine Reaktion: Traditionelle Inhaltsplattformen wollen kein Geld mehr für ihre Inhalte ausgeben. Sie wollen das, was ihren Wert ausmacht, weder produzieren noch die Produktion bezahlen.

Sind im Web oft für die Konsumenten kostenlos, so kehrt sich dies scheinbar gerade bei den für die Branche relevanten traditionellen Medien Zeitschrift und Konferenz um. Da bezahlen die Konsumenten und die ureigentlichen Produzenten gehen leer aus oder sollen gar noch Geld mitbringen.

Eine merkwürdige Welt ist das.

Mit dem, was ich einmal auf der Schule gelernt habe, hat das nicht viel zu tun. Da galt nämlich, dass Angebot und Nachfrage den Preis regeln. Ist das Angebot groß und die Nachfrage klein, dann ist der Preis für das Angebot niedrig. Kommt dann die Nachfrage dem Angebot näher, zieht der Preis an. Maximal wird der dann bei einem Monopol.

Daran hat auch das Web nichts geändert, würde ich mal sagen. Wenn die Artikel bei Codeproject für Leser kostenlos sind, dann liegt das daran, dass das Angebot an Content im Web so riesig ist. Die Nachfrage pro Contentanbieter ist deshalb klein und der Preis niedrig bis nicht existent. Wenn Codeproject dennoch überleben kann, dann liegt es an Werbeeinnahmen und good will der Contentproduzenten. Die verschenken ihr Wissen für... ja, für was eigentlich? Für das gute Gefühl, der Community etwas zurückgegeben zu haben:

"Everything on the site may be freely used. All we ask in return is that you contribute something back to the community." (CodeProject FAQ)

Ob das genug Lohn der Mühe ist, muss jeder für sich entscheiden. Dass die Qualität solcher Gratisinhalte oft zu wünschen übrig lässt, ist hingegen wenig zweifelhaft.

Aber einerlei. In den zwei obigen Geschichten geht es nicht um Codeproject. Es geht auch nicht ums Web. Es geht vielmehr um traditionelle Medien, die mittlerweile schon traditionell nicht aus dem Klagen herauskommen, die Nachfrage bei ihnen sei so schmerzvoll gering.

Was tun sie aber in der Lage: sie senken weder den Preis, noch erhöhen sie die Qualität. Sie drehen vielmehr an der Kostenschraube. Sie geben den Druck, der auf ihnen lastet, an die weiter, die eigentlich erst ihre Existenz berechtigen. Denn ohne Inhalte kein Medium zu ihrer Verbreitung.

Es gibt natürlich kein Recht auf Honorar für Kompetenzträger. Und so finde ich es ganz legitim, wenn Medien wie das MSDN Magazine kein Honorar zahlen. Auch sie leben nach den Gesetzen des Marktes: Das Angebot ist beschränkt, die Nachfrage ist hoch, also ist auch der Preis hoch. In diesem Fall meine ich allerdings das Angebot an Platz für den Inhalt und die Nachfrage von Autorenseite. Pro Ausgabe erscheinen nur ca. 15 Artikel von denen einige schon fest an Kolumnenautoren vergeben sind. Für die verbleibenden gibt es eine lange Schlange an willigen Autoren - also erlaubt sich das MSDN Magazine, kein Honorar zu zahlen. Dort zu veröffentlichen hat für die Autoren soviel Wert (Ruhm oder Sichtbarkeit + Aufträge), dass sie diese Politik akzeptieren.

Wieder zurück zu lokalem Konferenzveranstalter und Zeitschriftenverlag. Die haben nun dieselbe Politik wie das MSDN Magazine installiert - aber bieten bei weitem nicht denselben Nutzen für die Inhaltsproduzenten. Die Konferenzen des Veranstalters sind klein, die Auflage der Zeitschrift auch. Das beklagen beide.

Es erscheint mir daher widersinnig, eine solche Politik im Umgang mit den Wertproduzenten zu installieren. Was verspricht man sich davon? Beide handeln gegen das simpelste Gesetz des Marktes: Keine Nachfrage bei dem Abnehmern, aber der Preis bleibt konstant und der Wert wird nicht erhöht. Keine Nachfrage bei den Inhaltslieferanten, aber der Preis für die Lieferung wird erhöht, indem das Honorar gesenkt wird.

Denn so sieht es leider aus: die Inhalte der Konferenzen und der Zeitschrift sind nicht herausragend. Kompetenzträger, die fachlich gut und stilistisch angenehm vortragen oder schreiben, sind einfach Mangelware. Wer dann nichts dafür, sondern alles dagegen tut, die eigene Inhaltsplattform attraktiv für solche ohnehin raren Inhaltslieferanten zu machen, der darf sich nicht wundern, wenn die Qualität sinkt. Einige sehr gute und auch beliebte Inhaltslieferanten sind denn auch schon nicht mehr zu sehen oder zu lesen; sie haben besseres zu tun, als auch noch Geld für die Wissensweitergabe auszugeben.

Was ist unzweifelhaft der Effekt, wenn Kompetenzpräsentationen nicht nur nichts einbringen, sondern sogar kosten sollen? Sie geraten zu Verkaufsveranstaltungen. Es präsentieren die sich, die es nötig haben, weil sie nicht nur die Investition der Präsentation wieder hereinbekommen müssen, sondern auch noch darüber hinaus mit ihr Profit durch nachfolgende Aufträge generieren müssen.

Oder es sind die zu sehen, die sich zeigen müssen, weil ein System es so will ("publish or perish") bzw. der Chef.

Alles in allem ist - wie überall, wo Werbung ins Spiel kommt - aber nicht damit zu rechnen, dass durch solche Politik die Qualität im Allgemeinen und Ehrlichkeit/Authentizität im Besonderen steigen. Nach beidem fragen aber Teilnehmer wie Leser. Im Dschungel heutiger Technologien brauchen sie nichts dringender als vertrauenswürdige Quellen. Präsentatoren in Wort oder Schrift, die für die Präsentationsmöglichkeit zahlen mussten, sind das allerdings eher nicht.

Ergo: Die Nachfrage nach diesen Inhaltsplattformen kann nur abnehmen. Die schon jetzt beklagte negative Tendenz verschärft sich. Die, die gut aufbereitete Informationen dringender denn je nötig haben, wandern weiter ab ins Web, um dort viel Mühe für die Filterung von Inhalten aufzuwenden.

Schade. Denn die Plattformen haben einen Namen. Nun verspielen sie ihn.

Früher war platte Werbung. Da konnten wir Inhalt und Beschönigung auseinander halten. Dann kam das Advertorial. Sofern gekennzeichnet, konnten wir immer noch Inhalt und Beschönigung trennen, doch es war schwieriger geworden. Nun kommt ungekennzeichneter bezahlter Content. Den können wir nicht mehr von Content unterscheiden, der nicht primär verkaufsinteressengeleitet ist. Statt für unser Geld vertrauenswürdieg Informationen zu bekommen, sehen und lesen wir im Zweifelsfall vor allem eines: Werbung.

Eine verhängnisvolle Entwicklung, die letztlich allen Inhaltsanbietern Schaden zufügt. Wer sich da beklagt, dass es mit der Nachfrage nicht stimmt und auf das Web zeigt, der hat leider weder die Befindlichkeit der Branche noch die Gesetze des Marktes begriffen.

Dabei wäre es doch so einfach, die Nachfrageentwicklung umzukehren. Die Zauberworte lauten - wie immer - Innovation und Investition. Wer das nicht glaubt oder sich inspirieren lassen möchte, der lese "Alles, außer gewöhnlich". Dessen Autoren haben sicherlich auch ein Honorar für ihre Arbeit bekommen.

PS: Es geht mir übrigens bei dieser Betrachtung nicht darum, ob mir oder jemand anderem die Geschichten widerfahren sind. Ich stelle nur eine bedenkliche Tendenz fest. Nicht nur für jeden, der daran denkt, doch mal sein Wissen weiterzugeben, sondern für alle, die vertrauenswürdiges Wissen suchen.

Warum Lego nichts mit Softwareentwicklung zu tun hat [OOP 2009]

Laien Softwareentwicklung verständlich zu machen, ist nicht leicht. Helfen sollen dann Analogien. Beliebt ist die, Software mit einem Küchenrezept zu vergleichen. Doch nicht nur Laien haben ihre Schwierigkeit mit der Softwareentwicklung. Auch die Profis ringen immer wieder um Verständnis. So suchen auch die Profis nach Analogien. Beliebt ist bei ihnen die, Softwareentwicklung als Arbeit mit einem Lego-Bausatz zu sehen. Oder sie wünschen sich zumindest, dass es so wäre. Denn das Zusammensetzen von Lego-Bausteinen hat soviel mit Softwareentwicklung  zu tun wie Bambi mit einem Reh. Daran ändern auch wortreiche Beschwörungen wie die von James Noble auf InfoQ nichts.

Seine "Lego Hypothese" ist wieder einmal hübsch anzuhören - doch sie weist auch wieder in die falsche Richtung. Ich glaube, solange wir noch das Ziel haben, Softwareentwicklung wie ein Lego-Spiel werden zu lassen, solange stehen wir uns selbst im Weg zu einer einfacheren Softwareentwicklung. Genauso wie uns RPC à la .NET Remoting im Weg steht bei der Entwicklung paralleler und skalierbarer Software.

Was ist nun das Problem mit der Lego-Metapher?

Vom Offensichtlichen sehen wir einmal ab; Lego-Bausteine bieten keine Dienstleistungen, wie es Funktionseinheiten jeder Größenordnung - von der Methode bis zum SOA-Service - in einer Software tun. Lego-Bausteine sind also trivial.

Das Problem hat nicht mit der "Qualität" oder dem "Inhalt" von Lego-Bausteinen zu tun, sondern mit der "Lego-Form".

Problem 1: Feine Granularität

Da ist zum einen die uniforme Größe der Lego-Bausteine. Sie variiert zwar in gewissen Grenzen, aber in Bezug auf das, was aus ihnen am Ende gebaut wird, sind sie im Grunde alle gleich groß. Oder eben gleich klein. Lego bietet nur eine Granularität für den Bau. Ob es ein kleines Auto oder der Nachbau einer Kathedrale ist, alles wird aus kleinsten Teilen zusammengesetzt. "Container", um größere Teile unabhängig von einander zu bauen und später zusammenzusetzen, gibt es nicht. Lego kennt keine Abstraktionen.

Das ist keine Kritik an Lego. Der Erfolg von Lego ist von Abstraktionsmitteln unabhängig und ganz unbestritten. Lego soll nichts an seiner Ideen und seinen Produkten ändern. Nur sollten wir angesichts dieser Simplizität oder gar Trivialität des "System Lego" aufhören, darin einen Wegweiser für die Softwareentwicklung zu sehen. Lego kann uns viel lehren, zum Beispiel die Eleganz der Einfachheit oder den Nutzen von Standards. Aber in Lego steckt keine Botschaft zur Strukturierung komplexer, ständig in Veränderung begriffener Systeme. Die können wir nämlich nur planen, wenn wir sie auf unterschiedlichen Abstraktionsebene denken können, und bauen, wenn wir Bausteine ganz unterschiedlicher Granularität haben.

Lego-Bausteine sehen so aus, wie sie aussehen, eben weil sie keine vielfältigen Dienstleistungen bieten, sondern immer wieder nur Festigkeit in konstanter Form. Das war´s. Software jedoch ist anders, ganz anders. Und so ist es eine Illusion anzunehmen, vielfältige Softwaredienstleistungen ließen sich zusammenstecken wie triviale Lego-Bausteine.

Problem 2: Direkte Verbindungen

Lego-Bausteine sind "tot". Software hingegen "lebt". Nicht nur sind Software-"Bausteine" ständig in Aktion, Software insgesamt ist auch beständig im Wandel. Das bedeutet:

• Die Zahl der "Bausteine" in einem System ändert sich ständig.
• Die Zahl der Beziehungen zwischen den "Bausteinen" in einer Software ändert sich ständig.

Software als System von Funktionseinheiten mit vielfältigen Beziehungen ist kontinuierlich im Wandel begriffen. Sie unterliegt dauernder Umkonfiguration im Kleinen und im Großen. Das liegt in der Natur ihres Zwecks, der Lösung komplexer Aufgabenstellungen. Und das ist natürlich auch der schlichten Möglichkeit geschuldet, Immaterielles wie Software so flexibel "kneten" zu können.

Lego-Bausteine hingegen werden im Zuge einer "Baumaßnahme" einmal aufeinander gesetzt und bleiben dann so. Weder verändern sich die Bausteine, noch verändert sich die Statik des großen Ganzen.

Deshalb ist es ausreichend, dass Lego-Bausteine direkt miteinander verbunden werden. Wir stecken sie unmittelbar aufeinander. Für die mit ihnen zu bauenden "Systeme" ist das genug.

Komplexeres jedoch, das wird seit jeher anders zusammengesetzt. Wo echte Dienstleistungseinheiten - im Gegensatz zu Stabilitätseinheiten - größeres bilden sollen, da sind die nicht direkt verbunden wie Lego-Bausteine. Echte Dienstleistungen stehen immer indirekt in Beziehung. Zwischen ihnen ist immer ein "Beziehungsvermittler", etwas Drittes, das sie zusammenbringt und -hält.

Stecker und Buchse, Schrauben, Nägel, Bolzen, Klemmen... es gibt viele Arten, Zusammenhalt herzustellen. Manchmal sind sie ganz einfach wie ein Holzzapfen, manchmal komplex wie ein Router. Aber immer ist ihre vornehmste Aufgabe zu verbinden. Nicht mehr, nicht weniger.

Ganz grundsätzlich unterscheiden wir in komplexen Systemen also zwischen den eigentlichen (Teil)Dienstleistungen und ihren Verbindungen. Wir koppeln Funktionseinheiten explizit und damit indirekt. Lego hingegen koppelt implizit und direkt.

Diese direkten Verbindungen zwischen Lego-Bausteinen sind für mich das k.o. der Lego-Analogie. Wannimmer wir sie beschwören, suggerieren wir mehr oder weniger subtil, dass direkte, implizite Verbindungen zwischen Funktionseinheiten genügen würden, um komplexe Softwaresysteme zu bauen. Das ist weitreichend kontraproduktiv. Solche Suggestionen vergiften das Nachdenken über Software und erzeugen früher oder besser Schmerzen. Denn wo direkt und implizit verbunden wird, da ist das Resultat starr. Und das bedeutet, Veränderungen sind schwierig; sie erzeugen Schmerzen, weil sie immer wieder die inhärente Starrheit überwinden müssen.

Eine bessere Analogie

Wenn Bauteile, Baugruppen, Module, Subsysteme von komplexen Systemen immer indirekt verbunden sind, um sie effizient fertigen, separat prüfen und flexibel zusammenbauen zu können, dann sollten wir unsere Analogien danach wählen, wenn wir welche brauchen. Statt uns immer wieder nach einer Lego-Softwarewelt zu sehnen, sollten wir eher nach Stabilbaukästen oder Elektronikbaukästen schielen.

Wenn schon eine spielerische Analogie, wenn schon Bausatz, dann so. Sie führen vor, wie aus kleinen Teilen größere werden durch indirekte Verbindungen.

Software ICs sind eine tauglichere Zielvorstellung als Software Lego-Bausteine.

Natürlich sollten wir dann auch danach in der Softwareentwicklung handeln. Die passend gewählte Analogie sollte uns etwas sagen; sie sollte rückwirken auf uns. Wir sollten definieren, was für uns explizite und indirekte Verbindungen sind. Denn Verbindungen haben wir viele und in vielerlei Ausprägungen:

• synchron/asynchron
• lokal/verteilt
• single-/cross-platform

Nicht, dass es dazu noch keine Ideen gäbe. DI, WCF, REST, ESB sind einige Akronyme in diesem Zusammenhang.

Doch ich glaube, dass uns noch ein echter Konsenz darüber fehlt, wann wir wie Software-Bausteine zusammenfügen. Ganz davon zu schweigen, was denn die Software-Bausteine sind, die dann so verbunden werden. Reichen Objekte und SOA-Services? Nein, ich denke, sie sind nur der Anfang.

Objektorientierung allein bewegt sich tatsächlich auf der Lego-Ebene. SOA-Services hingegen sind sehr große Bausteine, die vor allem asynchron, verteilt und cross-platform verbunden sind. Dazwischen liegt aber  noch ein weites Feld, dessen sich zumindest der Hype nicht bewusst ist. Das müssen wir beackern. Nur dann kommen wir raus aus dem Hypothesenstadium und hinein in echte, skalierbare Software-Bausteinpraxis.

Publizieren, aber mit Zukunft - Ein erster Baustein

Nun ist´s geschehen: Die Verlagswelt hat seit der Buchmesse 2008 unwiderruflich erkannt, dass das eBook (oder allgemeiner: eContent) nicht vorübergehend und nicht nebensächlich ist. Vielmehr gilt: "eContent is core". Das eBook kommt also. Jetzt, nun endlich. PDF gibt es schon lange und die zweite Welle der eBook Reader ist nun auch akzeptabel. Genug kritische Masse ist vorhanden, um "traditionellen Content" - also Zeitschriften und Bücher - digital der Leserschaft zuzuführen.

Aber wie nun genau? Das ist die Masterfrage. Puzzleteile für ein modernes Verlagsangebot gibt es viele. Hier als Beispiel eines, das mir sehr gut gefällt:

Das ist ein Artikel von mir dargestellt in einem Flash-basierten Viewer. Dafür habe ich nur das Artikel-PDF zu www.scribd.com hochladen müssen. Fertig. Das "Leseerlebnis" gefällt mir besser als im Acrobat Reader: das Blättern ist flüssiger, es gibt eine gute Übersicht, ich kann zwischen mehreren Ansichtmodi wechseln.

So könnte es die dotnetpro mit allen Artikeln in ihrem Archiv für die Abonnenten machen; die anderen Zeitschriftenanbieter selbstverständlich auch. Denn nicht nur hat so ein Viewer Vorteile für den Leser. Verlage können einstellen, was Sie dem online Leser mit so einem Dokument erlauben zu tun. Soll er es als PDF lokal speichern können? Soll er es drucken können? Der Verlag behält das Szepter in der Hand.

Genau das war es nämlich, was Verleger bisher vermisst haben. Bei allem Interesse für die online Welt fühlten sie sich an Physische gekettet, weil sie Angst hatten, sonst keinen Einfluss mehr auf die Verwendung ihrer Inhalte ausüben zu können. Die Wahl lautete bisher (scheinbar): Drucken und Geld verdienen oder online anbieten und leer ausgehen.

Mit einem Viewer wie oben gibt es nun noch eine dritte Position in der Mitte: online gehen und die Nutzung nach Gusto einschränken. Ohne Inhalte noch speziell für´s Web layouten zu müssen, können sie 1:1 online gestellt werden. Die Verlage können den Nutzen der online Publikation also quasi sofort einfahren - ganz ohne Reie-

Die Zukunft einer Zeitschrift wie der dotnetpro stelle ich mir deshalb so vor:

• Die dotnetpro produziert zunächst einmal alle Inhalte nur digital als PDF. Sie werden wir üblich layoutet und mit Werbung gespikt.
• Die Inhalte werden wie oben gezeigt online publiziert. Manche Inhalte sind kostenlos und können von jedem gelesen werden. Manche Inhalte kann man nur mit einem Abo lesen. Wer ein Abo hat, kann sie dann auch lokal als PDF speichern.

So weit, so gut. Hätte alles auch schon passieren können ohne einen solchen Flash-Viewer. Klar. Das online Archiv der dotnetpro gibt es ja auch schon. Aber, wie gesagt, die einfache Darstellung der Artikel (oder eines ganzen Heftes) wie oben finde ich viel attraktiver als Acrobat.

Doch jetzt weiter: Was ist denn mit den Lesern, sie gern auch Papier in der Hand hätten? Online lesen ist nicht jedermanns Sache und auch nicht optimal für jede Situation. Zum Nachschlagen nutze ich es gern. Aber meine monatliche dotnetpro auf Papier möchte ich nicht missen.

Oder genauer: Ich möchte die Artikel, die ich jeden Monat lesen möchte, auf Papier haben können, wenn ich es will. Darüber hinaus möchte ich sogar jederzeit mir Artikel der dotnetpro zu "Sonderheften" zusammenstellen können, die ich dann auf Papier bekomme.

Das geht zwar auch, indem ich mir Artikel zusammensuche und die PDFs ausdrucke. Aber wieviel Mühe ist das? Und wie sieht das Ergebnis aus? Unschönes Papiergefledder.

Inhalte in gefälliger gebundener Form: das hat Wert für mich als Leser! Die möchte ich also auch in Zukunft, wenn dotnetpro & Co "digital gehen", nicht missen. Das eBook wird das pBook nicht verdrängen. Aber es wird seine Herstellung und Nutzung verändern.

Für die dotnetpro, das CoDe Magazine, das MSDN Magazine, Dr. Dobb´s Journal usw. zahle ich also aus mehreren Gründen gern:

1. Inhalt: Sie liefern mit eine für mich relevante Mischung an Content auf hohem Niveau, ohne dass ich lange googlen muss.
2. Layout: Der Content ist gut lesbar layoutet und auf einem sprachlich ordentlichen Niveau. So ist die Lektüre leichter für mich.
3. Usability: Den Content in die Hand nehmen zu können, um ihn im Bus oder in der Badewanne lesen und darin Notizen machen zu können, macht ihn für mich lesefreundlich. Durch ein Heft blättern und auch räumlich einen Eindruck vom Inhalt zu bekommen, halte ich für wichtig für das Behalten. (eBook Reader können das nicht bieten - und wollen es auch nicht. Sie sehen darin gerade ihren Vorteil.)

Das sind meine Prioritäten. In dieser Reihenfolge. Das Papier kommt zuletzt - aber es kommt. dotnetpro & Co sollten es also nicht aufgeben. Im Gegenteil! Ichhalte das Papier auch im Zeitalter der eBooks für den Freund jedes Verlegers. Doch er muss damit anders umgehen. Es ist gerade für Fachinhalte nicht mehr erstrangig im Sinne eines primären Veröffentlichungsmediums.

Zur Zukunft der dotnetpro gehört für mich deshalb auch noch:

• Ich kann mir die online publizierte dotnetpro bei Bedarf ausgedruckt und gebunden liefern lassen. Sie wird dann on demand hergestellt.
• Nicht nur die monatlichen Artikelzusammenstellungen kann ich mir drucken und binden lassen, sondern jede Kombination von Inhalten. Die dotnetpro kann selbst Sonderhefte aus ihren Archivinhalten schnüren und online wie printed on demand anbieten. Darüber hinaus bietet sie mir die Möglichkeit, im Archiv zu suchen, Artikel zu einem virtuellen Sonderheft zusammen zu fassen - und auch dieses persönliche Sonderheft auf Papier zu bestellen.
• Und im nächsten Schritt kann ich Filter auf die Inhalte setzen, so dass automatisch Neuerscheinungen in für mich relevanten Bereichen zu "Sonderheften" gebündelt werden. Für die online Nutzung geht das heute schon mit RSS-Feeds. Aber ich wünsche mir darüber hinaus, dass diese Inhalte als Hefte einfach so mir auf den Tisch flattern. Denn dann schenke ich ihnen eine andere Aufmerksamkeit. Dann kann ich mich auf die fokussieren, statt oft online nur husch-husch drüber zu lesen.

Meine Vision von der Zukunft der Zeitschriften ist also eine hybride: Sie sollten zuerst online publizieren - was nicht heißt, dass es kostenlos sein soll. Sie sollten aber auch weiterhin auf Papier verfügbar sein, wenn ich es mir wünsche.

Der obige Flash-View ist dafür ein erster Baustein, weil er so handlich für Leser und Verleger ist. Der zweite Baustein, der ad hoc on demand Druck... der fehlt noch. Existierende Print-on-Demand Anbieter wie Book on Demand oder buchwerft können das nicht. Hilfe naht jedoch... Der zweite Baustein ist unterwegs. Davon aber ein andermal.

PS: Was ich hier über Zeitschriften gesagt habe, gilt im Grunde auch für Fach-/Sachbuchverlage. Auch sie sollten "online first" denken - ohne Abstriche beim Layout. Dann eröffnen sich ganz neue Möglichkeiten des Umgangs mit Büchern. Die Zukunft gehört dann dem cBook, dem customized book, d.h. den Büchern, die jeder sich zusammenstellen kann, wie er möchte - aber nicht muss.

Warum ich Vortragsagendas nicht mag [OOP 2009]

Ein Vortrag soll mit einer Agenda beginnen - so will es... ja, wer eigentlich? So ist es zumindest. Oft, meistens, wenn man Vorträge auf Entwicklerkonferenzen sieht. In irgendeinem Rhetorik-Lehrbuch mag das mal gestanden haben und jedes Buch mit Inhaltsverzeichnis scheint das zu unterstreichen.

Aber ich halte davon gar nicht. Und so sage ich es denn auch immer wieder den Teilnehmern der Rhetorikseminare des Professional Developer College. Die reagieren dann mit Überraschung, Unglauben, Skepsis. Das könne doch nicht sein. Man müsse doch dem werten Publikum einen Überblick geben, bevor man mit dem Eigentlichen des Vortrags beginnt.

Nun, dann möge man hier einmal hineinschauen:

Das ist ein absolut typischer Vortrag auf einer Entwicklerkonferenz. So beginnt er denn auch mit einer Agenda. Der Sprecher zeigt, wie er sich den Vortrag in thematische Abschnitte gegliedert denkt. Und er spricht darüber. Damit er sich an die Struktur erinnert, hat er das kanonische Agenda-Slide an den Anfang der Vortragslides gesetzt.

Ja, genau, damit der Sprecher sich erinnert, deshalb ist dieses Slide dort. Kein anderer Grund scheint mir plausibel. Warum? Weil der Referent die Punkte abliest. Er liest den Text vor und fügt nichts hinzu. Warum sollte er das tun, wenn er sich seiner Vortragsstruktur erinnerte? Dann würde er nämlich nicht dieselben Worte benutzen, die jeder Zuschauer auch lesen kann.

Was habe ich nun als Zuschauer davon, dass der Referent 1. eine Agenda zeigt und 2. diese Agenda nur vorliest, wie es meistens der Fall ist? Nichts. Mir wird dadurch nichts klarer. Ich baue keine Vorfreude auf, ich bin nicht überrascht, ich fühle mich nicht erhellt. Denn dass ein Vortrag mit dem Titel "Architecting for Latency" am Anfang Latenz generall thematisiert, um sicherzustellen, dass alle dasselbe darunter verstehen, dann weiter geht zu den Gründen, warum ihre Berücksichtigung sinnig ist, anschließend die Schwierigkeiten beleuchtet und am Ende - hört, hört! - Lösungen aufzeigt... nun, das (!) erwarte ich, wenn ich auch nur 30 Sekunden über das Thema nachdenke.

So hat die Agenda keinen Nutzen. Sie langweilt nur. Wie üblich. Ihr Informationswert ist Null. Darüber hinaus nimmt sie einem Vortrag jede Spannung. Wer würde schon zu Beginn eines Krimis dessen Agenda gern kennenlernen? Nichts anderes als ein "kleiner Krimi" sollte ein Vortrag aber sein: er sollte Spannung erzeugen. Die Zuschauer sollen sich in jeder Minute fragen, wie es wohl weitergehen mag in Richtung Lösung. Sie sollen emotional gefesselt sein, mitfiebern, Interesse haben. Dafür ist eine Übersicht allerdings denkbar ungeeignet.

Aber Columbo war doch auch immer Spannend, obwohl man schon zu Anfang wusste, wer der Bösewicht ist. Ja, das stimmt. Aber Columbo hat nie am Anfang verraten, wie er (!) das herausfindet. Die Spannung bestand darin, eben nicht (!) zu wissen, wie er das für uns Offensichtliche langsam erarbeitet. Columbo mag eine eigene Agenda, eine Methode gehabt haben - verraten hat er sie uns aber nicht.

Also: die Agenda am Anfang eines Vortrag hat keinen Nutzen für die Zuschauer. Entweder haben sie ohnehin schon die Erwartung, dass es so, wie der Referent beabsichtigt, durchs Thema geht. Oder sie kennen das Thema nur wenig - dann verstehen sie nicht, was der Referent da überhaupt in der Agenda nacheinander listet. Sollte schließlich beides nicht stimmen und die Zuschauer toootal von der Agenda überrascht sein... tja, dann hat der Referent sein Pulver im Grunde verschossen. Dann hat er schon am Anfang verraten, dass er eine Überraschung für das Publikum hat. Wie langweilig.

Ein Inhaltsverzeichnis, eine Agenda ist nur sinnvoll, wenn der Zuschauer mit ihrer Kenntnis Entscheidungen besser treffen kann. Welche Entscheidung soll er aber bei einem 60min Vortrag treffen? Bei einem Buch kann er nach Lektüre des Inhaltsverzeichnisses zu einem für ihn besonders interessanten Kapitel springen. Im Vortrag muss er im schlechtesten Fall bei vollem Bewusstsein 50min ausharren, um dann in den letzten 10min zu hören, was ihn interessiert. Die Agenda hat ihm Hoffnung und Überraschungseffekte genommen.

Bei einem mehrtägigen Training mag es sinnig sein, am Anfang kurz den Verlauf des Trainings zu skizzieren, damit Teilnehmer ihre Ressourcen einteilen können. Doch auch in dem Fall bin ich skeptisch, dass das mehr bringt als eine diffuse Beruhigung. Denn wer trainiert werden will, der hat naturgemäß wenig Ahnung vom Thema. Was nützt also einem Trainingsteilnehmer bei einem .NET Grundlagenseminar die Information am 1. Tag, dass er am 4. die Weihen der WinForms UserControl Programmierung empfangen wird? Soll er damit Vorfreude aufbauen? Hm...

Dass (!) ein Thema behandelt wird, ist natürlich wichtig zu wissen. Ohne diese Information würde man ein Training kaum buchen. Aber in welcher Reihenfolge die Inhalte vermittelt werden... was nützt diese Information? Sie macht es dem Referenten sogar schwer, während der Stoffbehandlung den Weg durchs Thema zuschauerbezogen zu wählen.

Bottom line: Wer noch eine Agenda am Anfang seines Vortrags hat, streiche sie ersatzlos.

Besser als eine Agenda ist ein knackiger Einstieg, der das Publikum ohne Verzug "abholt" und auf eine spannende Fahrt durch das Thema mitnimmt.

Photosynth - Rundumblick ganz einfach

Den Eindruck zu verewigen, den man als Mensch mit einem Blick oder gar einem Rundumblick hat, ist schwer. Eine Videokamera ist nicht immer zur Hand, ein "Photo Stitcher" recht umständlich zu bedienen, ein 360° Objektiv teuer. Also was tun?

Microsoft Photosynth nutzen!

Ein echt cooles Tool aus dem Forschungslabor von Microsoft, das nun den Weg in die breite Öffentlichkeit gefunden hat.

Mit Photosynth ist der Rundumblick ein Kinderspiel:

1. Einfach Fotos schießen nach Belieben. Sie im Kreis drehen für einen 360° Blick oder um das "Objekt der Begierde" fotografierend herumwandern. Egal.
2. Fotos zu Photosynth hochladen.
3. Photosynth macht daraus eine "Galerie", in der man sich mit der Maus bewegen kann: sich in der Szene drehen, nach oben/unten blicken, heranzoomen.

Ja, heranzoomen geht auch, denn man kann Totale und Close-Up mischen. Photosynth erkennt das und macht die Szene "tiefer", wo mehr Details verfügbar sind.

Ich habe das grad mal mit einem Blick von meinem Balkon ausprobiert. Hier das Ergebnis:

Die Detailbilder sind leider etwas unscharf, weil die Belichtung nicht optimal war. Aber der Gesamteffekt und -nutzen wird schon deutlich, denke ich. Am Wochenende werde ich daher mit meiner Frau losgehen und für ihren Beruf relevante Szenerien einfangen. Daraus machen wir dann Synths und stellen sie auf ihre Homepage (die wir gerade einem Redesign unterziehen). Dann können sich ihre Kunden einen viel besseren Eindruck davon machen, was sie erwartet.

Meine Frau ist Bestatterin :-) Die Szenerien werden also Friedhofskapelle, Ruhewald oder Anonymes Feld auf dem Ohlsdorfer Friedhof sein. Photosynth macht da keinen Unterschied ;-)

Ist der Fachkräftemangel hausgemacht? [OOP 2009]

Im Karriere Special der SIGS-DATACOM findet sich ein Artikel mit dem Titel "Neue Software-Entwickler braucht das Land". Hört sich interessant, weil realistisch an. Ich kenne nur Firmen, die Entwickler suchen, aber keinen, der ohne Projekt wäre. Wir brauchen also neue bzw. mehr Entwickler. Auch der Statistik offener Stellen darf man im Großen und Ganzen wohl trauen. Die spricht von mehreren Zehntausend unbesetzten IT-Stellen. Soweitsogut.

Erhellend finde ich den Artikel dann jedoch nicht. Er ergeht sich in sehr pauschalen Beschreibungen von Projektszenarien und allgemeinen Anforderungen an Entwickler. Nichts, was wir nicht schon gehört hätten. Mehrfach hören, schadet zwar auch nicht, doch diesen Beitrag finde ist so durchweg im Überflug, dass er mir nichts bringt. Und er gipfelt dann in 8 gut gemeinten Tipps zur Fitness für Entwickler. Er soll mitbringen:

• Fähigkeit, in kurzfristig zusammengestellten internationalen Projektteams schnell produktiv zu werden
• Branchenkenntnisse
• Beratungs- und Requirements Engineering-Fähigkeiten
• große, auch internationale Mobilität, da häufig Einsatz vor Ort beim Kunden
• Laufende Anpassung des Know-Hows an neue Trends
• örtliche und zeitliche Flexibilität
• Erfahrung mit Standardsoftware und Software-Frameworks
• Methodenwissen (Entwicklungsprozess und Tools)

Als ich diese Liste gelesen habe, da musste ich denn doch lachen. Oder weinen? Ja, es ist wohl eher zum Weinen. Denn wer solches fordert, der muss sich nicht wundern, dass er immer noch Entwickler sucht. Solche Entwickler müssen wirklich erst "neu gebacken werden". Ich kenne zumindest keinen.

Ein näherer Blick auf die Tipps enthüllt, warum das so ist:

Unzweifelhaft ist, dass ein Softwareentwickler "laufende Anpassung des Know-Hows an neue Trends" vornehmen muss, "Methodenwissen" braucht und "Erfahrung mit Standardsoftware und Software-Frameworks" erforderlich sind. Das alles gehört zum Kern des Berufs "Softwareentwickler", zu seinen technisch-fachlichen Kompetenzen, zu seinen Hardskills. (Was genau mit "Methoden" und "Standardsoftware" gemeint ist, bliebe zwar zu diskutieren und ist auch wohl unterschiedlich nach Lösungsdomäne (z.B. Mobile Software vs. Games vs. Web-Anwendungen), aber nehmen wir mal an, dass wir da einen Konsens fänden.)

Auch Branchenkenntnisse sind sicherlich nicht aus dem Kompetenzportfolio des Softwareentwicklers wegzudiskutieren. Allerdings: Sie brauchen Zeit. Meist mehr Zeit als der Erwerb der (grundlegenden) Fachkompetenzen.

Sind Softwareentwickler immer auch Berater?

Wie stehts nun aber mit den "Beratungs- und Requirements Engineering-Fähigkeiten"? So sehr ich auch für einen Aufbau von Softskills bei Softwareentwicklern bin (s. dazu auch meinen Beitrag "Software braucht Soft Skills" im selben Heft) - ich wüsste nicht, warum zum Beruf "Softwareentwickler" zwangsläufig "Beratungs- und Requirements Engineering-Fähigkeiten" gehören sollten. Ein Softwareentwickler ist eben ein Entwickler von Software und kein Berater und kein Requirements Engineer. Wer Fähigkeiten zur Beratung oder zur Anforderungserhebung sucht, der sollte nicht Softwareentwickler, sondern Berater und Requirements Engineers suchen. Ein gutes Auftreten beim Kunden, die Fähigkeit zum Zuhören und zur Zusammenarbeit mit dem Kunden sollen natürlich alle Softwareentwickler haben. Aber Zuhören und Zusammenarbeit sind nicht gleich Beratung und Anforderungsanalyse. Autor Rolf Unterberger schießt hier für meinen Geschmack weit übers Ziel hinaus. Das kann nur Frust und Unsicherheit erzeugen.

Kann man Teams kurzfristig bilden?

Jetzt Teamfähigkeit: Selbstverständlich sollen Softwareentwickler Teamkompetenz besitzen. Softwareentwicklung ist Teamwork. Und das ist umso schwerer, je weiter die Teammitglieder kulturell und zeitlich und politisch voneinander entfernt sind. (Auch im selben Raum!)

Herr Unterberger fordert aber quasi Unmögliches, wenn er die Fähigkeit zur Produktivität verlangt, wenn solche Teams kurzfristig zusammengestellt werden. Unmöglich ist das nämlich, weil in seiner Formulierung von den "kurzfristig zusammengestellten internationalen Projektteams " ein Widerspruch steckt. Es ist ein Widerspruch, den Manager nur ungern zur Kenntnis nehmen. Es kann nicht sein, was nicht sein darf. Denn dass es überhaupt ein Team gibt, wo kurzfristig und auch noch kulturübergreifend Menschen an ein Projekt gesetzt werden, das ist unmöglich.

Teams, d.h. Gruppen von Menschen mit gemeinsamen Werten und klaren Aufgabenverteilungen und gegenseitigem Vertrauen usw., echte Teams, die brauchen Zeit. Menschen müssen zu Teams zusammenwachsen. Dekretieren kann man das nicht. "Du, du, du und du, ihr seid jetzt ein Team! Los, hopp! Und schon produktiv sein! Ab morgen alle 1000 km von zuhause fort." Das funktioniert nicht. Egal, welche Teamkompetenz Entwickler mitbringen.

Teams brauchen Zeit. Das echte, "systemische" Team und das "organisatorische Team" sind zwei ganz unterschiedliche soziale Systeme. Echte Teams müssen durch gute Führung aus Gruppen geschmiedet werden. Zeit und solch gute Führung ist nun aber nicht jedes Managers Sache. Also fordert der Manager, dass Softwareentwickler am besten mal solche Superkompetenzen mitbringen sollten. Die würden ihm nämlich das Leben leichter machen. Aber: das ist unmöglich und führt daher nur zu Frust und Unsicherheit bei denen, die solche Tipps lesen.

Flexibilität über alles?

Zuguterletzt die üblichen Flexibilitätsforderungen. Softwareentwickler - wie quasi jeder moderne Arbeiter - sollten nicht zu sehr an ihrer Zeit oder an bestimmten Orten hängen. Flexibilität in allen vier Dimensionen ist gefragt.

Das ist natürlich keine neue Forderung. Ihr Alter macht sie nur nicht einlösbarer oder weniger kontraproduktiv.

Menschen brauchen einfach Fixpunkte in ihrem Leben, Planbarkeit, Heimat, soziale Bindungen (die mit Ort und Zeit zu tun haben). Nimmt man ihnen diese qua Jobbeschreibung, können sie nicht mehr optimal motiviert sein. (Dass es immer Ausnahmen gibt, Menschen, die in der Ferne aufblühen, die oft wechselnde Herausforderungen suchen, die sich voll reinhängen wollen, das ist unzweifelhaft. Aber sollten ihre Fähigkeiten (oder Persönlichkeitsstörungen?) deshalb zu einer branchenweiten Norm erhoben werden?)

Aber halten wir uns nicht mit solchem Grundsätzlichen auf. Nehmen wir mal an, es gibt nicht nur einzelne, sondern viele, die überhaupt wie gefordert flexibel sein können und wollen. Wo sind die denn zu finden? Ich denke, da gibt es keine zwei Meinungen: bei denen, die jünger als 30 oder maximal 35 Jahre sind.

Was bedeutet das für die freundliche Tipp-Sammlung des Artikels? Sie richtet sich an "die Jugend", an Menschen am Anfang ihrer Berufstätigkeit. Wenn wir das Erwerbsleben mal noch bis zum 67. Lebensjahr denken, dann dauert es von einem Ausbildungsabschluss mit ca. 25 Jahren knapp 40 Jahre. Laut Anforderungen des Artikels an Menschen, die die Softwareentwicklung zu ihrem Beruf erkoren haben, können von diesen 40 Jahren aber höchstens 10 professionell und attraktiv für Arbeitgeber geleistet werden. Denn nach den ersten 25% des Erwerbslebens erfüllen Softwareentwickler 2 von 8 Kriterien nicht mehr. Sie werden dann - ganz menschlich - unflexibel, weil sie sich den Wunsch nach Heim und Familie erfüllen wollen. Heute München, morgen Dubai, übermorgen Lima? Das ist nichts für Softwareentwickler, die auch mal jemand anderes sehen wollen als hyperflexible Teamkollegen.

Der Widerspruch

Aber selbst wenn Autor Rolf Unterberger mit flexiblen Softwareentwicklern bis 35 Jahre zufrieden wäre, er fände doch keine, die seine Anforderungen erfüllen. Denn die stehen im Widerspruch zueinander. Flexibilität widerspricht Erfahrung. Wer jung ist, mag flexibel sein. Aber er kann durch sein geringes Alter eben nicht die harten und weichen sonstigen Kompetenzen entwickelt haben, die die anderen Punkte fordern.

Wer in den ersten 10 Jahren seiner beruflichen Praxis als Softwareentwickler steckt, der kann nicht "Branchenkenntnisse" haben, "Beratungs- und Requirements Engineering-Fähigkeiten" besitzen und in "kurzfristig zusammengestellten internationalen Projektteams schnell produktiv" werden. Das ist Quatsch!

Er kann zwar von allem vielleicht ein bisschen. Von dem einen mehr, vom anderen weniger. Aber er kann es nicht in der Solidität, wie es der Artikel mit seinen pauschalen Forderungen suggeriert, dass er es können sollte.

Hausgemachter Fachkräftemangel

Und so kann ich nur konstatieren: Wenn die Liste des Mitzubringenden im Artikel von Rolf Unterberger wirklich ernstgemeint ist, dann ist der Fachkräftemangel hausgemacht. Solche Fachkräfte kann es nicht geben. Solche Forderungen sind Illusionen von Managern, die wenig Bezug zum Metier der Softwareentwicklung und zu den Menschen haben, die sie entwickeln. Im milden Fall sind solche Manager so stark unter Druck, dass sie keinen anderen Ausweg wissen, als den Druck so an die Anzustellenden weiterzugeben. Im anderen Fall sind solche Manager... nun, ich sage mal... nein, das verkneife ich mir doch.

Fazit: Nicht jeder Karriererat ist ein guter Rat! Nicht jeder Checkliste sollte man folgen. Der gesunde Menschenverstand sollte auch bei der Karriereplanung eingeschaltet bleiben.

Networking pur - Der .NET Open Space Event in Leipzig

Wer den Erfahrungsaustausch sucht, interessante Leute aus der DACH-Entwicklergemeinde kennenlernen will oder etwas rund um .NET lernen will, der ist mit dem .NET Open Space Event gut bedient. Zum ersten Mal fand der am vergangenen Wochenende in Leipzig statt - und wird dort hoffentlich auch in Zukunft seine Heimat haben. Ich freue mich jedenfalls schon auf den nächsten.

Anders als bei den üblichen Entwicklerkonferenzen, wo ein Content Management die Themen und Referenten plant, organisiert sich ein Open Space Event selbst. Die Agenda ist offen, nur das Oberthema - hier: .NET - steht fest, damit sich grundsätzlich Gleichgesinnte zusammenfinden.

Und dann gehts los! Sind die Gleichgesinnten "auf einem Haufen", hat jeder die Möglichkeit, ein Thema vorzuschlagen, über das er gern sprechen möchte. Dabei ist es egal, ob er oder sie kompetent zum Thema ist oder nicht. So habe ich z.B. am 2. Tage das Thema "Funktionale Programmierung" vorgeschlagen, ohne Experte darin zu sein. Mich hat einfach der Meinungsaustausch gereizt und vielleicht die eine oder andere Meinung eines unter den Gleichgesinnten anwesenden Experten. Dass dann da keiner war, sondern wir eher alle nur Einäugige oder Blinde, hat dem Erfolg jedoch keinen Abbruch getan.

Stefan Lieser leitet die Themenfindung. Foto: Kurt Häusler.

Wenn ein Thema genügend Interessenten findet, finden die sich bei einem Open Space Event in einem von den Organisatoren bereitgestellten Raum zusammen und diskutieren einfach. Das war´s. Keine weiteren Vorgaben, keine Verpflichtungen, kein großes Regelwerk.

Interesse an einem Thema und Lust auf Gespräch in einer mehr oder weniger großen Runde, das ist alles. So waren die Runden manchmal klein (wie beim Thema Parallelverarbeitung, wo wir zu knapp zehnt waren), ein andermal groß (wie beim Thema Testen, an dem alle knapp 90 Teilnehmer mitdiskutiert haben).

Bei großer Teilnehmerzahl und vielen Meinungen kann der Austausch durch einen "Fishbowl" moderiert werden. Drei Diskutanten sitzen vorne und tauschen sich aus - bis sie durch Zuhörer, die etwas beitragen möchten, abgelöst werden. Foto: Kurt Häusler.

Zu jeder Zeit konnten max. 4 Themen gleichzeitig in Gruppen besprochen werden. Das hat manches Mal für Frust gesorgt, weil es mehr als ein interessantes Thema gab. Aber es war ok. Breit interessierende Themen wurden deshalb als "general session" alleinstehend behandelt, entweder in einem Raum oder in mehreren Gruppen.

Der Wert des .NET Open Space war für jeden Teilnehmer damit proportional zu seinem Engagement: Wer ein Thema dringend behandeln wollte, hat es für ein Gruppengespräch vorgeschlagen. Wer in einer Gruppe etwas fragen/sagen wollte, hat einfach den Mund aufgemacht. Es gab keinen Rückzug darauf, dass da ja ein Sprecher nur sein Wissen loswerden wollte, um anschließend in einer Speaker Lounge zu verschwinden. Jeder war Zuhörer und Sprecher gleichzeitig - wenn er/sie wollte. So ergab sich ganz natürlich ein intensives Networking, wie man es auf keiner üblichen Konferenz findet.

Networking at its best im Foyer des Veranstaltungsortes. Foto: Kurt Häusler.

Rundum also ein innovativer Event, der mir etwas gebracht hat. Ob der Technical Summit von Microsoft im November das auch leisten wird, weiß ich hingegen noch nicht. Manchmal ist weniger Aufwand eben mehr. Denn der .NET Open Space war bescheiden ausgestattet, da er keine weitläufigen Show Floor mit Ausstellerbuden oder Handouts oder Giveaways zu bieten hatte. Macht aber nichts. Alles war völlig ausreichend. Vor allem das Caterin mit süßen Sachen :-)

Das süße Catering war sehr verführerisch. Der schlanken Linie der Open Space Besucher wären ein paar mehr Gemüsesticks beim nächsten Mal zuträglicher ;-) Foto: Kurt Häusler.

Der .NET Open Space hat zum ersten Mal stattgefunden. Open Spaces als Eventformat sind aber nicht neu. In England und den USA hat die Alt.Net Gemeinde sie schon länger für sich entdeckt. Und anno 2001 hatte sogar Microsoft in Deutschland schon einmal einen Open Space im Anschluss an den Technical Summit veranstaltet. Damals aber nur offensichtlich wenig memorablem Erfolg, da ich keinen getroffen habe, der sich daran erinnern konnte. Nun, so haben manche Ideen eben ihre Zeit. Die für Open Spaces scheint nun endlich gekommen. Lange überfällig und deshalb gut so.

Gerade deshalb ist natürlich auch noch nicht alles perfekt gelaufen in Leipzig - wenn denn das überhaupt ein Kriterium ist. Die Themenfindung könnte schneller laufen und lief auch am zweiten Tag schon schneller. Ein wenig mehr "Moderation" könnte sein, damit auch "schwächere Stimmen" einmal Gehör finden oder Sessions nicht so einfach "ins Normale" abdriften. Denn wenn aus dem Gespräch ein - wenn auch wohlmeinender - Monolog wird, der Raum dunkel ist und mehr als eine Stunde Powerpoint den Takt angibt, dann... ja, dann ist der Abstand zum Üblichen zu gering. Dann verlagert sich das Gespräch wieder ins Zufällige und in die Pausen.

Doch das sind Kleinigkeiten. Unterm Strich hat mit der Event sehr gut gefallen. Ich habe auch ansonsten nur positive Stimmen gehört. Gratulation und Dank an das Event-Team Alexander Groß, Stefan Lieser, Torsten Weber!

Die Teilnehmer können es nicht lassen. Auch nach Stunden des Networkings während der Gruppendiskussionen setzen sie die Gespräche bei der Abendveranstaltung in einer gemütlichen Leipziger Kneipe fort. Foto: Kurt Häusler.

ADC 08 - Runden auf einem runden Event

Das hat Spaß gemacht! Runden drehen auf der ADC 2008. Mit einem Segway! Zuerst im Schildkrötenmodus mit nur 9km/h, dann mit 20km/h. Huiiii... das ging ab auf dem Parkplatz des Veranstaltungsortes in Frankenthal. Eine Leichtigkeit des Fahrens, die man nicht vom Fahrrad oder Auto kennt. Denn ein Segway-Gefährt lässt sich so einfach Steuern wie die eigenen Beine: total intuitiv. Eine kleine Gewichtsverlagerung in die Wunschrichtung und schon ändert der Segway seinen Kurs. Vor, zurück, auf der Stelle - und dann auch Treppen runter :-)

Mit dem Segway hatte Hannes Preishuber als Veranstalter der ADC 2008 ein glückliches Händchen für einen Hingucker, ein Gimmick, das Techis begeistert. Weiter so! Auf der ADC 2009 sollte es ein paar mehr Segways geben und einen Parcours zur Entwicklung der Fahrgeschicklichkeit...

Doch nicht nur die Runden mit dem Segway haben die ADC 2008 zu einem runden Event für mich gemacht. Die Stimmung der Teilnehmer war gut, der Abendevent launig - mit einem Quiz, bei dem angesichts des ganzen Neuen auch mal solide Kenntnisse frührerer Technologien wie GWBASIC gefragt waren.

Das Fachliche kaum auch nicht zu kurz. Keine Sorge. Neno Loje und Bernd Marquardt hatten in bewerter Manie ein solides Programm zusammengestellt - das zeitgemäß einiges in punkto Parallelprogrammierung zu bieten hatte.

Dazu habe ich auch beigetragen mit einem Vortrag zum Thema Microsoft Concurrency Coordination Runtime. Asynchrone Programmierung liegt mir grad sehr am Herzen. Der zweite Vortrag drehte sich um Unit Tests mit Attrappen (Mock Objects). Und dann habe ich spontan noch die Herausforderung angenommen, die Keynote zu halten. Neno hatte mich am Wochenende angerufen, ob ich für den kurzfristig verhinderten Frank Fischer von Microsoft einspringen könnte mit einem architekturorientierten Thema. Auch wenn ich dafür dann etwas improvisieren musste, bin ich doch ganz zufrieden mit dem Vortrag. Er gab mir die Chance, die Notwendigkeit zu einem Bewusstseinswandel vom synchronen zum asynchronen Denken bei der Planung von Software darzustellen. Keynotes sollen ja nicht so technisch sein ;-)

Wer mag, kann sich den Beispielcode der Attrappen- und CCR-Vorträge hier herunterladen. Enjoy!

Nachtrag:

Hier der Beispielcode der Architektur-Workshop Tage zum Download:

• Workshop am Mittwoch, 15.10.2008
• Workshop am Donnerstag, 16.10.2008

Zusammenwachsen - Wie die Wiesn Frontend und Backend verbindet

O/R Mapping (ORM) ist mehr als LINQ to Sql oder NHibernate. Die ORM-Welt ist vielfältiger - und wird nun auch noch bunter. Denn ein Hersteller von "bunten Steuerelementen" für WinForms, ASP.NET, WPF und Silverlight will jetzt Farbe in die manchmal recht schwarz/weiß gezeichnete ORM-Welt bringen.

Telerik - noch immer eher ein Newcomer, wenn auch ein starker, und noch nicht so bekannt in Deutschland - hat den ORM-Hersteller Vanatec in sein Portfolio integriert. Vanatecs O/R Mapper OpenAccess, der einer der ersten für die .NET- und Java-Plattform war, schließt nun die Klammer, die Telerik mit seinen Steuerelementen um .NET-Anwendungen geöffnet hatte.

Die offizielle Verlautbarung findet sich hier. Inoffiziell wurde die Entscheidung jedoch schon beim jährlichen Treffen des Vanatec Expert Advisory Council (EAC) bekannt gegeben. Vanatec hatte sich schon vor Jahren den Kontakt zur Community auf die Fahne geschrieben, um möglichst dicht am Markt zu entwickeln. So wurden alljährlich Entwicklungsfortschritte und "Communitybefindlichkeiten" auf einem EAC-Treffen diskutiert - das nicht zufällig während der Münchener Oktoberfestzeit statfindet ;-)

 
v.l.n.r.: Jörg Neumann, Tilman Börner, Neno Loje, Ralf Westphal

Die Freude der hier abgebildeten EAC-Mitglieder ist deshalb aber nicht nur der guten Stimmung und Wiedersehensfreude zuzuschreiben. Eher wird umgekehrt ein Schuh draus: Auslöser für gute Stimmung und lachende Gesichter ist der Gewinn für die Entwicklergemeinde, den der Zusammenschluss von Telerik und Vanatec bedeutet.

Der ist zum einen finazieller Art, da die Telerik Suite ohne Preisaufschlag (!) nun auch noch OpenAccess enthalten wird, also einen ORM, der hier und heute mehr bietet als LINQ to SQL und den Kinderkrankheiten, unter denen Microsofts Entity Framework noch länger leiden wird, lang entwachsen ist.

Zum anderen besteht der Gewinn für die Community darin, dass Telerik nun versuchen wird, zusammenwachsen zu lassen, was zusammengehört: Frontend und Backend, Darstellung und Objekte, View und Model. Denn da gibt es noch einiges in punkto Datenbindung zu tun. Relationale Daten in Objekte wandeln (mapping) und dann auch noch mit ihrer Beziehungsvielfalt leicht editierbar anzuzeigen (data binding): das ist immer noch eine Herausforderung. Da muss immer noch zuviel Infrastrukturcode geschrieben werden, der vom eigentlich Wichtigen, der Geschäftslogik, ablenkt.

Wir dürfen also gespannt sein auf die Ideen, die Telerik+Vanatec in den nächsten Monaten umsetzen. Auf dem EAC-Treffen wurde dazu schon leidenschaftlich diskutiert... worunter am Ende zum Glück die Eintracht nicht gelitten hat:

Pro sit! - möge uns allen der Zusammenschluss nützen.

PS: Die Telerik Geschäftsführung aus Bulgarien war natürlich auch mit auf dem Oktoberfest. Aber es schien, als sei deutsche Ausgelassenheit - oder besser: oktoberfestige - deren Sache nicht so ganz. Ist ja auch gewöhnungsbedürftig, selbst für mich als Nordlicht.

Peter Brunner (rechts), der Geschäftsführer von Vanatec, war dafür umso besser gelaunt :-)

Wer würde das nicht verstehen? Es werden besonders spannende Monate für ihn und seine Jungs bis zum nächsten Oktoberfest :-)

Die Aschenputtel-Strategie - Ein 80:20-Kriterium für neue Technologien und Konzepte

Wie und wann entscheiden Sie sich eigentlich für den Einsatz einer neuen Technologie oder eines Konzeptes? Wann legen Sie mit IronPython los? Wie entscheiden Sie, ob Sie den Entity Framework benutzen?

Aschenputtel konnte die Tauben um Entscheidungshilfe bei der Sortierung von Linsen bitten - "die Guten ins Töpfchen, die Schlechten ins Kröpfchen". Sie hingegen sind auf sich allein gestellt. Wie entscheiden Sie zwischen Gutem und Schlechtem, d.h. Lernwürdigem und dem, was Sie ignorieren?

Diese Frage sprang mir bei der Lektüre von Kevin Hazzards Serie über F# in den Sinn. F#, Microsofts funktionale Programmiersprache, nimmt gerade Anlauf, um in den Mainstream der Programmierung zu springen. Aber lohnt sich der Lernaufwand für F# wirklich? Dito beim ADO.NET Entity Framework. Dito für die Windows Workflow Foundation. Dito für alles Neue, Vielversprechende.

Wir leben im Überfluss. An Optionen für unseren Werkzeugkasten mangelt es nicht. Und wenn wir die Qualität unserer Arbeit ständig steigern wie auch produktiver werden wollen, dann tun wir gut daran, immer wieder Neues zu lernen. Ohne eine Strategie ist es jedoch schwer, aus dem Überfluss für uns Geeignetes auszuwählen. Deshalb schließen viele Entwickler die Augen und blenden den Überfluss auf Jahre aus - um dann bei einem Jobwechsel mit einer dramatisch veränderten Welt konfrontiert zu werden, die es ihnen sehr schwer macht, auf die aktuellen Züge aufzuspringen. Eine Vogel-Strauß-Strategie ist also denkbar ungeeignet für mittel- und langfristigen Erfolg in unserer Branche.

Eine Fahne-im-Wind-Strategie bringt es andererseits aber auch nicht. Niemand tut gut daran, möglichst immer beim Neuesten schnellstmöglich dabei zu sein. Bleeding edge technology heißt nicht umsonst so: an forderster Entwicklungsfront kann man sich leicht schneiden und viel Zeit in den Sand setzen.

Von welcher Strategie können Sie sich nun aber helfen lassen? Ich nenne sie mal...

Die Aschenputtel-Strategie - oder: 80:20 einmal anders

Aschenputtel hat zwar nicht diese Strategie angewandt, aber sie hatte zumindest eine Strategie (der Delegation) und war damit organisierter als viele Softwareentwickler, wenn es um die Trennung des "Guten" vom "Schlechten" geht.

Meine Idee einer Strategie lautet nun ganz simpel:

Etwas Neues ist "gut" oder "lernwürdig" oder "adaptionswert", wenn es bei 80% der Projekte zu 20% "Einsparungen" führt.

Die 80:20 habe ich natürlich aus Effekthascherei gewählt :-) Das Verhältnis ist durch die Pareto-Verteilung zu Ruhm gekommen und insofern ein eye catcher. Letztlich geht es mir aber nicht um 80% der Projekte, sondern nur um einen genügend großen Prozentsatz, den jeder selbst für sich bestimmen muss. Ich halte nur nichts davon ihn viel höher zu setzen. Wer nach Neuem sucht, dass in 100% oder 95% der Fällen "der Bringer ist", wird kaum fündig und somit de facto zum Vogel Strauß.

Auch die 20% sind nur ein Anhaltspunkt. Die Einsparungen sollen einfach deutlich sein. Sie sollen sie nicht mit der Lupe suchen müssen. Sie sollen nicht in zufälligen Fluktuationen untergehen und auch nicht unterhalb der Messbarkeitsgrenze liegen. Da sich die Branche mit Messungen eh schwer tut, ist also ein Prozentsatz nötig, der Verbesserungen mit dem bloßen Auge erkennbar macht. Sie müssen sich auch dem oberflächlichen und gelegentlichen Betrachter recht leicht erschließen.

Nochmal etwas laxer und im Ganzen formuliert: Wenn Sie auf eine neue Technologie stoßen, einem neuen Konzept begegnen, dann fragen Sie sich: Bringt mir diese Neuerung in einem großteil meiner Projekte einen deutlichen Vorteil?

Hört sich eigentlich einfach an oder gar normal. Fragen Sie sich das nicht ohnehin? Durchaus - aber dennoch glaube ich, dass diese ausdrückliche Formulierung noch etwas bringt.

1. Durch diese Formulierung wird betont, dass eine Neuerung nicht immer, sondern nur häufig einen Vorteil bieten muss. Allzuleicht verfallen Softwareentwickler und ihre Chefs nämlich in ein Optimierungsdenken, dass mit weniger als 100% kaum zufrieden ist. 100% oder Perfektion sind aber für den Fortschritt und gerade für Lernprozesse eine zu hohe Marke.
2. Die ausdrückliche Formulierung macht nicht nur dem Betrachter etwas bewusst, sondern ist eine Mahnung an den Anbieter der Neuerung. Sie führt ihm nämlich die Pflicht vor Augen, den Betrachtern es möglichst schnell und einfach klar zu machen, wieviele und wie sie Vorteile bietet. Als Betrachter will ich nämlich nicht lange rumrätseln, ob und wie F# oder das Entity Framework vielleicht und eventuell helfen könnten. Ich will konkret und mit Bezug auf meine bisherige Praxis erfahren, warum und wie sie mir etwas bringen.

Gerade der zweite Punkt vernachlässigen die Beseelten aber häufig. Wer über F# oder SQL Service Broker oder MSF oder Software Factories schreibt, ist selbst meist so davon überzeugt, dass er sich in allgemeinen und abstrakten Beschreibungen der visionierten Vorteile ergeht - dabei aber den noch nicht beseelten Betrachter aus den Augen verliert.

Gerade auch bei der oben erwähnten F#-Serie ist mir das aufgefallen. Kevin ist so begeistert, dass er bei aller Mühe mir in 4 Folgen seiner Serie nicht deutlich gemacht hat, warum ich F# lernen sollte. (Und das, obwohl ich schon ein F# Buch im Schrank stehen und zu 2/3 gelesen habe.) Er kommt einfach nicht auf den Punkt. Er greift nicht an den vorteilhaften Differenzen zu C# an. Er kehrt nicht den Mehr(!)wert heraus.

Information ist "ein Unterschied, der einen Unterschied macht" - so definiert es Gregory Bateson. Damit ich einen positiven Unterschied in meiner Arbeit durch etwas Neues realisiere, muss mir sein "Verkäufer" aber erstmal einen positiven Unterschied zu meinen bisherigen Vorstellungen und Gewohnheiten deutlich machen. Welcher Unterschied macht also welchen Unterschied? Zum Beispiel: Was an F# im Unterschied zu C# macht also welchen Unterschied in meiner Arbeit aus?

Es genügt nicht, nur die ersten Unterschiede aufzuzeigen. Implizite strenge Typisierung, Funktionen als Werte, Currying... das sind Unterschiede zu C#. Die werden auch allerorten beschrieben. Doch welchen Unterschied machen Sie für meine Arbeit. Nicht dass ich sie anwenden könnte, dass sie überhaupt da sind, motiviert Sie oder mich zum Einsatz von F# - es sei denn, wir sind sehr akademisch interessiert. Nein, der Unterschied muss einen spürbaren (20%) Unterschied in unserer täglichen Arbeit machen.

Irgendwas muss ich durch den Wechsel von A auf B, von C# auf F# (oder Python oder Ruby), von ADO.NET auf das Entity Framework (oder NHibernate oder OpenAccess) usw., irgendwas muss ich durch diesen Wechsel "einsparen". Ja, ich denke, es geht immer ums Sparen. Woanders mag es ums Schöne oder Interessante gehen, aber in unserer Branche geht´s vor allem ums Sparen. Das Neue soll uns Zeit sparen oder es soll uns Ressourcen sparen.  Die Zeit kann beim Entwurf oder bei der Herstellung von funktionalen wie nicht-funktionalen Eigenschaften oder bei der Produktion oder der Wartung gespart werden. Oder wir brauchen zur Entwicklungszeit oder zur Laufzeit weniger Ressourcen wie Prozessorleistung oder Speicherplatz oder Bandbreite.

Also: Was, wann und wieviel spare ich, wenn ich auf F# usw. umsteige?

Das (!) ist die Masterfrage, die die "Verkäufer" von Technologien und Konzepte zu allererst und klar und verständlich und ohne Umschweife zu beantworten haben. Natürlich geht das nicht immer in so harten Zahlen wie die 80:20 suggerieren. Aber die Mühe sollte man der Darstellung schon ansehen, diesem Ideal möglichst nahe zu kommen.

Anbieter sollten sich als Leitlinie bei ihren Darstellungen Fragen wie diese nehmen, die mir bei Lektüre einer Darstellung im Kopf herumgehen:

• Hilft mir das, um den Aufwand bei der Codierung um 20% zu reduzieren?
• Hilft mir das, um in 80% meiner Projekte deutlich mehr Fehlerfreiheit zu erreichen?
• Hilft mir das, um den Wartungsaufwand um 20% zu reduzieren?
• Hilft mir das, um 80% meiner Software deutlich länger attraktiv am Markt zu halten?
• Hilft mir das, um 20% mehr Performance oder Skalierbarkeit zu bieten?

Vorstellungen von Neuem, die mir diese und ähnliche Fragen nicht beantworten, sind in nicht-akademischen Kreisen oder außerhalb der Freizeitlektüre nutzlos. Wer mich motivieren will, der muss mir klar machen, dass sein Angebot diese Leistung erbringt. Wenn ich nicht in 80% meiner Projekte 20% Verbesserung in einem Bereich spüre, der mir überhaupt bewusst ist (oder lohnenswert bewusst gemacht werden kann), dann bin ich nicht motiviert.

Insofern werde ich mich erstmal nicht weiter mit F# oder Python oder dem Entity Framework beschäftigen. C# und db4o/OpenAccess/Persistor.NET sind derzeit gut genug. Mir konnte bisher nicht klar gemacht werden, dass das Neue irgendetwas um 20% verbessert.

Noch nicht - aber das kann natürlich anders werden. Beobachten werde ich den Markt weiterhin. Irgendwann mag eine Botschaft auftauchen, die auch mir den 20%-Gewinn von F# & Co deutlich macht.

Fazit

Mir und Ihnen als Beobachter des Marktes kann ich nur empfehlen, die Aschenputtel-Strategie bewusst anzuwenden. Fragen wir uns bei allem, was wir lesen/sehen, ob es danach ins Töpfchen oder Kröpfchen gehört.

Den Anbietern von Neuem (manchmal bin ich das auch selbst ;-) kann ich nur empfehlen:

• Kennzeichnen Sie Ihre Angebote als "motivierend" oder "informierend" oder "unterhaltend". Bei motivierenden Inhalten müssen die 80:20-Fragen klar beantwortet werden. Bei informierenden Inhalte ist das nicht mehr in der selben tiefe nötig, dann bin ich ja schon motiviert, wenn und weil ich den Beitrag lesen. Dann geht es nicht mehr ums Ob und Warum, sondern das Wie. Bei unterhaltenden Angeboten schließlich geht es um, nun, Unterhaltung. Da will ich keine "Kaufentscheidungen" treffen oder etwas lernen.
• Holen Sie Ihre Zielgruppe(n) da ab, wo sie heute stehen. Im Zeitalter des Überflusses geht es nicht mehr darum, ein Vakuum zu füllen. Wir alle haben schon Lösungen für die meisten Probleme, die mehr oder weniger gut gehen. Ihr Angebot muss sich also nicht nur gegen die Wettbewerber, sondern vor allem etablierte, schon vorhandene Technologien/Konzepte (oder schlicht Gewohnheiten) durchsetzen. Am besten zeigen Sie, wie etwas mit dem Neuen geht, das bisher nicht ging, aber gehen sollte. Oder Sie zeigen, wie etwas, das heute schon geht, mit dem Neuen eben 20% "besser" geht (leichter, schneller, verständlicher, skalierbarer usw.).
• Bedenken Sie, dass Ihre Zielgruppe(n) selten vor der Entscheidung zwischen dem "Einkauf" von Neu.A oder Neu.B stehen. Es geht meistens um Alt.A oder Neu.B. Soll überhaupt etwas anders gemacht werden? Nicht wie anders, sondern ob anders, ist die oft erst durch die Lektüre eines Angebotes aufgeworfene Frage.

Als Informations- oder Motivationsempfänger sind wir offen. Das ist sozusagen unser Angebot - letztlich auch, weil wir nicht anders können. Wir wollen und müssen schauen, wo wir etwas verbessern können. Sparen - so ganz allgemein - ist Programm in der Programmierung. Und nicht nur da.

Anbieter, oder genauer: Motivierer sollten das respektieren und auf den Punkt kommen. Klare Aussagen, klare Beispiele, statt Hype.

Zum Glück ist es mit der Aschenputtel-Strategie aber einfach, zwischen Fluff, Hype, Enthusiasmus und Reellem, Bedenkenswerktem, Wahrhaftigem zu unterscheiden.