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]