OOP 2007: Gedanken zu einem Niveauschema für Vorträge

In einem früheren Beitrag habe ich einen kritischen Blick zurück auf den .NET Tag der OOP 2007 geworfen. Trotzde grundsätzlicher Zufriedenheit mit den Vorträgen war bei mir ein Nachgeschmack geblieben. Das Niveau des Vortrags zum Thema Versionsverwaltung hatte nicht dem Kenntnisstand der Teilnehmer entsprochen. Wie lässt sich das in Zukunft vermeiden?

Vor dem Problem, Zielgruppenkenntnisniveau und Vortragsniveau in Übereinstimmung zu bringen, stehen Tech Chairs natürlich immer. Aber wie lösen sie es? Ich glaube, für eine systematische Lösung müssen zunächst zwei Szenarien unterschieden werden.

Das eine Szenario ist die "Ein Kessel Buntes"-Konferenz. Sie wird von einem groben Thema übertitelt, z.B. eine Technologe. Das ist der Fall für die TechEd oder die VSone oder auch die OOP. Dazu kommt noch eine ebenso grobe Beschreibung des generell angestrebten Niveaus der Veranstaltung. Die TechEd wendet sich Profis, die ADC an fortgeschrittene Profis.

Wer sich dann grundsätzlich angesprochen fühlt, der geht dann zur Veranstaltung und schaut, mit welchem Niveau die einzelnen Vorträge gekennzeichnet sind. Microsoft arbeitet mit den Niveaus 100, 200, 300, 400, die zunehmende Schwierigkeitsgrade/Tiefe anzeigen. Die Zuordnung zu einem Niveau nimmt gewöhnlich der Sprecher vor.

Das andere Szenario sind die Konzeptkonferenzen/-veranstaltungen wie die prio oder auch der .NET Tag. Das Gesamtthema ist sehr viel konkreter vorgegeben und die Vorträge folgen einem gewissen Programm, um in Summe ein größeres Ganzes zu ergeben. Teilnehmer haben hier weniger eine Wahl, sie springen weniger, sondern folgen dem vom Tech Chair gespannten Bogen. Sie können also weniger die Vorträge wählen, die ihrem Niveau entsprechen - die Vorträge müssen daher das zu erwartende Niveau der Teilnehmer eher antizipieren. Der Tech Chair muss sich dazu Gedanken machen und die den Sprechern kommunizieren.

Für die "Ein Kessel Buntes"-Veranstaltungen mögen nun wenige Schwierigkeitsstufen ausreichen, um Vorträge einzuordnen. Ich habe das zwar immer schon für zu pauschal gehalten, aber die Praxis scheint zu zeigen, dass die Teilnehmer damit leben können. Für Konzeptveranstaltungen glaube ich jedoch, dass das Niveauschema anders aussehen muss. Es geht nicht nur um Schwierigkeitsgrade, sondern auch die Form der Darstellung.

In der Zukunft werde ich es daher einmal anders probieren. Folgendes Niveauschema scheint mir praktikabel:

Theorie

100 - Impuls geben (Impulsvortrag)
Das Publikum ist mit dem Thema im Grunde nicht vertraut. Erst der Vortrag bringt es ihm nahe, er lässt es sozusagen über den Tellerrand schauen. Dem Publikum wird ein Impuls gegeben, die Augen offen zu halten und sich bei Gelegenheit einmal näher mit dem Thema zu beschäftigen.
Ziel: Zum Nachdenken anregen

200 - Awareness wecken (Motivationsvortrag)
Das Publikum hat vom Thema durchaus schon einmal gehört. Vielleicht haben einige sich daran schon einmal versucht, aber am Ende doch die Finger davon gelassen. Die Relevanz des Themas ist bisher für nicht so groß erachtet, als dass man es wirklich auf dem Zettel hätte. Der Vortrag stellt also das Thema nicht wirklich als Neu vor, sondern soll es nachhaltig in das Bewusstsein des Publikums heben. Er soll in ihm die Awareness wecken, dass das Thema wirklich relevant ist und Wert, sich damit einmal näher zu beschäftigen. Er zeigt Konsequenzen auf, was passiert, wenn man das Thema weiterhin nicht auf dem Zettel hat.
Ziel: Zur aktiven Beschäftigung mit einem Thema motivieren

300 - Orientierung bieten (Orientierungsvortrag)
Das Publikum kennt das Thema und hält es für relevant. Es möchte einen Einstieg in das Thema finden, es auf seinen Zettel nehmen. Der Vortrag gibt dem Publikum daher einen Überblick über das Thema, strukturiert es, macht sensibel für seine Terminologie. Er gibt dem Publikum eine erste Orientierungshilfe, damit es sich in der Literatur zum Thema zurecht finden kann.
Ziel: Zur eigenständigen Beschäftigung mit einem Thema befähigen

Praxisniveaus

400 - Einführung geben (Einführungsvortrag)
Das Publikum kennt das Thema und hat sich schon orientiert und möchte jetzt damit loslegen. Der Vortrag nimmt das Publikum deshalb an die Hand und führt es möglichst pragmatisch in ausgewählte Aspekte ein. Es sollen die Grundzüge des Umgangs mit dem Thema vermittelt werden.
Ziel: Zur Anwendung einfacher Aspekte auf den Projektalltag befähigen

500- Vertiefen (Vertiefungsvortrag)
Das Publikum hat das Thema schon in den Projektalltag integriert und die Grundzüge verstanden. Der Vortrag nimmt daher das Publikum an die Hand und führt es tiefer ins Thema ein. Es werden speziellere Aspekte behandelt, Sonderfälle vorgestellt, kompliziertere Sachverhalte gelöst. Der Vortrag wendet sich an ein schon erfahrenes Publikum.
Ziel: Zur Anwendung auch komplizierter und spezieller Aspekte auf den Projektalltag befähigen

600 - Best Practice demonstrieren (Best-Practice-Vortrag)
Das Publikum hat weitgehende Erfahrung mit dem Thema. Es sucht den Erfahrungsaustausch mit dem Experten und den Peers, um die Anwendung des Themas zu optimieren. Der Vortrag stellt Modelllösungen und Wege vor, die sich in der Praxis bewährt haben. Er wählt aus den Optionen der Konzepte und Werkzeuge des Themas, d.h. aus dem gesamten Raum des Möglichen bewusst nur eine Untermenge des Praktikablen aus. Solche Best Practices ergeben sich erst nach längerer Zeit des aktiven und breiten Einsatzes eines Themas und sind insofern ein Destillat des Machbaren.
Ziel: Zum meisterhaften, souveränen Einsatz im Projektalltag befähigen

700 - Kritik üben (Kritikvortrag)
Das Publikum ist intim mit dem Thema vertraut und stößt an seine Grenzen. Der Vortrag beleuchtet daher das Thema kritisch, macht Möglichkeiten und Grenzen explizit und deutet zumindest Wege an, wie die Grenzen überschritten werden können.
Ziel: Kritische Reflektion des Themas, um einen bewussteren Einsatz im Projektalltag zu fördern

Mit diesen aufeinander aufbauenden Niveaus für Vorträge fühle ich mich recht wohl. Die Zielgruppen und das Ziel für Vorträge auf jedem Niveau sind klar beschrieben. Sie beschreiben die Annäherung an ein Thema, dessen schrittweise Meisterschaft und schließlich auch den Übergang zu einem Thema, das darüber hinaus weist. Sie entsprechen damit sozusagen dem Lebenszyklus jedes Themas.

Natürlich lässt sich nun nicht jeder Vortrag in Zukunft 100%ig einem dieser Niveaus zuordnen. Motivation und Orientierung finden oft zusammen statt. Für den einen ist etwas noch einfach, der andere empfindet es schon als Vertiefung. Und kritische Elemente können auf jeder Ebene vorhanden sein.

Nichtsdestotrotz werde ich mich um möglichst klare Zuordnung in Zukunft bemühen, woimmer ich als Tech Chair arbeite. Und wenn ich einen Vortrag einreiche, dann klassifiziere ich ihn einfach auch mal nach diesem Schema. Vielleicht kann ich ja andere Tech Chairs davon überzeugen, es auch zu benutzen. Dann könnten wir über Veranstaltungsgrenzen hinweg für die Teilnehmer mehr Klarheit schaffen.

Zum Abschluss noch die nachträgliche Niveauzuordnung für die Vorträge des .NET Tags der OOP 2007:

200 - Softwareproduktion als Oberthema: Der .NET Tag sollte die Awareness in puncto automatischer Qualitätsüberwachung und Produktion heben

300 - Korrektheit gewährleisten, Rainer Grau: Der Vortrag hat einen Überblick über verschiedene Aspekte des automatischen Testens und produzierens gegeben. Die Teilnehmer können jetzt selbst den Einstieg in die für sie besonders relevanten Aspekte finden. Rainer Grau hat einen 300er Vortrag geliefert, ich hatte mir ursprünglich allerdings einen 400er vorgestellt.

400 - Betrieb überwachen, Holger Schwichtenberg: Holger hat konkret gezeigt, wie sich der Betrieb einer Software überwachen lässt. Damit kann das Publikum im Grunde sofort praktisch einsteigen. Aber Holger hat durch die Vielfalt der Technologien, die er gezeigt hat, auch einen Überblick gegeben. Insofern ist es ein 300-400 Vortrag gewesen.

300 - Varianten & Versionen verwalten, Holger Schwichtenberg: Holger hat einen Überblick über das Thema gegeben und im Grunde keine Praxis gezeigt. Das hat nicht dem Kenntnisstand des Publikums entsprochen. Ich hatte auch einen 500er oder 600er Vortrag erwartet. Hier ist die Planung also leider etwas daneben gegangen. Aber in Zukunft kann ich meine Erwartungen ja nun besser kommunizieren.

300 - Automatisch produzieren, Neno Loje: Das Publikum hatte zu diesem Aspekt wenig Erfahrung. Neno hat daher aus meiner Sicht mit einem 300er Vortrag das richtige Niveau getroffen. Ein 300er ist es gewesen, weil Neno im Grunde nicht mehr das Bewusstsein der Teilnehmer wecken musste, sondern anhand einiger Beispiel einen Überblick gegeben hat, wie sich das Thema im Projektalltag manifestieren lässt. Die Teilnehmer haben Werkzeuge gesehen und Zusammenhänge kennengelernt, so dass sie jetzt auch allein ins Thema praktisch einsteigen könnten.

200 - Qualität überwachen, Walter Bischofberger: Automatische Qualitätsüberwachung von Software mit Metriken oder Strukturanalyse ist für die meisten Teilnehmer bisher ein Buch mit sieben Siegeln gewesen. Dass das geht und nicht so schwierig ist, dass es sinnvoll ist und in keinem Projekt fehlen sollte, das sollte Walter dem Publikum vermitteln und hat es auch geschafft. Er hat vor allem Bewusstsein geschaffen, aber auch einen Überblick und praktischen Einblick gegeben.

Und jetzt... auf zur nächsten Konferenz und frisch das Niveauschema angewandt. Mal schauen, wie es mir bei der nächsten prio gelingt. Ich sehe es ja nicht nur als Mittel zur Kennzeichnung von dem, was da ist, sondern als Planungsinstrument.

.NET 3.0 kompakt - Mein neues Buch ist da!

Endlich ist es nun herausgekommen. Die neue Auflage oder eher die komplette Überarbeitung meines ersten Buches: .NET kompakt.

