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 :-)