Anlässlich des .NET 3.0 Release haben Christian Weyer und ich es unternommen, sozusagen die entscheidenden "Neuzugänge" beim .NET Framework von Version 2.0, 3.0 und auch schon darüber hinaus wieder einmal von einem recht grundlegenden Blickwinkel aus zu beschreiben.

.NET 3.0 kompakt

Ralf Westphal, Christian Weyer

Spektrum Akademischer Verlag, 2007, ISBN 382741458X

221 Seiten, 17 EUR

Klappentext:

.NET hat sich als Plattform etabliert. Dennoch ist Orientierungshilfe für .NET nötig, denn die Plattform wächst kontinuierlich. ".NET 3.0 kompakt" arbeitet deshalb die großen Strömungen in der Entwicklung der .NET-Sprachen und -APIs heraus. Das daraus entstehende big picture hilft Ihnen einzuschätzen, welche Bedeutung .NET für Ihre Projekte heute und in Zukunft haben wird. Die Autoren erklären Ihnen die grundlegenden Konzepte der Plattform; dabei geht es nicht um technische Details, sondern um die Zusammenhänge in einer komplexen technologischen Landschaft. ".NET 3.0 kompakt" beantwortet Fragen wie:

-Was ist neu bei C# 2.0 und VB8 und warum wurden gerade diese Features eingeführt?

-Was steckt hinter WCF, WPF, WF, Windows CardSpace, Linq, Generics?

-Welchen Einfluss haben die neuen Plattform-Features auf die Architektur von Software?

-Wie sieht die Zukunft der .NET-Plattform aus?

Viel Spaß beim Lesen!

Das Intuitive Datenmodell I

Ich möchte ein neues Datenmodell vorschlagen. Eines, das sich radikal von denen unterscheidet, die Sie täglich in der Softwareentwicklung einsetzen.

Ich möchte ein Datenmodell vorschlagen, dass nur noch Werte kennt und keine Referenzen mehr zwischen diesen Werte. Diese konzeptionelle Reduktion macht es ohne Verlust an breiter Einsetzbarkeit in vielen Fällen einfacher zu handhaben als andere Datenmodelle, eröffnet darüber hinaus aber auch ganz neue Perspektiven auf den Umgang mit Daten.

Motivation
Sie haben das Objektorientierte Datenmodell verinnerlicht, denken täglich in den Bahnen des Relationalen Datenmodells, jonglieren mit XML und haben bestimmt auch von anderen (persistenten) Datenmodellen [1,2] gehört wie dem Hierarchischen oder gar dem Assoziativen Datenmodell.

Diese Datenmodelle haben natürlich alle ihre Berechtigung. Jedes versucht auf seine Weise das Problem zu lösen, Datenzusammenhänge der realen Welt für Software bearbeitbar zu machen. Und das leisten sie grundsätzlich auch.

Sind die existierenden Datenmodelle deshalb aber perfekt? Könnte die Datenmodellierung nicht für manche oder gar viele Fälle einfacher oder flexibler sein? Ich glaube, ja. Ich glaube, wir sind schon so sehr gerade in die Mainstream-Datenmodelle eingetaucht, dass wir den Schmerz, den sie uns manchmal bereiten, nicht mehr spüren. Sie sind ja auch zumindest so leistungsfähig, dass wir am Ende irgendwie alle Datenmodellierungsprobleme lösen. War das dann allerdings so einfach, wie es hätte sein können?

Gewöhnlich beantworten Sie diese Frage von einem Standpunkt innerhalb der Menge der existierenden Datenmodelle. Sie überlegen, ob Sie ein Datenschema mit den vorhandenen Mitteln, den Konzepten des gewählten Datenmodells, auch wirklich gut entworfen haben – oder ob vielleicht ein anderes der verfügbaren Datenmodelle etwas geeigneter gewesen wäre.

Eine verständliche Haltung und die allermeiste Zeit können wir uns auch keine andere leisten. Wir müssen mit den Werkzeugen leben, die wir haben.

Wenn die Antworten dann aber immer wieder schwer fallen, wenn sie immer wieder lauten, „Ja, ich habe es so gut gemacht, wie es das Datenmodell erlaubt, aber irgendwie ist das Ergebnis trotzdem unbefriedigend“, dann kann es Zeit sein, den Standpunkt zu wechseln und über den Tellerrand zu schauen.

Solche Antworten sind es nun, die mich angetrieben haben, über die existierenden Datenmodelle hinaus zu denken. Trotz oder wegen aller Vertrautheit mit der Objektorientierung, RDBMS und XML bin ich immer wieder in Situationen geraten, wo ich diese Datenmodelle als umständlich oder beschränkend empfunden habe. Der Grund: sie leiden alle am selben Problem.

Die Container-Referenz-Dichotomy als Grundproblem
Die existierenden Datenmodelle [1,2] basieren alle auf einer grundlegenden Dichotomie, der zwischen Containern und Referenzen. Sie sind die wiederkehrenden, fundamentalen Konzepte aller Datenmodelle.

Egal, ob Sie objektorientiert oder relation modellieren, Sie müssen sich immer wieder dieselbe Frage stellen: Fasse ich diese und jene Daten zusammen in einen Container oder soll ich sie lieber auf verschiedene Container aufteilen und dann die Container einander referenzieren lassen?

Sind die Container Objekte oder Datensätze? Heißen die Referenzen Objektvariable oder Fremdschlüssel? Das sind Feinheiten. Ihre Frage ist trotzdem dieselbe. Und sie ist nicht leicht zu beantworten, denn eine Entscheidung hat weitreichende Folgen:

• Ob Daten zusammen im selben Container liegen oder nur über Referenzen verbunden sind, hat Einfluss auf die Form des Codes zur Speicherung und zur Abfrage. Das hat wiederum Auswirkung auf die Performance.


• Ob Daten heute zusammen mit anderen in einem Container liegen oder für sich allein, hat Auswirkungen darauf, wie Sie morgen Bezug auf sie nehmen können. Um Daten in neue Zusammenhänge stellen zu können, müssen sie auf den Punkt referenzierbar sein; das sind sie aber nur, wenn sie allein in einem Container stehen. Ihre Entscheidungen für Container und Referenzen haben also Auswirkungen auf die Flexibilität Ihres Datenmodells.

Zur immer wieder zu fällenden Entscheidung zwischen Container und Referenz tritt eine Beschränkung der Schachtelung von Containern. Sie können Daten in Felder/Spalten stecken, die dann zu Klassen/Tabellen zusammenfassen… und das war´s. Sollten Daten in der Realität jedoch in tieferen Hierarchien stecken, dann müssen Sie sie „flachklopfen“, um sie mit den existierenden Datenmodellen abzubilden. Nur XML macht hier eine Ausnahme, hat aber nicht den Stellenwert als Datenmodell, den Objektorientiertes oder Relationales haben.

Bei aller Liebe zu den Mainstream-Datenmodellen empfinde ich sie also zunehmend als beschränkend und umständlich. Sie sind leistungsfähig und etabliert… aber für bestimmte Anwendungsfälle scheinen sie mir inzwischen unzeitgemäß:

• Für eine Softwarewelt, in dem immer mehr flexibel und dynamisch passieren soll – die dynamischen Sprachen wie Ruby oder Python sind dafür nur ein Beisiel –, sind ihre Schemata zu starr.
  
• Für eine Softwarewelt, in der immer mehr ad hoc entwickelt werden soll, weil keine Zeit für lange Planung ist, sind ihre Schemata zu schwer zu entwerfen. Entscheidungen über Datennormalisierung können nur von Fachleuten getroffen werden; der Poweruser ist überfordert.
  
• Für eine Softwarewelt, in der es immer mehr gilt, „Wissen“ aus schon Vorhandenem zu heben (Datamining), bieten existierende Datenmodelle zuwenig Hilfe bei der Vermeidung oder Auflösung von Dateninseln.

Soweit die Probleme mit heutigen Datenmodellen aus meiner Sicht. Verstehen Sie, warum ich mich motiviert gefühlt habe, nach einer Alternative bzw. Ergänzung zu suchen? Gefunden habe ich dann schließlich einen Ansatz, den ich das Intuitive Datenmodell nennen möchte.

Davon mehr im nächsten Artikel dieser Serie.

Ressourcen
[1] UnixSpace, Database Models, http://unixspace.com/context/databases.html
[2] Mike Prestwood, An Introduction to Object Orientation, http://www.prestwood.com/ASPSuite/KB/document_view.asp?qid=100137

Googlegeiz ist geil - Kostenlose Zugriffsstatistiken mit Google Analytics

Eigentlich bin ich ja nicht so sehr der Freund der allgemeinen "Geiz ist geil"-Mentalität und dem ewigen Wunsch nach "kostenlos, kostenlos, kostenlos". Kostenlos ausprobieren und so den Nutzen vor dem Kauf bestimmen können, ist sicherlich immer gut - aber wertvolle Dienstleistungen dürfen und sollen selbstverständlich auch etwas kosten.

So ganz allgemein freue ich mich dann aber natürlich auch, wenn eine coole Dienstleistung auch einmal kostenlos ist. Konkret ist das im Augenblick Google Analytics, ein online Service zur Erhebung von Website-Statistiken.

Für meine Homepage www.ralfw.de habe ich zwar über meinen Provider QualityHosting - mit dem ich sehr zufrieden bin - schon eine Statistik, aber für dieses neue deutsche Blog nicht und auch nicht das Blog des Professional Developer College, die beide bei blogspot.com gehostet sind.

Nach Einrichten der Blogs hatte ich also überlegt, wie ich dafür auch Statistiken bekommen könnte und bin auf Google Analytics gestoßen. Da blogspot.com auch von Google betrieben wird und mir gefällt, hab ich dann gedacht, warum nicht auch für die Statistik dann beim selben Anbieter bleiben.

Und ich bin sehr zufrieden mit meiner Entscheidung! Das Anmelden bei Google Analytics ist supereinfach. Um Zugriffsstatistiken erheben zu lassen, muss dann in die zu beobachtenden Seiten nur ein kurzes Script eingesetzt werden; das ist besonders einfach, wenn die Seiten durch ein CMS generiert werden, weil eine solche Änderung dann nur zentral an einer oder wenigen Seitenvorlagen vorzunehmen ist.

Fertig! Fortan führt Google Analytics Buch über die Bewegungen von Besuchern auf Ihren Seiten. Die Statistiken sind fein gegliedert und nach Rollen (z.B. Marketing, Webmaster) zusammengefasst. Da sollte kaum ein Wunsch offen bleiben - zumindest für die allermeisten Betreiber von kleinen bis mittleren Websites. Da ich nun endlich auch die "Referrals"-Übersicht gefunden habe, bin zumindest ich wunschlos glücklich - und das zum Nulltarif.

Happy tracking!

PS: Ja, ja, ich bin mir schon bewusst, dass Google den Service natürlich kostenlos anbietet, weil er für Google einen Nutzen hat. Google erfährt noch mehr über die Seiten, die sie ansonsten nur einfach verschlagworten können. Aber: so what? Erstens kann ich jederzeit wieder aus Google Analytics aussteigen, wenn ich meine, dass dadurch die "Bewertung" meiner Seiten in der Google Suchmaschine schlechter wird. Zweitens hänge ich noch dem naiven Glauben an, dass in Ermangelung eines Semantic Web Google nur "gerechter" werden kann, wenn es mehr über einen Website erfährt wie z.B. durch Nutzungsstatistiken.

OOP 2007: (Selbst)Kritischer Rückblick auf den .NET Tag

Der .NET Tag der OOP 2007 liegt hinter uns. Alle Jahre wieder... Die OOP nun schon zum 16. Mal! Der .NET Tag immerhin auch schon zum vierten Mal. Im Fluss der stetigen Neuerungen in der Branche finde ich ein paar Inseln der Konstanz eigentlich sehr entspannend. Insofern würde ich auch sagen: Nach dem .NET Tag der OOP ist vor dem .NET Tag der OOP :-)

Mir hat der .NET Tag wieder Spaß gemacht - und ich hoffe, das Feedback wird zeigen, dass es auch den Teilnehmern so gegangen ist. Als Tech Chair des .NET Tages ist es ja meine Aufgabe, ein attraktives Programm zusammenzustellen.

Die Teilnehmerzahl war aus meiner Sicht jedenfalls zufriedenstellend. Der erste Vortrag um 9h war noch nicht so gut besucht (ca. 40-50 Teilnehmer), was wie immer am frühen Termin, aber in diesem Jahr auch speziell an den Witterungsverhältnissen lag. Aber die weiteren Vorträge haben bis zum Schluss regen Besuch anziehen können; ich schätze mal, es waren jeweils 70-90 Teilnehmer oder sogar mehr.

Und wie waren die Vorträge? Hm... Ich fand sie alle "solide". Es gab keine "Ausreißer" nach oben oder unten in der Qualität, d.h. keinen besonders begeisternden, aber auch keinen besonders enttäuschenden Vortrag. Der Gruntton war besonnen - außer bei Neno Loje mit seiner positiv "jugendlichen Art".

Im Grunde bin ich also zufrieden mit der "Performance" der Referenten. Dennoch kann ich den .NET Tag nicht einfach als perfekt und erledigt abhaken.

Nachdenklich macht mich aber nicht so sehr die Bemerkung eines Teilnehmers während des Vortrags "Qualität überwachen" von Walter Bischofberger, das höre sich an wie eine "Verkaufsveranstaltung". Dem Teilnehmer stieß auf, dass Walter (unter anderem) über sein eigenes Produkt Sotograph referierte. Auch wenn ich den Gedanken hinter der kritischen Bemerkung des Teilnehmers verstehe, so finde ich sie in ihrer Pauschalität aber unberechtigt. Es ist nicht die Aufgabe einer Konferenz wie der OOP, "kritische Rezensionen" von Technologie und Konzepten zu präsentieren. Jede Konferenz will vor allem Möglichkeiten demonstrieren und zeigen, was geht. Wenn dann hier und da ein Vortag zum Verriss wird wie Christian Weyers zum Thema Web Service Software Factory, dann ist das natürlich ok - aber es ist nicht Sinn des Ganzen. Entwicklerkonferenzen sind keine wissenschaftlichen Veranstaltungen. Es geht nicht um die Diskussion rivalisierender Theorien und ihre Falsifizierung. Es geht um die Präsentation von technologischen Optionen, das Machbare - das selbstverständlich immer auch Lücken hat.

Und insofern finde ich es nicht besonders kritikwürdig, wenn ein Sprecher über sein eigenes Produkt spricht. Ein "unabhängiger" Sprecher ist zwar immer eine politisch bessere Wahl - aber nicht für jedes interessante und vorstellenswerte Produkt gibt es einen solchen Sprecher. Also stehe ich zu meiner Wahl von Walter Bischofberger als Referent zum Thema Qualitätsmessung. Er hat in das Thema allgemein eingeführt, andere Produkte nicht ausgeklammert und dann 2-3 Demos dessen, was möglich ist bzw. auch mit anderen Tools möglich sein sollte mit seinem Sotograph gemacht. Ist das wirklich kritikwürdig? Finde ich nicht. (Zugegeben: Es kommt dabei auf den Ton an. Ein Verkäufergebahren womöglich gepaart mit mangelnder technischer Kompetenz sind selbstverständlich zu vermeiden. Beides fehlte dem Vortrag aber zum Glück.)

Die spontane Kritik des Teilnehmers ist auch naiv, weil Sprecher jeder Herkunft kein Interesse daran haben können, (besonders) kritisch aufzutreten. Niemand wird einen Vortrag nach dem Motto "Warum sie XYZ nicht nutzen sollten" einreichen. Der Grund: Am Ende färbt die Negativität der Aussage auf den Sprecher ab. Der möchte ja aber positiv assoziiert werden, um sich (oder seine Firma) auch über den Vortrag hinaus "zu verkaufen".

Eine Fachkonferenz wie die OOP ist also unterm Strich notwenig immer eine "Verkaufsveranstaltung": Alles, was präsentiert wird, wird ganz allgemein und grundsätzlich in positiver Weise dargestellt. Eine Fachkonferenz demonstriert das Mögliche, den state-of-the-art dar - und eben nicht das, was nicht geht. Dabei gibt es natürlich auch kritische Töne und es werden auch Grenzen von Technologien und Werkzeugen gezeigt. Sprecher können dadurch auch ihre Glaubwürdigkeit steigern. Aber die Dosis der Kritik muss vergleichsweise klein sein. Kein Teilnehmer will ja nach Hause fahren und sagen "Hey, Leute, jetzt weiß ich, was wir alles nicht tun sollten." :-)

Insofern: Mir ist ein solider Vortrag eines technisch beschlagenen Vertreters eines Herstellers lieber als ein schlechter Vortrag eines unabhängigen Sprechers. Ein guter Vortrag eines Unabhängiger ist dann noch eine Steigerung... aber nicht immer findet sich eben solch ein Sprecher. Und mir ist ein solider Vortrag durch den Hersteller vor allem lieber, als womöglich ein interessantes Thema gar nicht zu behandeln! Das aber geschieht häufig, weil viele spannende Technologien so wenig bekannt sind, dass sich kein unabhängiger Kompetenzträger findet, der auch noch ein guter Sprecher ist.

Aber, wie gesagt, diese kritische Äußerung des Teilnehmes über die vermeintliche "Verkaufsveranstaltung" hat mich gar nicht so nachdenklich gemacht. Viel mehr habe ich überlegt, ob die Vorträge des .NET Tages im Allgemeinen das richtige Niveau hatten.

Dass das Oberthema "Softwareproduktion" richtig gewählt war und wichtig zu vermitteln ist, davon bin ich weiterhin überzeugt. Aber die herausgegriffenen Aspekte waren den Teilnehmern sehr unterschiedlich vertraut. Eine Versionsverwaltung betreiben quasi alle schon, wie eine kurze Umfrage zeigte. Aber eine Qualitätsüberwachung eher keiner. Unit Testing ist allen bekannt, aber ein umfassender Techprozess dennoch nicht breit etabliert.

Das Niveau der Vorträge ist dieser unterschiedlichen Vertrautheit mit den Themen allerdings nicht unbedingt gerecht geworden. Bei Rainer Grau hätte ich mir etwas mehr Konkretheit in der Beschreibung gewünscht, wie Korrektheit gewährleistet werden kann. Und Holger Schwichtenberg hätte die breite Bekanntheit von Versionsverwaltungssystemen nutzen können, Best Practices vorzustellen; stattdessen hat auch er nur recht allgemein - wenn auch solide - zum Thema referiert.

Für mich ergibt sich daraus der Schluss: Gerade bei einer Konzeptveranstaltung wie dem .NET Tag ist es wichtig, das Wissensniveau der Teilnehmer richtig einzuschätzen und die Vorträge danach auszurichten. Bei den üblichen "Ein Kessel Buntes"-Konferenzen wird das umgekehrt durchaus getan: Vortragsvorschläge sind dort mit einem Schwierigkeitsgrad zu kennzeichnen. Teilnehmer können sich dann die Vorträge heraussuchen, die ihrem Kenntnisstand entsprechen.

Eine Konzeptveranstaltung, die das Oberthema vorgibt, muss hingegen anders arbeiten. Sie muss proaktiv den zu erwartenden Kenntnisstand der Teilnehmer einschätzen und danach nicht nur die Vortragsthemen definieren, sondern auch das Niveau des Vortrag. Und das sollte sich nicht in 100, 200, 300, 400 wie bei Microsoft erschöpfen, sondern feiner unterscheiden.

Ich denke, zu so einem "Niveauschema" für Vorträge, muss ich mir für den nächsten .NET Tag mal Gedanken machen. Dann stimmen Teilnehmererwartungen und Sprecherleistungen hoffentlich noch besser überein.

Software als System III – System durch Kommunikation

Software ist zunächst einmal ein Etwas, das in eine Umwelt eingebettet ist. Sie ist sogar von ihrer Umwelt nicht zu trennen. Software kann nicht ohne Umwelt gedacht werden und beide nicht ohne gegenseitige Beeinflussung. So ist es eben, dessen sollte man sich bewusst sein, denn nur dann kann man diese Beeinflussung auch steuern. Darüber will ich aber erst später weiter nachdenken.

Jetzt erstmal ein näherer Blick auf das, was die Software nun ausmacht. Auf den ersten Blick erscheint sie als ein Etwas, eben die Software. Ein Beobachter sieht sie dann als Ganzes. Der kann aber auch seine Perspektive wechseln, sozusagen näher heranzoomen und dann das Softwareganze als etwas Zusammengesetztes sehen. Software besteht immer aus mehr oder weniger Teilen. Das sind vor allem die aus der Programmierung resultierenden Code- und Datenartefakte, aber es können auch „zugekaufte“ sein.

Solange diese Artefakte allerdings nur einfach so „herumliegen“, ist Software nicht sehr spannend. Zu „leben“ beginnt Software erst, wenn die Artefakte miteinander in Beziehung gesetzt werden und entlang dieser Beziehungen interagieren. Das ist die Geburt von Software als System.





Erst wenn die Softwarebestandteile aufeinander operieren, entsteht aus den bis dahin „toten“ Bausteinen ein „lebendiges“ System, das der Umwelt gegenüber Funktionalität bietet. Wie und wann die Beziehungen zwischen den Artefakten definiert werden, ist dafür zweitrangig. Zur Laufzeit manifestieren sie sich und lassen ein „Gewebe“ aus Artefakten entstehen.

Die schon zur Entwicklungszeit festgelegten statischen Referenzen sind für das System zur Laufzeit natürlich der Ausgangspunkt; die wahre Komplexität einer Software ergibt sich allerdings erst mit Aufnahme der Kommunikation. Der Code einer Software ist mithin immer nur ein Bauplan oder eine Erzeugungsanweisungen für die zur Laufzeit zu instanzierenden und kommunizierenden Artefakte. Die Komplexität einer Software zur Entwicklungszeit ist also immer kleiner als die zur Laufzeit.

Die Komplexität sehe ich in diesem Zusammenhang zumindest positiv korrelierend mit der Zahl der kommunizierenden Strukturelemente, der Zahl der Kommunikationspfade, der Zahl der Zyklen im Graphen der kommunizierenden Strukturelemente, der Reichweite von Operationen. Oder einfacher ausgedrückt: Je mehr die Struktur einer Software einem Topf voller Spaghetti gleicht, desto komplexer ist sie :-)

Natürlich kommunizieren aber nicht nur die Strukturelemente einer Software miteinander, sondern auch die Software als Ganzes mit der Umwelt. So kann es zumindest ein Beobachter sehen, für den die Software eine Black Box ist. Macht er sie dann auf, stellt sich heraus, dass immer nur einzelne Strukturelemente auf der Umwelt operieren bzw. die Umwelt wahrnehmen.

Die mit der Umwelt interagierenden Strukturelemente definieren dabei gleichzeitig die Grenze einer Software. Sie ist also keine analoge Linie, sondern besteht aus diskreten Teilen.




[Vorhergehender Artikel] [Nächster Artikel] [Artikelserie]

Software als System II – Software-Umwelt-Kopplung

Ich versuche also mal einen ganz unverstellten Blick auf Software, lasse (zunächst) mal alles hinter mir, was .NET oder OOP angeht. Was ist dann Software?

Ich glaube, es ist hilfreich, Software zunächst einmal ganz allgemein als etwas zu betrachten, das von seiner Umwelt zu unterscheiden ist. Insofern gibt es eine Trennlinie zwischen dem, was wir zu einer Software rechnen und dem Rest der Welt.

Klingt trivial – ist aber wichtig, um das Besondere an Software zu verstehen. Aber ich will nicht vorgreifen.

Nun „liegt“ Software aber nicht einfach so in ihrer Umwelt, sondern allemal die Umwelt verändert sich über die Zeit. Diese Veränderungen wirken sich natürlich auch auf die Software aus. Umweltveränderungen ziehen also Softwareveränderungen nach sich. Und umgekehrt: Veränderungen an der Software führen auch zu Veränderungen in ihrer Umwelt. Software und Umwelt stehen also in einer Rückkopplungsbeziehung: Veränderungen an einem Beziehungspartner wirken sich nicht nur auf den anderen aus, sondern über jenen auch wieder zurück auf diesen und immer so fort…

Software und Umwelt sind jedoch nicht einfach zwei amorphe „Blobs“, sondern haben eine je eigene Struktur. Ihre gegenseitige Beeinflussung kann daher als strukturelle Kopplung bezeichnet werden. Strukturänderungen auf der einen Seite führen zu Strukturänderungen auf der anderen usw.

Was genau die Strukturbestandteile der Umwelt sind, soll an dieser Stelle zunächst vernachlässigt werden. Ganz allgemein lässt sie sich aber in mehrere sehr verschiedene Bereiche gliedern. Zur Umwelt einer Software gehören z.B.:

-Die hard- und softwaretechnische Infrastruktur in der sie läuft
-Die technologischen Optionen für ihre Realisierug
-Die Geschäftsprozesse der Kunden
-Das Verhalten der Anwender

Veränderungen können hier z.B. bei den technologischen Optionen beginnen, die bei Adaption zu einer Verbesserung von Performance und Skalierbarkeit der Software führen, die sich wiederum auf die Geschäftsprozesse des Kunden auswirken, die wiederum Begehrlichkeiten wecken und zu neuen Anforderungen führen, die dann Anpassungen in der Software nach sich ziehen usw. usf.

Der Begriff der strukturellen Kopplung [1] ist Maturanas Konzept der autopoietischen Systeme entnommen [2]. Ich finde einfach, er passt sehr gut, um die gegenseitige Beeinflussung von Umwelt und Software zu beschreiben. Allerdings will ich damit nicht sagen, Software sei ein autopoietisches System. Software ist noch nicht einmal ein autonomes System. Software verändert sich also nicht selbst, sondern nur durch Eingriffe ihrer Entwickler, auf die die Umwelt der Software direkt oder indirekt wirkt. Für die weitere Betrachtung finde ich es jedoch einfacher, davon abzusehen und stattdessen der Einfachheit halber zu denken, die Struktur einer Software würde direkt von ihrer Umwelt beeinflusst.

[1] Vogel & Partner, Strukturelle Kopplung, http://www.hs-niederrhein.de/fb06/vogel/konstrukt/glossar/strukturellekopplung.htm
[2] Wikipedia, Autopoiesis, http://de.wikipedia.org/wiki/Autopoiesis

[Vorhergehender Artikel] [Nächster Artikel] [Artikelserie]

Schießt Microsoft sich mit Windows Vista ins Aus?

Ein geschätzter Kollege hat mich auf Peter Gutmanns Analyse von Windows Vistas Content Protection Mechanismen ("A Cost Analysis of Windows Vista Content Protection") aufmerksam gemacht. Des Kollegen Stirn war dabei sehr gerunzelt und er sagte, er stelle sich nach Lektüre dieser Analyse ernsthaft die Frage, wie lange es für ihn noch tragbar sei, Windows einzusetzen und pro Microsoft zu sein.

Ich habe mir den Text dann auch angeschaut und versucht, eine klare Position für mich zu finden. Allein, ich finde es nicht einfach, aus dem, was Gutmann da beschreibt, eine klare pro oder contra Position abzuleiten. Insbesondere kann ich mich nicht wie mein Kollege ereifern. Hm... vielleicht bin ich ja aber auch nur naiv und kurzsichtig und kann die schwerwiegenden Implikationen für uns alle nicht erkennen?

Was Gutmann schreibt, ist vorderhand natürlich geeignet, auch mir einige Stirnrunzeln zu verursachen. Auch ich möchte bezahlten, digitalen Content (Videos, Musik, aber auch Texte) unzweifelhaft immer dann benutzen, wenn ich es möchte - und nicht der Gnade eines Betriebssystems ausgeliefert sein.

Aber... Digitaler Content ist halt wirklich etwas ganz anderes als ein Buch oder ein Auto oder ein Konzert.

Insofern sehe ich andererseits auch die schlichte Notwendigkeit, für etwas, das ganz anders ist als alles Bisherige, und viel Geld in er Produktion kostet, auch Wege zu finden, Umsatz zu generieren. Auf die Ehrlichkeit der Käufer zu hoffen, ist für mich da letztlich auch keine Lösung. Sorry, ich bin wohl insofern Pessimist.

Sind nun die Maßnahmen, die Windows Vista ergreift, um (bezahlten) digitalen Content zu schützen, d.h. nicht erworbene Nutzungsarten- und frequenzen zu verwehren, "gut"? Hat Microsoft den richtigen Weg eingeschlagen oder sich damit nun endgültig ins Reich des Bösen katapultiert?

Hm... Time will tell, würde ich sagen. Microsoft ist auch nur eine Firma, die die Konsequenzen ihres Handelns tragen muss. Wenn genügend Kunden Vistas Maßnahmen schlecht finden, dann werden sie wechseln - und Microsoft muss seinen Kurs anpassen und andere Anbieter werden profitieren. Jedem steht es frei, ein anderes Betriebssystem zu wählen. Da bin ich ganz leidenschaftslos. Welches Betriebssystem man wählt, ist das Ergebnis einer Güterabwägung.
Microsofts Entscheidung also für mich weder "gut", noch "böse". Ich werde Windows Vista aus anderen Gründen noch eine Weile nicht einsetzen.

Aber darum geht es mir hier nicht. In mir hat Gutmanns Analyse vielmehr unmittelbar das Gefühl hervorgerufen, dass sie am wesentlichen Punkt vorbeigeht oder etwas Entscheidendes außer Acht lässt.

So grimm Gutmanns Urteil auch ist und sich deshalb auch so fundamental, geradezu absolut und damit quasi automatisch "richtig" anhört... es ist dennoch ein Urteil, hinter dem Prämissen stehen. Allgemeine, individuelle, kulturelle, historisch gewachsenen Prämissen. Hinter Gutmanns Urteil steht damit auch eine Extrapolation nach dem Motto: "Wenn alles andere so bleibt, wie es ist, und Windows sich so entwickelt, dann wird die Welt schlechter."
Genau das aber halte ich für naiv. Es ist so naiv wie die Beschwörung einer Zeit, da uns das Öl ausgegangen sein wird. Denn: Der letzte Tropfen Öl wird nie gefördert - weil es zu teuer sein würde.

Nicht, dass man nicht negative Utopien denken dürfte oder gar sollte! Nein, sie sind wichtig. Sie lassen das (mehr oder weniger) Mögliche auf das Heutige wirken - verändern dabei aber das Heutige in einer Weise, dass das Mögliche (hoffentlich) eben nicht eintritt.
Wie aber genau es dann am Ende kommt, dass das einstmals Mögliche, das Visionierte eben nicht Realität wird, das ist im jeweiligen Jetzt ganz unklar.

So kann es sein, dass Gutmanns Kritik Microsoft einfach dazu bewegt, die Vista Schutzmechanismen abzuschalten. Das wäre dann der Erfolg von "Politik von unten" oder so. Die Macht des Anwendervolkes hätte dann etwas direkt beim Hersteller/Despoten ausgerichtet.

Aber es kann auch ganz anders kommen und auch ganz unabhängig von Gutmann. Und das ist eben das Gefühl, was sich mir beim Lesen aufgedrängt hat:
Gutmann hat eine entscheidende andere Entwicklung nicht im Blick. Sein Blick ist historisch gefärbt. Seine Prämisse lautet: Windows Vista und seine Nachfolger mit ihren Mechanismen zum Schutz digitalen Contents laufen auch in Zukunft auf general purpose PCs.
Mit dieser Prämisse sind die von ihm beschrieben Szenarien, in denen Krankenhausangestellte auf dem Tomographie-PC auch gekauft Musik hören wollen oder Schlachtschiffe, die durch Vista in ihrer Operation beeinträchtigt werden, eine düstere Aussicht.
Meine Vermutung ist jedoch, dass die Hardwareentwicklung (!) uns eine noch viel weitergehende Spezialisierung der Geräte bescheren wird, so dass es im Grunde keinen Konflikt mehr geben wird zwischen Funktionalität, die keine Beeinträchtigung durch Vista erfahren darf, und anderer, die beeinträchtigt werden kann, falls schützenswerter (weil bezahlter) Content Gefahr läuft, unerlaubt benutzt zu werden.

In meiner Vision der Zukunft hat der Krankenhausangestellte einfach kein Problem mit dem Krankenhausrechner, weil er seinen bezahlten Content auf einem Spezialgerät wie dem iPod abspielt. Der Krankenhausrechner zeigt dann alle Röntgenbilder ohne Beeinträchtigung - weil der Krankenhausangestellte ihn nicht mehr missbraucht.

Und das Schlachtschiff... dort existiert im operationskritischen Netzwerk einfach kein Content der Vista veranlassen könnte, die Funktionalität von PCs im Einsatz zu behindern.
Dasselbe gilt für den Home-Bereich. Wir werden soviele ausreichen preisgünstige verschiedenartige Geräte haben, dass uns die Beschränkungen von Vista oder anderen Betriebssystemen nicht mehr interessieren. Ich nehme mein Exemplar eines Buches mit ins Bett oder in den Zug oder aufs Klo. Darüber beklage ich mich nicht. Und ich werde in Zukunft meine eBooks auf den vielleicht 2-3 eBook Readern ohne Probleme herumschleppen können und wollen. Und meine Musik höre ich auch vom eBook Device oder einem sonstigen Spezialgerät - aber nicht mehr von dem Rechner, auf dem dann auch Visual Studio und .NET laufen und uneingeschränkten Zugriff auf alle Schnittstellen haben wollen.

In meiner Zukunft löst sich das Content Protection Problem zu einem großen Teil durch die weitere Spezialisierung der computing devices. Der PC hat seinen Zinit überschritten. Die general purpose Maschinen werden eben nicht mehr wirklich, wirklich alles tun können und sollen. Für schützenswerten Content werden wir Spezialgeräte haben wie heute das Handy oder den MP3-Player.

Mich graut also nicht so sehr vor Vista. Aber vielleicht bin ich ja doch naiv? Time will tell. Ich denke, weder Gutmann, noch mein Kollege, noch ich können am Ende wirklich vorhersehen, wie es denn kommen wird. Aber es gibt auch nicht nur die eine und negative Zukunft.

Schießt Microsoft sich also mit Vistas Schutzmechanismen ins Aus? So einfach, wie Gutmann es darstellt, ist das wohl nicht zu beurteilen.

Software als System I - Motivation

Alle reden von Objektorientierung oder Serviceorientierung – aber was ist Software eigentlich? Da gibt es Quellcode und Maschinencode… Aber Software ist ja nicht das eine oder das andere, sondern alles gehört irgendwie zusammen.

Ich finde dieses „Durcheinander“ zunehmend störend oder gar kontraproduktiv. Es kommt mir manchmal so vor, als würden unterschiedliche Parteien auch über komplett Anderes reden. Da bin ich als Moderator oder Diskussionsteilnehmer auf SOA-orientierten Veranstaltungen wie dem ASG Workshop oder dem CITT Expertengespräch und habe den Eindruck, das ist eine ganz, ganz andere Welt als die von Entwickerevents wie der prio Konferenz der dotnetpro oder der VSone. Als „normaler“ Entwickler ist es schwer, der Servicediskussion zu folgen – und die Vertreter der Serviceorientierung interessieren sich nicht mehr für die „Niederungen“ der „normalen“ Programmierung.

Wissenschafts- oder gesellschaftstheoretisch ist es natürlich verständlich, wenn Fachgebiete ab einer bestimmten Größe Regionen unterschiedlicher „Kultur“ und Sprache ausbilden. Ab einer bestimmten Größe zerfällt das Ganze in Teile, die dann unabhängig von einander weiterwachsen, und später wiederum zerfallen können usw… Jeder dieser Bereiche ist dann ein Spezialgebiet, das mit anderen Berührungspunkte hat, aber ansonsten eben etwas klar unterscheidbar Eigenständiges darstellt. Das hat in anderen Branchen womöglich Jahrhunderte gedauert, bei Software dauert es nur wenige Jahrzehnte und geht immer schneller.

Das ist kein aufzuhaltender, sondern ein ganz natürlicher Prozess. Man kann ihn aber bewusst erleben oder unbewusst. Man kann ihn begrüßen und nutzen oder unter ihm leiden. Ich versuche, ihn bewusst wahrzunehmen, soweit es mir möglich ist, und ihn nutzen bzw. mitgestalten.

Ein Ansatz dabei ist der Versuch, den entstandenen und entstehenden „Regionen“ der Softwarelandschaft (wieder) eine gemeinsame Grundlage zu geben. Ich möchte sie kommunikationsfähig halten. Die Entwicklung zu immer größerer Differenzierung ist nicht aufzuhalten und auch gut – aber darüber sollte nicht der gemeinsame Ursprung vergessen werden. Ich meine daher, dass es an der Zeit ist, einmal zurückzutreten von der Geschäftigkeit in den Spezialgebieten und zu überlegen, wie Software für eine möglichst große Gemeinschaft von Entwicklern definiert werden kann, um ein Ziel zu erreichen: ihre Planung und den Austausch über sie zu erleichtern.

Während meiner Beraterarbeit treffe ich ausnahmslos Entwickler mit Kompetenz in ihrer Fachdomäne, Kompetenz in der konkreten Programmierung einer konkreten Aufgabe – die sich aber mit der Planung oder Beschreibung von Software schwer tun. Objekte stecken ihnen im Blut; sie zeichnen Klassendiagramme und jonglieren mit Entwurfsmustern; sie können in Visual Studio Projekten denken, kennen Infrastrukturprodukte und APIs… Aber wie das alles zusammenhängt und ein Gesamtbild formt, davon haben sie wenig Vorstellung. UML & Designer aller Art helfen ihnen dabei auch nicht.

Es fehlt ihnen – so mein Eindruck – ein Grundgerüst. Und nicht nur ihnen! Denn auch ich fühle mich immer wieder überwältigt von der Vielfalt an Konzepten und Technologien in unserer Branche.

Insofern beginne ich hier eine Reihe von Postings unter der Überschrift „Software als System“ nicht einfach, um der Community etwas mitzuteilen, was ich schon meine zu wissen, sondern vielmehr für mich selbst. In dieser Postingserie möchte ich im Sinne Kleists daher eher schreibend mir selbst darüber klar werden, was ich denke und das zu verfeinern, als „gesichertes Wissen“ weiterzugeben.
Diese Serie stellt mithin den Versuch dar, quasi im Selbstgespräch ein allgemeines Bild von Software zu entwickeln. Mein Ausgangspunkt sind dabei Begriffe aus der neueren Systemtheorie, die ich versuchen werden, zum Nutzen der Softwareentwicklung auf unsere Branche zu übertragen. Mal schauen, was dabei herauskommt. Über Kommentare und Mitdenken von Bloglesern freue ich mich natürlich.

Die Leitfrage in den kommenden Postings ist also: Was ist Software eigentlich so ganz allgemein? Und wie kann uns das helfen, Software ganz konkret zu realisieren, ohne uns in einer babylonischen Sprach- und Denkverwirrung zu verlieren? Ich bin gespannt, auf was ich da so komme ;-)

[Nächster Artikel der Serie] [Alle Artikel]

Die BASTA! sagt basta! zur Sprecher-Community

Nun ist es wohl doch mehr als ein Beben, das da durch die deutsche Landschaft der Entwicklerveranstaltungen geht. Es klirren nicht nur die Gläser im Küchenschrank, es zeigen sich eher schon Risse in den Wänden. So muss es wohl zumindest der Software & Support Verlag als Veranstalter der BASTA! empfinden, denn er greift anlässlich der Frühjahrs-BASTA! 2007 zu einem rigorosen Mittel zur Profilierung seiner Konferenz:

Die BASTA! schließt Sprecher, die auch auf anderen Entwicklerveranstaltungen auftreten, aus ihrem Programm aus.

Zu diesen Sprechern zählen bekannte Namen wie Neno Loje oder Christian Wenz; aber auch ich bin bei der BASTA! abgelehnt worden aufgrund Mitwirkens bei einer anderen Veranstaltung. Im Detail sind die Begründungen, die aus mehr oder weniger offiziellen Quellen vom Veranstalter zu erfahren sind, zwar verschieden - unterm Strich jedoch ist die Aussage klar:

Die BASTA! will ihr Profil schärfen, sie will sich von anderen Veranstaltungen abheben. Das meint sie, nicht mit Sprechern tun zu können, die auf anderen Veranstaltungen auftreten. Also lädt sie diese Sprecher nicht mehr ein.

Sprecher werden also nicht aufgrund mangelnder Kompetenz oder nicht zur Konferenz passender Vortragsvorschläge abgelehnt, sondern weil sie ihre Kompetenz auch anderen Entwicklerveranstaltungen (erfolgreich) angeboten haben.

Welche "anderen Entwicklerveranstaltungen" einen solchen Ausschluss nach sich ziehen, wenn ein Sprecher dort auftritt, bleibt allerdings im Dunkeln. Bei mir war es das Engagement als Content Manager für die prio der dotnetpro. Bei anderen wohl andere Veranstaltungen in zeitlicher Nähe zur Frühjahrs-BASTA!.

Pointiert ausgedrückt sagt die BASTA! also zur Sprecher-Community: "Leute, es ist Schluss mit eurem 'Konferenztourismus'! Basta! Wer bei uns sprechen will, der muss sich nach unseren Regeln wohlverhalten und sollte aufpassen, dass er nicht mit den Falschen ins Geschäfts kommt."

Wer "die Falschen" allerdings sind... Wie "Wohlverhalten" genau aussieht... Dazu gibt es keine genaue Auskunft. Es heißt z.B., dass bei zukünftigen Vortragsvorschlägen mit anzugeben sei, bei welchen Veranstaltungen man soundsoviele Wochen vor oder nach einer BASTA! auch noch aufzutreten plane. Ob solche Auftritte dann aber Konsequenzen haben? Und welche Auftritte für wen welche Konsequenzen haben? Dazu gibt es keine allgemeine Aussage.

Soweit die Lage zur Behandlung der Sprecher-Community durch die BASTA!

Dazu habe ich folgende Gedanken:

Grundsätzlich bin ich für mehr Profil bei den Entwicklerveranstaltungen. Sprecher sollten sich mehr profilieren, die Veranstaltungen sollten sich klarer profilieren.

Ich tue das z.B., indem ich nicht mehr das Ziel habe, bei möglichst vielen Veranstaltungen zu sprechen. So war es früher einmal. Heute möchte ich bei weniger Veranstaltungen mehr bewirken. Eine dieser Veranstaltungen ist die prio. Eine andere war die BASTA! - aber das ist ja nun wohl vorbei.

Die prio als Veranstaltung profiliert sich durch ein anderes Konzept. Die Sprecherauswahl dort erfolgt nach Passgenauigkeit ihrer Kompetenz zum jeweiligen Fokusthema. Ob ein Sprecher dann auch schon auf der BASTA! oder VSone gesprochen hat... das ist egal. Er soll ein guter Sprecher sein und etwas Wesentliches zum jährlich wechselnden Konferenzthema zu sagen haben.

Ich sage also Ja! zur Veranstaltungsprofilierung - aber ich sage Nein! zum Versuch der Profilierung qua implizitem "Wettbewerbsverbot" für Sprecher. Meine Gründe:

1. Ich halte eine solche Politik für unpartnerschaftlich gegenüber Sprechern, die z.T. schon langjährig mit der BASTA! verbunden sind und viel Engagement gezeigt haben - auch wenn sie bei anderen Veranstaltungen engagiert waren. Christian Wenz z.B. war ja einstmals hoch geschätzt bei der BASTA! als Session Chair.

2. Eine Auswahl von Sprechern nach "Wohlverhalten" statt nach Kompetenz und Beliebtheit kann nicht zur inhaltlichen Qualität der Konferenz beitragen. Dass bei zwei gleich guten Sprechern zu einem Thema vielleicht einfach das "unverbrauchtere Gesicht" vorgezogen wird, kann ich verstehen. Dass bei ungleichen Sprechern zu einem Thema aber womöglich der schlechtere gewählt wird, weil der bessere sich nicht "wohlverhalten" hat, das (!) kann nicht im Sinne der Teilnehmer sein. Denen sind solche politischen Spielchen zurecht egal.

3. Schließlich halte ich die Ausschlusspolitik der BASTA! für realitätsverkennend. Sie ist Ausdruck eines Unverständnisses dafür, dass gute Sprecher meist nicht einfach so gut sind, sondern ihre Qualität jahrelanger Übung schulden. Diese Übung aber bieten ihnen häufigere Auftritte auf unterschiedlichen Veranstaltungen. Wer kann sich häufige Auftritte aber leisten? Die wollen ja auch vorbereitet sein. Die kann sich nur leisten, wer entweder bei einer (großen) Firma in Lohn & Brot steht, die ihm dafür den Freiraum gibt. Das sind beispielsweise die Angestellten von Technologieherstellern wie Microsoft. Oder das sind Profisprecher, die (auch) von den Auftritten leben.

Wenn nun letzteren angezeigt wird, dass sie nicht mehr sprechen dürfen, falls sie sich nicht "wohlverhalten", dann entzieht man den Guten einen Teil ihrer Lebensgrundlage - allemal, wenn man mit dem Sprecherhonorar knauserig ist. Das Resultat: Bekannte Sprecher mögen sich darauf einlassen - aber neue Sprecher werden es schwerer haben, sich zu Profis, zu guten Sprechern zu entwickeln.

Noch schlimmer aber: Wenn der Anreiz zu sprechen für "Freiwillige" geringer wird, dann entsteht mehr Raum für "Unfreiwillige", d.h. für die, deren potenter Arbeitgeber die Lücken füllen will. Und das sind... die Sprecher der Technologiehersteller. Wer ein "Wettbewerbsverbot" verhängt, leistet dem Verlust an unabhängiger Meinung Vorschub.

Ob der Anteil von 12,5% an Sprechern von Technologieherstellern, die die BASTA! in ihrer Sprecherliste führt, im Vergleich zu knapp 8% bei der VSone dafür schon ein Zeichen ist, weiß ich natürlich nicht. (Ich hoffe auch, dass ich richtig gezählt habe.) Aber es könnte eine Tendenz andeuten...

(Dass am Ende im Grunde die meisten Sprecher irgendein Interesse daran haben, "etwas" über den Inhalt ihrer Vorträge hinaus zu verkaufen, tut meiner Befürchtung einer Gefahr von weniger Unabhängigkeit keinen Abbruch. Denn wenn ein Sprecher seine Kompetenz demonstriert und man deshalb seinen Rat auch nach der Konferenz sucht, dann ist das in der Community akzeptiert. Der "Verkauf" des eigenen Produktes jedoch - also z.B. wenn ein Microsoft Sprecher über Microsoft Werkzeuge redet -, ist "ein ganz anderer Schnack" (wie wir in Norddeutschland sagen). Da ist die Community sensibler. Da sollte der Community zumindest klar gemacht werden, warum ein Vertreter eines Technologieherstellers spricht. Es kann und soll ja auch nicht vermieden werden; nur sollte es eben auch nicht politisch befördert werden.)

Ok, jetzt aber genug. Basta! auch für meinen Kommentar hier zur BASTA! Mir geht es hier darum, eine aus meiner Sicht ungute Entwicklung zu dokumentieren. Mit dieser Information kann nun jeder - Sprecher, Teilnehmer oder Veranstalter - für sich entscheiden, wie er sich der BASTA! oder anderen Veranstaltungen gegenüber verhält.

Die BASTA! hat eine neue Politik gewählt. Die BASTA! wird sehen, ob diese Politik ihr wirklich hilft, ein klareres, positives Profil zu bekommen, das ihre Teilnehmerzahl erhält oder vergrößert. Die BASTA! hat einen Kampf aufgenommen, den sie für nötig hält. Ich bin gespannt, wie sich die BASTA! im Speziellen und die Entwicklerveranstaltungslandschaft im Allgemeinen in der "Kampfzone" entwickeln.

Vorsorgliche Anmerkung:

Wer Kritik übt, gerät schnell unter Beschuss. So erwarte ich, dass man angesichts dieser Beschreibung der BASTA!-Politik auch auf mich sichtbar (oder unsichtbar) das Feuer eröffnen wird. Deshalb sage ich vorsoglich, um es wirklich ganz deutlich zu machen:

Ich bin zwar enttäuscht von der Behandlung durch den BASTA!-Veranstalter, aber diese Enttäuschung ist nicht mein Antrieb für dieses Posting. Ich hätte es auch geschrieben, wenn es nur andere Sprecher getroffen hätte. Bevor man mir meinen Ausschluss aufgrund mangelndem "Wohlverhalten" jedoch mitgeteilt hatte, waren für mich die Ausschlüsse anderer nur ein Gerücht. Jetzt habe ich sie aber verifiziert. Meine Darstellung ist daher gespeist aus einem Wunsch, diese nun gesicherte Information, die Einfluss auf die Community hat, auch der Community zu vermitteln.

Sollte allerdings meine Darstellung widererwarten aufgrund von Missverständnissen oder Fehlinformationen, denen ich ungewollte aufgesessen bin, Unmut erregen, so bitte ich, mir das einfach direkt und unverzüglich mitzuteilen oder hier im Blog einen Kommentar zu hinterlassen. Motto: Ein offenes Wort ist besser als ein offenes Bein.

In diesem Sinne freue ich mich auch auf einen Dialog mit Veranstaltern, die ein Interesse haben, der Community mit guten Inhalten und guten Präsentationen zu dienen.

OOP 2007: .NET Tag als Kickoff für mehr Industrialisierung – Teil 2

Die Softwareproduktion ist Teil des gesamten Softwareherstellungsprozesses wie auch die Softwareentwicklung [siehe Teil 1 dieser Postingserie]. Sie manifestiert und prüft die Artefakte der Implementation als letztem Schritt der Entwicklung.

Darüber hinaus hat sie aber weitere Aufgaben:

3. Variantenmanagement
Software ist ständig im Fluss. Softwareproduktion bedeutet daher nicht vielfache Produktion desselben Entwicklungsstandes, sondern Produktion von immer wieder Neuem. Im Grunde erzeugt die Produktion nur Unikate, denn bei jedem Produktionslauf unterscheiden sich die Artefakte mehr oder weniger vom vorherigen.

Im Sinne der Qualitätssicherung, aber auch der „Lieferfähigkeit“ ist die Softwareproduktion daher daran interessiert, darüber Buch zu führen, was sie wann produziert hat. Sie ist die Triebfeder eines Variantenmanagements, das alle transformierten Artefakte und die zugehörigen Qualitätsprüfungsergebnisse protokolliert. Nur so können Fehler in früheren Produkten nachvollzogen werden, wenn die Produktion schon wieder vorangeschritten ist. Nur so können auch frühere Produktionversionen nochmals produziert werden, wenn der Bedarf entsteht.

4. Deployment
Am Ende, wenn die Qualitätskontrolle zufriedenstellend durchgeführt wurde, muss die Produktion ihre Erzeugnisse natürlich noch verpacken. Kunden wollen ja nicht einfach eine CD voll mit transformierten Artefakten, sondern eine möglichst auf Knopfdruck laufende Software. Aufgabe der Produktion ist daher auch, aus allen Bestandteilen der Software ein Deployment-Paket zu schnüren, das es dem Kunden möglichst einfach macht, die Software in seine Infrastruktur zu integrieren und den Anwendern zur Verfügung zu stellen.

Zusammenfassung
Softwareproduktion ist heute weit mehr als ein Tastendruck in der Visual-Studio-Entwicklungsumgebung oder das Zustammenstellen eines Setups mit InstallShield o.ä. Softwareproduktion ist die Triebfeder für die Qualitätssicherung von Software:

• Prüfung der funktionalen Korrektheit im Sinne der Kundenanforderungen
• Prüfung der Erfüllung nicht-funktionaler Anforderungen durch den Kunden
• Prüfung des Betriebs der Software
• Sicherstellung der „Lieferfähigkeit“
• Sicherstellung der Weiterentwicklung

Diese stark gewachsene Bedeutung der Softwareproduktion ist noch wenig im Bewusstsein von Projektteams in der .NET-Softwareentwicklung verankert. Softwarequalität darf nicht länger eine Sache gutwilligen individuellen Bemühens überstrapazierter Entwickler sein. Softwarequalität muss zukünftig eine geplante und überwachte Eigenschaft von Software werden. Brennpunkt dafür ist die Softwareproduktion als Schnittstelle zwischen Entwicklung und Kunde. Ihre Ergebnisse sind es, die der Kunde zufrieden einsetzt – oder gefrustet kritisiert. Andere Branchen haben das schon lange begriffen; das Ergebnis ist die heutige industrialisierte Produktion von Gütern aller Art, an deren hoher Qualität wir uns alle täglich erfreuen. In diesem Sinne soll eine bewusste Softwareproduktion zu einer Industrialisierung der Softwareherstellung beitragen.

Deshalb schien es mir wichtig, den OOP .NET-Tag des Jahres 2007 auf dieses Thema zu fokussieren. Es ist überfällig in der breiten Diskussion.

OOP 2007: .NET-Tag als Kickoff für mehr Industrialisierung – Teil 1

In diesem Jahr beschäftigt sich der .NET-Tag der OOP am 23.1. mit dem Thema Softwareproduktion. Ist dieser Begriff aber nicht synonym mit Softwareentwicklung? Nein. Produktion „baut etwas zusammen“, Entwicklung plant das, was „zusammengebaut“ werden soll. Produktion manifestiert Entwicklung.

Verortung der Softwareproduktion
Der Begriff Softwareproduktion wirft insofern sogar ein kritisches Licht auf den der Softwareentwicklung, der für sich ja beansprucht, für alle Tätigkeiten zu stehen, die damit zu tun haben, aus Anforderungen Software „abzuleiten“ und dann am Ende auch an den Kunden auszuliefern. Früher hieß das schlicht Programmierung. Dann wurde daraus Softwareentwicklung. Diese begriffliche Veränderung scheint also kein Fortschritt, sondern trägt eher dazu bei, den Blick auf den ganzen Prozess zu trüben.



Als Track Chair für den .NET-Tag habe ich daher bewusst Softwareproduktion als Thema gewählt, um den Blick auf einen Teil des ganzen Softwareherstellungsprozess zu lenken, der gewöhnlich keine so große Aufmerksamkeit bekommt. In der Ausbildung stehen Entwurf und Implementation im Vordergrund. Es geht vor allem um Konzepte zur Beschreibung von Software und Technologie bzw. Werkzeuge für die Implementierung.

Historisch gesehen ist das auch verständlich. Aber die Zeiten haben sich gewandelt. Die Ansprüche an Software sind gestiegen und steigen immer weiter. Ebenso steigt ihre komplexität bzw. die der Infrastruktur, in der sie funktionieren muss. Wenn früher Entwicklung und Produktion noch zusammen betrachtet werden konnten, weil die Produktion nur einen kleinen, unliebsamen Teil in Form des Setups für eine Software darstellte, so ist es heute aber angezeigt, die Produktion als eigenständigen Zweig des Herstellungsprozesses herausvorzuheben. Dies ist ein für die Weiterentwicklung der Branche notwendiger Schritt zu mehr Systematik und auch mehr Industrialisierung, d.h. mehr verlässliche Qualität.

Und was ist Teil der Produktion? Die Produktion überführt die Implementation des Entwurfs einer Software in einen auslieferbaren „Zustand“. Die Produktion macht aus dem Ergebnis der Entwicklung etwas Anwendbares. Früher war es da im einfachsten Fall mit der Übersetzung von Quellcode getan. Diese Zeiten sind jedoch vorbei. In der Java-Welt ist man sich dessen schon länger bewusst – die .NET- oder Microsoft-Welt hinkt hier jedoch noch hinterher. Deshalb der .NET-Tag zum Thema Softwareproduktion.

Das Ergebnis der Entwicklung sind Quellcode und vergleichbare Artefakte wie Datenbankschemata. Die Entwickler können über sie nicht mehr sagen, als dass sie meinen (!), diese Artefakte würden die Anforderungen des Kunden erfüllen. Weder haben diese Artefakte aber schon eine Form, dass ein Kunde damit etwas anfangen könnte, noch ist ihre Qualität gewiss.

1. Transformation der Implementationsartefakte
Die erste Aufgabe der Softwareproduktion ist daher, alle Artefakte in die endgültige, beim Kunden zu installierende Form zu transformieren. Das haben die Programmierer für Quellcode während der Implementation zwar auch schon durchaus getan – aber aus Sicht der Produktion ist das relativ unwichtig. Sie will sich nicht darauf verlassen. Am Ende hat sie die Verantwortung für die Qualität der ausgelieferten Produkte, selbst wenn Fehler auf Mängel in der Entwicklung zurückgeführt werden können.

Die Transformation ist insofern eine erste, sehr grobe Qualitätskontrolle. Sie prüft nicht nur, ob die Artefakte an sich strukturell korrekt sind, sondern auch unabhängig vom Ort der Implementation transformiert werden können. Das ist wichtig, um den Ort der Implementation bei Bedarf wechseln zu können. Das trägt zur Agilität und Modularität der Entwicklung bei.

2. Qualitätsprüfung der Produkte
Die zweite Aufgabe der Softwareproduktion besteht dann in der Prüfung der Artefakte. Halten Sie, was sie laut Entwicklungsplan versprechen? Die Softwareproduktion ist damit die Instanz, deren Tests am Ende des Tages wirklich zählbe. Ob Softwareentwickler während der Implementation getestet haben oder nicht… Es ist gut, wenn sie es tun und nur aus ihrer Sicht fehlerfreie Artefakte der Produktion übergeben. Aber die Produktion kann sich darauf nicht verlassen. Es ist letztlich ihre Verantwortung, die „Tragfähigkeit“ der Software im Einsatz zu garantieren.

Allerdings kann die Produktion diese Verantwortung nur durch Mithilfe von Entwicklung und Support wahrnehmen. Denn die Qualitätsüberwachung von Software ist keine Sache einmaliger Prüfung, sondern muss vorbereitet werden und erstreckt sich auch auf den produktiven Einsatz. Darüber hinaus gilt es auch, nicht nur die Erfüllung der Anforderungen an den Betrieb sicherzustellen. Die Softwareproduktion ist ja nicht nur daran interessiert, heute ein qualitativ hochwertiges Produkt auszuliefern. Sie will auch sicherstellen, dass diese Qualität morgen und übermorgen noch genauso hoch ist. Die Softwareproduktion ist damit die Triebfeder eines umfassenden Qualitätsmanagements, das auch die Organisation der Artefakte und des Entwicklungsteams im Blick behalten muss.

Mehr im nächsten Posting...

Wer hören kann, ist klar im Vorteil

Gerade habe ich ein Blogposting meiner, hm, "Mitphilosophin" Ina Schmidt gelesen, in dem Sie in durchaus poetischen Worten, das Hören preist oder zumindest ins Bewusstsein hebt. (Mit Ina treffe ich mich regelmäßig zum "philosophischen Diskurs" in einem hamburger Kaffeehaus - sozusagen Kaffeehausphilosophie, statt Kaffeehauskonsultation ;-) - und wir arbeiten daran, einen totalen Bestseller zu schreiben. Natürlich zum heißen Thema Philosophie, ist ja klar. Aber mehr kann ich noch nicht verraten...)

Also, Ina lobt das Zuhören und ich habe sofort das Gefühl gehabt, dass das auch irgendwie relevant für die Softwareentwicklung ist. Aber wie...? Dann ist es mir aufgefallen: In der Softwareentwicklung hat Zuhören keinen so großen Stellenwert wie in anderen Branchen.

Oder genauer: Nicht nur das Zuhören, sondern allgemeiner das Rezipieren, das Aufnehmen, das Auf-sich-wirken-lassen. Denn die Softwareentwicklung beginnt mit dem Produzieren - und ist stolz darauf. Ein Programmierkurs ist gelungen, wenn die Teilnehmern möglichst schnell etwas produziert haben. Man soll Code schreiben lernen - nicht lesen.

Damit ist die Softwareentwicklung wohl quasi symptomatisch für einen großen pädagogischen bzw. didaktischen Trend. Denn in den Schulen steht ja heute der Ausdruck der Kinder im Vordergrund. Kinder sollen lernen, sich zu äußern, sich zu produzieren. Es geht wider den Stubenhocker und stillen Duckmäuser! Nicht nur der Befehlsempfänger als ultimativer Rezipient ist out, schon das schlichte Zuhören ist out. Belege dafür sind auch die unzähligen Fernsehshows, in denen sich jeder quasi nach Belieben produzieren kann. Die letzten Zuhörer sind die Moderatoren; ihre Aufgabe ist aber nicht das partnerschaftliche Zuhören, sondern die Lenkung (oder gar Provokation) der Produktion.

Unsere Gesellschaft ist also eine geworden, in der der Ausdruck, die Selbstproduktion im Vordergrund steht. Und die Softwareentwicklung hat das zum Credo in ihrer Ausbildung erhoben.

Relevant wird das nun, wenn man schaut, woran es bei der Softwareentwicklung hakt: nämlich bei der Kommunikation. Die Kommunikation mit dem Kunden ist immer wieder schwierig. Aber auch im Team ist´s nicht immer leicht. Und dann beim Support.

Meine These: Diese Schwierigkeiten haben damit zu tun, dass das Rezipieren in der Softwareentwicklung von Anfang an einen so geringen Stellenwert hat. Code lesen, Kunden zuhören, Anwendern lauschen, Literatur studieren... das wird nicht gelehrt.

"Code Reading" ist das einzige Buch, das ich kenne, das sich mit dem Lesen von Code beschäftigt. Allen anderen geht es ums Schreiben.

Natürlich soll und muss Code geschrieben werden. Softwareentwickler sollen Produzenten sein. Klar. Sie werden nicht nur für´s Zuhören bezahlt; sie sind ja keine Therapeuten oder Beichtväter.

Insgesamt aber, scheint mir, ist die Waagschale des Produzierens zu schwer. Es sollte etwas mehr Gewicht auf die andere Waagschale gelegt werden. Zuhören, aufnehmen, rezipieren sollte auch explizit geübt werden.

Warum? Nicht aus philosophischen Gründen oder Gutmenschtum. Rezipieren, d.h. aktives Aufnehmen und nicht passives "auf Durchzug schalten" ist einfach die andere Seite der Medaille bei der Interaktion lernender Systeme mit ihrer Umwelt.

Lernende Systeme - einzelne Menschen oder auch Organisationen - sind auf ständige Interaktionen mit ihrer Umwelt angewiesen, um "auf Kurs zu bleiben". Im Sinne des Konstruktivismus müssen sie ständig ihr internes Modell von der Umwelt überprüfen, um ihre "Passgenauigkeit" (Viabilität) zu erhalten. Lernende System müssen handeln (Produktion) und dann wahrnehmen, was passiert (Rezeption). Immer und immer wieder. Je größer der Wandel in der Umwelt, desto häufiger müssen diese Interaktionen stattfinden.

Wer dann aber vor allem nur handelt und nicht gleichzeitig auch rezipiert, auf Feedback lauscht, der lernt nichts dazu. Der geht von einem Modellstand aus und festigt ihn mit jeder Handlung, da er Feedback, welches dem Modell widersprechen könnte, nicht wahrnimmt.

Je weniger das Rezipieren in der Softwareentwicklung also Thema ist, desto schlechter lernen Softwareentwickler und Projektteams - vor allem aus "menschlichen Feedbackquellen". Deshalb kann ich Inas Ermunterung zum Zuhören nur zustimmen. Lernen wir alle besser zuhören, besser aufnehmen, empfangen. Ich bin sicher, dass sich dadurch die Beziehungen zu Kunden und Kollegen nur verbessern können - und der Projekterfolg leichter zu erringen ist.

Schenken wir mehr Aufmerksamkeit...

Aber halt, das Thema "Schenken" behandle ich lieber ein andermal.

Vom Konzept der Konzeptkonferenz

Ein Beben geht durch die deutsche Entwicklerkonferenzlandschaft. Es ist nicht, noch nicht sehr stark, es klirren nur die Gläser, es zittert der Boden nur ein wenig, aber es ist merklich. Heute habe ich es z.B. wieder gemerkt, als ich mit dem Veranstalter einer großen deutschen Entwicklerkonferenz telefoniert habe. Das Symptom: die Aufregung um den Begriff "Konzeptkonferenz", den ich für die prio Konferenz der dotnetpro benutzt habe.

In einem Posting hatte ich vom Erfolg der prio als "erster Konzeptkonferenz" gesprochen. Das stieß meinem telefonischen Gesprächspartner und seinem Stab auf. Und auch einem Kommentar zu meinem Posting hatte ich schon Empörung über diesen Begriff entnommen.

Sicherlich kann man über die Eignung des Begriffs diskutieren (s.u.), aber die Sensibilität mit der er aufgenommen wurde, die Heftigkeit, mit der er zurückgewiesen wurde, das sind für mich Symptome für ein zumindest leichtes Beben in der Konferenzlandschaft. Es wird eben enger. Man muss sich mehr anstrengen für den Erfolg seiner Veranstaltung. Die Zeiten, als die BASTA! in den 1990ern so ziemlich allein auf weiter Flur war, sind vorbei. Und da wo es enger wird, da reagiert man dann halt feinfüliger, wenn man etwas hört, was scheinbar am eigenen Image kratzt.

Denn das ist die Empfindung der Kommentatoren des Begriffs "Konzeptkonferenz": Er kratzt am Image anderer Veranstaltung, weil er scheinbar anderen Veranstaltung ein Konzept abspricht. Wer will schon konzeptlos sein?

Nun, da mir heute wieder dieses Missverständnis entgegengeschlagen ist, scheint es angezeigt, doch noch ein Wort über den Begriff zu verlieren. Ich hänge einfach an ihm, weil ich ihn schlicht weiterhin passend finde. Also, was meine ich mit "Konzeptkonferenz"?

Für mich steht "Konzeptkonferenz" als zusammengesetzter Begriff in der Nähe von "Konzeptalbum" und "Konzeptkunst". Diese Begriffe sind seit langem etabliert und keiner hegt Zweifel an ihrer Bedeutung oder Sinnhaftigkeit. "Konzeptalbum" drückt nicht (!) aus, dass hinter anderen Alben kein Konzept stünde. Und "Konzeptkunst" spricht anderer Kunst nicht ab, auch ein Konzept zu haben.

Diese Begriffe sind insofern idiomatisch und nicht einfach durch eine Zerlegung in ihre Bestandteile zu erklären: Konzeptkunst = Kunst mit Konzept, Konzeptalbum = Album mit Konzept.

So einfach ist es nicht. So einfach machen es sich aber die Kritiker des Begriffs "Konzeptkonferenz". Sie hören, was sie wollen. Sie meinen, ich wollte sagen: "Die prio ist die erste Konferenz mit einem Konzept." Aber das habe ich nicht gesagt und das will ich nicht sagen. In meinem früheren Blogposting und einem Kommentar habe ich das auch deutlich gemacht.

Konzeptkonferenz != Konferenz mit Konzept. Diese "Übersetzung" ist zu einfach. Ein solcher linguistischer Kniff funktioniert halt nicht immer so, wie man es gerne hätte. Was wäre denn sonst ein "Radiorecorder"? Ein Recorder der Radios aufnimmt? Nein, auch das ist zu einfach.

Wikipedia sagt, ein Konzeptalbum sei ein Album, "bei dem die einzelnen Titel nicht isoliert sondern in ihrer Beziehung zu den anderen Teilen des Albums als Gesamtwerk betrachtet werden."

In Anlehnung daran ist für mich eine "Konzeptkonferenz" eine Konferenz, bei der die einzelnen Vorträge nicht isoliert, sondern in ihrer Beziehung zu den anderen als Gesamtdarstellung zu einem Thema betrachtet werden.

Sind TechEd oder BASTA! oder VSone nach dieser Definition Konzeptkonferenzen? Nein. Haben diese Konferenzen deshalb aber auch kein Konzept? Doch, natürlich.

Das Verständnis für den Begriff liegt in "ihrer Beziehung zu den anderen als Gesamtdarstellung". Nur weil eine Konferenz sich auf .NET konzentriert oder auch ein Teilthema wie TFS oder SQL Server, wird sie nicht gleich zur Konzeptkonferenz. Es kommt darauf an, wie mit dem Inhalt umgegangen wird. Wird ein offener oder geschlossener Call-for-Papers abgesetzt und man wählt dann halt so aus den Einreichungen aus. Man nimmt letztlich, was man kriegen kann? So verfahren TechEd & Co. Das ist ihr Konzept - aber sie sind deshalb keine Konzeptkonferenzen.

Denn für eine Konzeptkonferenz muss noch etwas hinzutreten: Die Vorträge müssen zu einem Ganzen, das größer als die Summe seiner Teile ist, zusammengefügt werden. Erst dann ergibt sich eine "Gesamtdarstellung". Die einzelnen Vorträge müssen in Beziehung stehen, auf einander Bezug nehmen, miteinander verzahnt werden.

Wo das Oberthema eines von vielen Tracks bei einer Konferenz vielleicht lautet "WCF" und Vorträge dann nur unterschiedliche Aspekte beleuchten, fehlt einfach die Gesamtdarstellung. "Contract-first Design für WCF-Anwendungen" und "Session Managemant mit WCF" und "Datastreaming mit WCF" ergeben zusammen einfach keine "Gesamtdarstellung", nichts, das größer ist als die Summe seiner Teile.

Dazu braucht es einen Bogen, der gespannt wird, und dessen Bausteine die einzelnen Vorträge sind. Und genau diesen Bogen hat die prio gespannt. Sie hat ein Oberthema - Softwareproduktion - definiert und genau spezifiziert, welche Unterthemen zu diesem Oberthema zusammengebaut werden sollen. Das große Ganze war klar und geplant, die Einzelteile waren klar und geplant. Das hat das Marketing dann auch "durchkomponiert" genannt.

Solche Planung gibt es bei TechEd oder BASTA! oder VSone aber nicht. Das gibt´s zwar einzelne Track-Themen, aber was dann in den Tracks gesagt wird, soll keinem "Plan" jenseits von "Das ist cool!" oder "Das hat noch keiner gesagt!" oder "Das ist strategisch wichtig zu sagen!" folgen.

Ist das schlimm? Kritisiere ich das? Nein. Das ist ok. Das ist auch ein Konzept. Aber das Resultat ist eben keine Konzeptkonferenz nach obiger Definition. Das Resultat ist dann "nur" eine Konferenz mit Konzept. Und das Konzept habe ich (durchaus nett und mit nostalgischem Anklang gemeint) als "Ein Kessel Buntes" bezeichnet.

Ist das so schwer zu begreifen? Vielleicht ja, wenn man sensibel für das Beben des Bodens unter den eigenen Konferenzbeinen ist.

Das tut mir dann leid. Ich möchte ja niemanden mit einem solchen Begriff verschrecken. Aber andererseits kann ich auch nicht helfen. Dinge, die anders sind - wie die prio im Vergleich zur TechEd oder BASTA! oder VSone -, die sollten auch einen anderen Namen bekommen. Nichts anderes habe ich mit "Konzeptkonferenz" tun wollen. Dem Kind einen griffigen Namen geben.

Ruf doch mal an! - Beratung jetzt auch per Telefon

Ich bin schon ein paar Mal darauf angesprochen worden, ob man meine Beratungsleistungen nicht auch online oder per Telefon nützen könne? Online, d.h. per Email ist das natürlich noch nie ein Problem gewesen. Ich beantworte Fragen über dieses Medium jederzeit gern. Viele haben das auch schon genutzt. Diese Fragen sollten - allemal, wenn sie unvorbereitet kommen - nur einen gewissen Rahmen nicht sprengen; dann ist die Beantwortung selbstverständlich kostenlos.

Manche Themen sind jedoch größer und erfordern mehr Einsatz, als "eben mal" eine Email zu beantworten. Manche Themen lassen sich auch nur schwer in eine Email verpacken. Das gilt für den Fragenden und/oder mich als Antwortenden. Muss dann so eine Frage deshalb aber unbeantwortet bleiben? Oder muss dann gleich ein "richtiger" Beratungstermin vor Ort vereinbart werden?

Nein, das ist nicht (mehr) nötig. Aufgrund mehrerer Nachfragen in der letzten Zeit biete ich jetzt ganz offiziell meine Leistungen auch per Telefon/Skype an, Motto: Call a Consultant. Das hat viele Vorteile:

• Sie können die Kosten für solche Beratungs-/Coaching-Leistungen viel besser steuern. Sie müssen nicht in ganzen Tagen denken, die Sie unsere Zusammenarbeit aus Ihrem Projekt reißt, sondern können Termine viel kürzer und damit kostengünstiger halten. Allemal fallen keine Reisekosten an.
• Sie können die Beratungstermine viel flexibler planen: in kleineren Zeithappen, aber auch kurzfristiger. Telefonische Treffen von 1, 2, 3 Stunden lassen sich meist in einem Zeitraum von wenigen Tagen ab Anfrage einrichten.
• Wir können die Zeit zwischen Fragen und Antworten problemangemessener gestalten. Bei einem vor-Ort-Termin steht der Berater immer unter Druck, noch während des Termins eine Antworten/Lösungen zu präsentieren. Mit guter Vorbereitung ist das zwar oft möglich - aber eben nicht immer. Manchmal ergeben sich Probleme erst während des Termins und erfordern wieder einige Zeit des Nachdenkens oder der "Forschung". Das kostet dann Zeit, die nicht eingeplant wurde. Ein telefonischer Termin entzerrt die Situation jedoch. Darin lassen sich viel einfacher "Pausen" einlegen, die beide Seiten für "Stillarbeit" bis zum nächsten Termin nutzen können.

Nicht verschweigen kann ich natürlich auch den Vorteil für mich, dass Telefontermine einfach bequemer sind. Ich muss keine weite Reise antreten, ich muss nicht versuchen, verschiedene Kunden terminmäßig auf einer Reiseroute zu koordinieren.

Andererseits gibt es selbstverständlich aber auch Nachteile bei telefonischer Beratung: Insbesondere wenn wir uns noch nicht kennen, ist das Gespräch weniger persönlich. Die Kommunikation kann eher ins Stolpern geraten, weil man den anderen schlechter einschätzen kann. Ein telefonisches Gespräch reduziert einfach die "Kanäle", auf denen wir Botschaften senden. Das gilt auch für Darstellungen und Beispiele. Auf einem Flipchart kann man bei einem vor-Ort-Treffen schnell für alle sichtbar etwas skizzieren, auf einem Laptop am Beamer schnell mal für alle sichtbar etwas codieren. Das ist via Telefon schwierig.

Aber mit etwas gutem Willen und ein wenig Technik kann man diese Hürden auch nehmen. Da bin ich optimistisch und habe auch schon gute Erfahrungen mit einigen Partnern und Kunden gesammelt. Mit einer Webcam kann der Ton um ein Bild ergänzt werden. Mit Desktop Sharing und Chat kann man ein telefonisches Gespräch um visuelle Kanäle erweitern.

Damit liegt "Telefonconsulting" noch nicht gleich auf mit persönlichen Treffen, doch es ist so einfach und nützlich, dass ich es nun gern anbiete. Die Technologien sind da, die Nachfrage ist da. Warum also nicht.

So wichtig das "traditionelle" Beratungsgeschäft, d.h. mit Terminen vor Ort auch ist, so denke ich doch, dass Leistungen per Telefon und Internet einfach zeitgemäß sind. Sie bieten Flexibilität und geringere Kosten - und sind auch noch ökologisch positiv.

Ich freue mich also darauf, der Community zukünftig vermehrt auch "aus der Ferne" via Telefon und unterstützt durchs Internet mit Rat und Tat zur Seite zu stehen. Call your Consultant...

Die ersten Kaffeehauskonsultationen: das hat Spaß gemacht

Am 29.11. und am 8.12. habe ich meine ersten Kaffeehauskonsultationen in München und in Hamburg gegeben. Ich hatte diese Idee eines "Schnupperconsultings" in meinem Blog angekündigt - und hatte alle Hände voll zu tun.

In München - einer der Entwicklerhochburgen in Deutschland - hatte ich von 10h bis 18h ununterbrochen Klienten in meiner "mobilen Beratungspraxis" im Café Eisbach. Eigentlich hatte ich gedacht, zwischen den Terminen immer mal wieder mein Laptop aufklappen zu können, um weiter an einem Bericht zu schreiben. Aber Pustekuchen: Die Besucher gaben sich quasi die Klinke in die Hand. Sogar die dotnetpro berichtete davon auf einer Community-Seite in Heft 1/07.

In Hamburg war es dann etwas ruhiger - aber was wollte ich auch von der ".NET-Diaspora" erwarten. Hier aber zumindest mal eine Impression vom Gespräch mit Herrn Schmäu, der extra aus Berlin angereist war!

Er war der letzte Klient des Tages und ich musste wg. eines Folgetermins recht pünktlich um 17h los - aber wir haben 90min intensiv über seinem Problem gesessen und eine Lösung gefunden. Herr Schmäu kam mit einem Modellierungsproblem - es galt ein verteiltes System zu entwerfen - und ich habe auf der Basis von Softwarezellen und Contract-first Design in kleinen verständlichen Schritten sein System modelliert. Er hatte es vorher schon selbst versucht, war aber in ein paar Missverständnissen stecken geblieben. Zusammen konnten wir die schnell auflösen. Und Herr Schmäu hat einen Packen Papier mit Entwurfszeichnungen zurück zu seiner Firma nehmen können. Er sagt, eine Reise ins schöne Hamburg, die sich definitiv gelohnt hat. Kaffeehauskonsultation macht´s möglich.

Angesichts des Andrangs und des positiven Feedbacks werde ich natürlich auch in 2007 wieder Kaffeehauskonsultationen anbieten. Eine Terminübersicht wird es auf meiner Homepage geben. Für eine Push-Information über neue Termine lohnt sich aber natürlich das Abo des Feed für mein Blog :-)

Bis zum nächsten Mal, wenn es wieder heißt: Schnupper-Consulting im Kaffeehaus!

Willkommen im One Man Think Tank

So, jetzt habe ich es endlich geschafft und mir ein deutschsprachiges Blog angelegt.

Mein bisheriges Blog - http://weblogs.asp.net/ralfw - gilt weiterhin, aber dort werde ich mich in Zukunft auf englischsprachige Postings beschränken. Alles andere sorgt immer für Unwillen der internationalen .NET Bloggergemeinde, die den weblogs.asp.net Hauptfeed beobachten.

Hier bei blogspot fühle ich mich nun endlich frei, nach Herzenslust für den deutschsprachigen Raum zu schreiben - in dem die Mehrzahl meiner Freunde, Bekannten und Kunden sitzt. Das werden dann Gedanken zur Softwareentwicklung im Allgemeinen oder der .NET-Softwareentwicklung im Speziellen sein - aber vielleicht auch mal ganz anderes. Mal schauen...

Erstmal fühle ich mich hier mit einem frischen Blog sehr wohl. Los gehts...

Ralf Westphal, Hamburg
www.ralfw.de

PS: Auch in einem anderen Blog werde ich noch schreiben, dem Blog des Professional Developer College (www.prodevcollege.de). Da geht es dann um das große Thema Aus-/Weiterbildung und Personalauswahl. Ein Abonnement des Feeds von http://prodevcollege.blogspot.com lohnt sicht bestimmt ;-)