Die Zukunft der IDEs ist hier - Intentional Programming [OOP 2009]

Vor 4-5 Jahren hatte ich die Zukunft schon einmal gesehen. Damals auf der SD West Konferenz in Los Angeles. Jetzt wieder - aber dieses Mal im Internet. Sie scheint nun auch nicht mehr in so weiter Ferne zu liegen. Die Zukunft der IDEs ist für einige nämlich schon hier. Intentional Software - die ambitionierte und geradezu geheimnisvolle Firma von Softwarepionier Charles Simonyi - hat schon die ersten Releases ihrer Intentional Domain Workbench hinter sich. Bisher ist in deren Genuss allerdings nur ein kleiner Kreis von Anwendern gekommen.

Nach Jahren der eher verschlossenen Türen und vorsichtigen Äußerungen sucht Intentional Software nun jedoch vermehrt den Kontakt zur Entwicklergemeinde, wie es scheint. Selbst auf einer so kleinen Konferenz wie der SET 2009 war Charles Simonyi mit seinen Mitarbeitern, um ihre Vision von der Softwareentwicklung der Zukunft vorzustellen.

Das Bild oben skizziert, worum es geht: Software ist nurmehr eine abstrakte Beschreibung einer Problemlösung, die viele Darstellungen haben kann. Sie ist sogar so abstrakt, dass ihre "wahre Form" in der IDE nicht direkt bearbeitet wird. Für Visual Studio ist Software letztlich der Quelltext, den wir schreiben. Für die Intentional Domain Workbench ist es hingegen ein interner Baum. Und diesen Baum projiziert die Workbench als ganzes oder in Teilen so, wie es für den Anwender am besten passt. Programmierer sehen ihn z.B. als C#- oder Ruby-Code, Domänenexperten als Tabelle oder Graph oder Diagramm.

Und wo ist der Unterschied zu den domänenspezifischen Sprachen samt Werkzeugen wie Oslo, die gerade en vogue sind? Wo ist der Unterschied zum Model Driven Development?

Die Schnittmenge ist natürlich die domänenspezifische Darstellung. DSLs, MDD, Intentional Software bringen das Programm näher an den Domänenexperten. Der Transfer von Formulierungen in der Domänensprache in einem Anforderungsdokument in Code soll leichter werden. Oder noch besser: Domänenexperten sollen im Idealfall selbst programmieren.

Dass das möglich ist, haben Tabellenkalkulationsprogramme wie Excel schon für viele Problemdomänen gezeigt. Vor Excel bzw. VisiCalc mussten Anwender entweder den Taschenrechner bemühen oder ihre Kalkulationen Programmierern erklären, die sie dann z.B. in C oder Fortran umgesetzt haben. Heute greift der Domänenexperte selbst zu Excel oder - um ein anderes Beispiel zu nennen - MATLAB.

In ihrem Lösungsansatz für die "Domänenprogrammierung" unterscheiden sich DSLs, MDD und Intentional Software jedoch. Die Intentional Domain Workbench profiliert sich dabei aus meiner Sicht durch zweierlei:

• Abstrakte Repräsentation: Der Quellcode von Software hat nichts mehr mit einer Ausführungsplattform oder Problemdomäne zu tun. Er ist wirklich abstrakt, also nicht mehr textuell.
• Perspektivenvielfalt: Quellcode soll auf viele verschiedene Weisen im Ganzen oder in Ausschnitten dargestellt und bearbeitet werden können. Alle Sichtweisen sind gleichberechtigt. Quellcode kann daher auch gleichzeitig verschiedene Problemdomänen repräsentieren.
• Fließende Darstellung: Die vielen Perspektiven auf den Quellcode fließen in der Workbench umeinander. Sie müssen sich nicht zwischen der einen oder der anderen entscheiden, sondern können nebeneinander oder ineinander immer wieder anderen Perspektiven einnehmen.

Schauen Sie sich einmal dieses Video einer Präsentation der Workbench an. Für einen schnellen Eindruck von der Dynamik dieser visionären IDE empfehle ich allerdings den Download der WMV-Datei; spulen Sie darin vor bis zu Minute 14. Da gehts los mit der Demo, aus der die Screenshots oben stammen. Bis zu Minute 45 ist dann die Zukunft der IDEs schon auf Ihrem Desktop. Seien wir gespannt, wann sie schließlich als öffentliche Beta materialisiert. Aber warten Sie nicht darauf! Intentional Software hatte schon viel Zeit und wird wohl auch noch weiter Zeit haben. Man scheint auf Qualität bedacht statt Hype. Eine wohltuende Haltung in Zeiten sich überschlagender CTPs.

SET 2009 CCR Beispiele

Gestern auf der SET 2009 in Zürich habe ich einen Vortrag über die Concurrency Coordination Runtime (CCR) von Microsoft gehalten. Leider standen mit nur 45min zur Verfügung :-( Dennoch glaube ich, dass die Botschaft, die Zukunft liege bei asynchronen Komponenten, um Multicore Prozessoren auszureizen, bei den Teilnehmern angekommen ist. Der Raum war jedenfalls voll und alle schienen am Ende zufrieden. Vielleicht waren sie aber auch nur noch benommen vom Codefeuerwerk, dass ich abgebrannt habe? ;-) Denn ich habe neben 1-2 Flipchartblättern nur Code mit CCR-Beispielen gezeigt. Den gibts hier auch zum Download. Da asynchrone Programmierung für viele neu ist, mögen die Konstrukte auf die Schnelle nicht immer einfach zu verstehen gewesen sein, auch wenn ich mich auf die CCR-Grundlagen beschränkt habe. In jedem Fall freue ich mich, dass am Ende noch 10 Minuten "Überziehungszeit" war, um auch noch die transparente Verteilung von CCR-basierten asynchronen Komponenten demonstrieren. Denn: Wer schon lokal asynchron programmiert, hat es viel einfacher, skalierbare verteilte Architekturen aufzusetzen.

Werbung in .NET-Fachblättern

Wieviel Werbung steckt eigentlich in unseren .NET-Fachblättern? Bei Lektüre der aktuellen Ausgabe des dot.net Magazins ist mir irgendwie aufgefallen, dass da viele Events des Verlags beworben wurden. Das schien mir rein gefühlsmäßig ungewohnt. Also hab ich mal Werbefläche gezählt:

• dot.net Magazin 6/2009: Auf 100 Seiten inkl. Umschlag finden sich da ca. 24 Seiten Werbung unterschiedlicher Größe. Das sind 24% des Heftumfangs. Davon sind 17,8 Seiten Werbung für Verlagsprodukte (Zeitschriften, Bücher, Trainings, Events), also 74%.
• dotnetpro 5/2009: Auf 150 Seiten kommen 23,15 Seiten Werbung (15%), davon 11 für Verlagsprodukte (48%).

Einen solchen Unterschied in Umfang und Art der Werbung hätte ich nicht erwartet. Was können wir daraus aber ableiten?

Zunächst einmal ist zwar die dotnetpro mit 12,70 EUR pro Heft im Abo teurer als das dot.net Magazin für 7,49 EUR - aber der Preis pro werbefreier Seite ist gleich: 0,10 EUR.  Zwar kostet die Seite im dot.net Magazin nur 0,07 EUR, bei der dotnetpro jedoch 0,08 EUR - aber das dot.net Magazin enthält eben anteilig mehr Werbung. Deshalb liegen sie bei den "Nutzseiten" wieder gleichauf. Wer sich zwischen den Magazinen entscheiden muss, sollte sich also nicht vom Preis auf dem Umschlag irritieren lassen.

Dann ist die Werbung im dot.net Magazin zu fast 75% selbstbezüglich. Wer ein dot.net Magazin in der Hand hat, erfährt durch Werbung vor allem etwas über andere Produkte des dot.net Magazins bzw. des Unternehmens dahinter. Das ist aus Verlagssicht vielleicht erstmal eine gute Sache. Doch als Leser bin ich - wenn Werbung denn schon da ist (und ja: sie muss auch sein) - an Vielfalt interessiert. Dass ein Unternehmen allein meine Bedürfnisse erfüllen kann, ist wenig wahrscheinlich. Die dotnetpro bietet da mehr; ihre Anzeigenverkäufer sind erfolgreicher. Woran das liegt? Vielleicht an der Abonnentenzahl (8130 in Q1/09 bei der dotnetpro vs. 3557 beim dot.net Magazin, s. www.ivw.de)?

Schließlich - das war der Ausgangspunkt meiner Auszählung - ist es interessant zu sehen, dass das dot.net Magazin so stark für Veranstaltungen wirbt: 56% der Anzeigen ist darauf konzentriert (dotnetpro: 30%). In Zeiten des Internets hat offensichtlich die persönliche Anwesenheit wieder einen hohen Stellenwert erreicht. Woran mag das liegen? Ich denke, weil persönliche Anwesenheit eben doch mehr bringt als nur im stillen Kämmerlein zu lesen. Und weil sich für persönliche Anwesenheit leichter Geld verlangen lässt als für Lektürestoff.

Tja... und nun? Was mache ich mit diesen Erkenntnissen? Es gibt keinen Handlungsbedarf. Aber ich freue mich, dass ich meinem Gefühl trauen konnte. In der Werbung der .NET-Fachblätter hat sich etwas verändert. Schauen wir mal, wie es weitergeht.

PS: Jetzt habe ich nochmal in meinen Schrank gegriffen und zwei andere Magazine "ausgezählt". Als Zusammenfassung eine Tabelle:

Interessanterweise hat die amerikanische Zeitschrift keinen höheren Werbeanteil als die deutschen. Aber vor allem ist das CoDe Magazine dasjenige mit der geringsten Eigenwerbung, obwohl es ausdrücklich als "Kompetenzdemonstration" des Softwarehauses EPS Software gedacht war.

Auch gehen höhere Kosten pro werbefreie Seite nicht notwendig mit weniger Werbung insgesamt einher, wie das Objektspektrum beweist.

Unterm Strich ist das Feld dennoch recht dicht: Bei Zeitschriften-Fachpublikationen auf Papier müssen Leser einen Preis von ca. 0,1 EUR pro werbefreie Seite bezahlen. Fachbücher wie "Programmieren mit C#" oder "Refactoring" liegen mit 0,08 EUR bzw. 0,09 EUR scheinbar darunter, bieten pro Seite aber viel weniger Inhalt. Eine Buchseite enthält ca. 2.500 Zeichen, eine Zeitschriftenseite mehr als 6.000. Auf Zeitschriftenseiten normiert kosten Buchseiten daher ca. 0,20 EUR, sind also knapp doppelt so teuer wie Zeitschriftenseiten. Und das, obwohl das Buchlayout tendenziell einfacher ist. Es wird wohl daran liegen, dass Bücher "werbefreie Zonen" sind.

Und jetzt die Masterfrage: Wieviel würde der Inhalt online kosten? Wieviel wären wir bereit, dort zu zahlen? Nur 0 EUR wie üblich? Oder könnte eine dotnetpro auch 8.000 Abonnenten online haben? Einen Seitenpreis gäbe es dann zwar nicht mehr, aber vielleicht einen Artikelpreis. Ein dotnetpro-Artikel hat im Schnitt 5 Seiten, schätze ich mal. Er kostet auf Papier also werbefrei 0,50 EUR. Würden wir ihn für vielleicht 0,30 EUR auch im Internet lesen in einem online Abo? Oder würden wir lieber 0,75 EUR bezahlen und dafür eben nur die Artikel lesen, die uns wirklich, wirklich interessieren? Ähnliches gilt für Bücher und ihre Kapitel.

Ich denke, das sind Fragen, an denen die Verlage nicht mehr vorbeikommen. Vielleicht gibt es doch Handlungsbedarf?

Manifestierte Softwareentwicklung [OOP 2009]

Die Softwareentwicklung hat ein neues Manifest, das Manifesto for Software Craftsmanship:

Nach dem Manifesto for Agile Software Development [dt.] meint "man" offensichtlich, noch einen Schritt weitergehen zu müssen. Die "Software-Handwerker" nehmen den Ball der Agilisten auf und schlagen ihn bewusst zurück. Die "linke Seite" ihrer Grundsätze (z.B. "working software") entspricht der "linken Seite" bei den Agilisten. So entsteht nun eine dreistufige Wertehierarchie:

Prä-Agil	Agil	Handwerklich/Post-Agil
Ausführliche Dokumentation	Funktionierende Software	Handwerklich gute Software
Befolgen eines festgelegten Plans	Mut und Offenheit für Änderungen	Stetiger Wertzuwachs
Prozesse und Werkzeuge	Individuen und Interaktionen	Professionelle Gemeinschaft
Vertragsverhandlungen	Stetige Zusammenarbeit mit dem Kunden	Produktive Partnerschaft

 

Früher war der Fokus also z.B. auf ausführlicher Dokumentation. Darüber haben die Agilisten funktionierende Software gesetzt: Was nützt die beste Dokumentation, wenn am Ende die Software nicht befriedigt? Und darüber setzen nun die "Software-Handwerker" wiederum handwerklich gute Software. Denn was nützt funktionierende Software, die zwar läuft, aber nur zusammengezimmert ist und bei der ersten Belastungsprobe Probleme macht?

Im Craftsmanship-Manifest heißt es zwar "but also" statt "over" wie im Agile-Manifest, d.h. die handwerklichen Werte stehen nicht unbedingt höher als die agilen. Doch letztlich ist das eine Feinheit, denke ich. Wenn über den Grundsätzen der Software-Handwerker "Raising the bar" steht, setzen sie ihre Werte höher als die der Agilisten an, weil sie den umfassendsten Anspruch formulieren:

Das hört sich gut an. In Zeiten, da Softwarequalität schon für tot erklärt wird, ist jede Bemühung um mehr Qualität - denn um nichts anderes geht es den Software-Handwerkern - zu begrüßen.

Und dennoch... Irgendwie mag ich mich nicht vorbehaltlos über diese Form "manifestierter Softwareentwicklung" freuen. Warum? Ich glaube, es liegt an zweierlei:

• Die Form des Manifestes hat für mich gerade auch durch die direkte Bezugnahme auf das agile Manifest einen Beigeschmack. Da schwingt für mich Me-Too-Denken gemischt mit Neid und Kränkung und Hang zur Theatralik mit. Für mein Empfinden sind die Kopie der Form und die Bezugnahme daher kontraproduktiv trotz allem "but also" stat "over".
• Der Inhalt des Handwerker-Manifestes verliert aus meiner Sicht bei allem Willen zum Gegenteil den Kontakt zur Hauptperson: dem Kunden. Als Kunde interessiere ich mich nicht dafür, ob ein Softwareentwickler eine Handwerker- oder Ingenieursattitüde hat. Er soll gefälligst gute Software abliefern. Wie er das macht... egal. Er hat es schließlich gelernt. Oder? Folgt man aber den Diskussionen in der amerikanischen Software-Craftsmanship Gruppe, dann geht es eher um das "rechte Leben als Handwerker" als um Wege zu mehr Kundenzufriedenheit. Erste Softwareentwickler sind sogar schon zusammengezogen. Pair Programming scheint nun nicht mehr zu reichen.

So liegt für mich die Qualität des neues Manifests deutlich hinter der seines Vorgängers. Die Agilisten haben in ihren Grundsätze Aussagen darüber gemacht, was ihrer Meinung nach bessere Software bzw. einen besseren Produktionsprozess ausmacht: funktionierende Software statt "Gerede über Software", die Fähigkeit des Teams zum Umgang mit der Realität häufiger Änderungswünsche, flüssige Kommunikation im Team, enger Kontakt zum Kunden. Das ist knackig. Das lässt sich in seiner Effektivität messen.

Die Software-Handwerker hingegen formulieren schwammig. Sie werfen Fragen auf, wo angesichts lauter Klagen über die Softwarequalität konkrete Antworten nötig wären:

• "Handwerklich gute Software" klingt gut - aber wie lässt sich die handwerkliche Qualität messen? "Funktionierende Software" ist demgegenüber leicht erkennbar.
• "Stetiger Wertzuwachs" bei der Software ist eine gute Sache - aber wie geht das über eine agile Praktik wie das Scrum Backlog hinaus, bei dem der Kunde jederzeit selbst bestimmt, was für ihn wertvoll und daher als nächstes zu realisieren ist? Die agile Offenheit für Änderungen steht im Gegensatz zu Planbefolgungswahn. Der Nutzen, den Agilität behauptet, ist klar zu erkennen. Aber "Wertzuwachs" ist demgegenüber schwach.
• Was bringt eine "Professionelle Gemeinschaft" dem Kunden? Oder ersteinmal: Wer ist überhaupt Mitglied in der Gemeinschaft? Die Softwareentwickler unter sich? Oder das Team zusammen mit dem Kunden? Wo die Agilisten den Menschen ins Bild holen, addiert aus meiner Sicht die "community of professionals" nichts hinzu. Jedenfalls nichts, was erstens messbaren Vorteil böte oder zumindest für den Kunden verständlich wäre.
• Und schließlich die Frage, was an einer "produktiven Partnerschaft" neu ist? Das agile Manifest formuliert wieder klar einen Gegenentwurf: früher verschanzen hinter einmal abgeschlossenen Verträgen, heute stetige Kommunikation. Partnerschaft ist dazu kein Gegensatz und auch kein großer Schritt voran. Allemal, weil Partnerschaft niemandem aufgezwungen werden kann. Will der Kunde ein Partner sein? Die Agilisten lassen die Frage unbeantwortet und begnügen sich mit Realistischerem: kommunikativ engere Kopplung.

Allesinallem empfinde ich also das neueste Manifest der Softwareentwicklung als gut gewollt - aber zu kurz gesprungen. Eine Not zur Herausforderung der Agilitätsbewegung bestand nicht. Aber wenn schon Herausforderung, dann bitte auch "Butter bei die Fische" und nicht Herumgeeiere.

Bemühungen um mehr Softwarequalität und mehr Professionalität in der Softwareentwicklungen sind wichtig. Es ist höchste Zeit dafür. Clean Code Developer soll da nicht allein stehen. Die Software-Craftsmanship-Bewegung ist ja auch schon älter und will im Grunde dasselbe. Eigentlich. Nicht umsonst ist Robert C. Martin Teil beider Schnittmenge. Aber es ist schade, wenn eine Bemühung sich in romantischen Vorstellungen einer Handwerkerzunft ergeht und dann als weit sichtbare öffentliche Geste nur ein Remake eines Erfolgsschlagers zustande bringt.

Getting Things Done - ganz anders und ganz einfach [OOP 2009]

Ja, auch ich habe den Zeitmanagement-Klassiker "Getting Things Done" ("Wie ich die Dinge geregelt kriege") von David Allen gelesen. Und ich habe daraus auch etwas gelernt:

1. Habe einen (!) Platz, an dem du alle Aufgaben bzw. Hinweise darauf, sammelst.
2. Nutze diesen Platz konsequent und regelmäßig, um die nächste Aufgabe "abzuholen" bzw. zukünftige Aufgaben zu hinterlegen.
3. Erledige Kleinstaufgaben sofort, plane größere Aufgaben ein.

Ziel dieser Praktik sind mentale Entlastung und Kontrolle. Aufgaben, die man nicht gerade erledigt, sollen die Konzentration im Hier und Jetzt nicht behindern. Äußere Umstände beherrschen nicht, sondern werden durch aktive Planung beherrscht.

That´s it.

Mehr hat mir David Allen nicht gebracht - außer einem schlechten Gewissen, sein ausgefeiltes System nicht genauso ausgefeilt zu benutzen.

Naja, in einem Punkt habe ich es noch angepasst: Wo er empfiehlt, "Abteilungen" für Aufgaben anzulegen, die mit bestimmten Orten oder Gelegenheiten zu tun haben (z.B. "Wenn ich das nächste Mal beim Faxgerät bin"), da nutze ich diese Orte selbst. Habe ich eine Aufgaben, die mit dem Faxgerät oder dem Lebensmitteleinkauf zu tun haben, dann lege ich mir Aufgabenzettel genau dorthin, also zum Faxgerät und zur Wohnungstür (durch die ich zum Einkauf gehe). So "stolpere" ich über meine Aufgaben. Ich muss sie also nicht im Hinterkopf halten.

Ansonsten aber... da grüble ich eher darüber nach, was mich an David Allens gutgemeinten Ratschlägen stört. Und meine Erkenntnis ist inzwischen:

"Getting Things Done" (GTD) ist keine Lösung, sondern ein Symptom.

Das Buch ist ein Symptom für eine Kultur oder auch nur Arbeitshaltung, in der man soviel "auf dem Zettel hat", dass man überhaupt ein ausgefeiltes System braucht, um es zu bewältigen. Es scheint geradezu eine Tugend zu sein, sich soviel aufzuladen, dass man sich nur mit modernen Hilfsmitteln organisieren kann. Eine Aufgabenliste, ein Kalender, eine Wiedervorlagemappe oder auch (im fortgeschrittenen Stadium) eine Assistenz reichen nicht mehr. Nein, es muss ein mehrdimensionales Verwaltungs- und Erinnerungssystem sein.

Seit ich das erkannt habe, geht es mir besser. Ich brauche GTD nicht. Ich brauche nur Mut, mein Leben/meine Arbeit so einfach zu halten, dass ich gar nicht erst in eine organisatorische Überlastungssituation komme. Wenn ich an soviel denken muss, dass ein simpler Kalender und eine Aufgabenliste nicht mehr reichen, dann (!) habe ich ein Problem. Denn dann bin ich sehr wahrscheinlich auch so unter Druck, dass mir als Softwareentwickler schlicht Spielräume fehlen und der Raum für Kreativität begrenzt ist.

Dass GTD mir dann ja gerade helfen würde, diese Räume wieder zu eröffnen durch gute Planung... nun, das halte ich für eine Empfehlung wie "Putz die Zähne öfter, damit die ganzen Süßigkeiten ihnen nicht schaden."  Hier ist die Wurzel des Übels ein übermäßiger Zuckerkonsum, dort ist es eine Hypertrophie des Verantwortungsbewusstseins. Denn nur wer sich für viele Dinge verantwortlich fühlt, der hat auch viele Aufgaben, um diese Dinge geregelt zu kriegen.

Die wahre Lösung des Problems, mit dem sich GTD beschäftigt, lautet daher: Reduktion und Delegation. Weniger tun müssen und/oder andere an der Bewältigung beteiligen.

Wenn die zu regelnden Dinge soviel werden, dass man überhaupt merklich Zeit für ihre Regelung aufwenden muss, wenn also auch die Regelung zu regeln ist... dann ist Gefahr im Verzug. Soviel mal zur Abwechslung ins Stammbuch der ewig geschäftigen Manager geschrieben - zumindest derjenigen, die sich über ihre Aufgabenlast bewusst beklagen oder körperliche/psychische Symptome der Überlastung zeigen.

GTD hat nun einen Platz bei mir im Schrank als Mahnung, mich nicht von den Dingen beherrschen zu lassen und in eine Situation zu kommen, wo ich sie mit "normalen Mitteln" nicht mehr im Griff habe.

So freue ich mich auch, dass es Literatur gibt, hinter denen ein anderes Menschenbild steht und die aus der Regelung von Dingen nicht noch eine weitere, umständlich zu erwerbende Kompetenz machen. Wer bisher an GTD geglaubt hat, der versuche es doch mal zur Abwechslung mit einer anderen Einstellung:

oder ganz simplen Werkzeugen, die sich viel eher auch von Fall zu Fall einsetzen lassen:

Ein bisschen Papier in Form von Notizblock, Notizbuch oder Post-It Zetteln reicht oft in Kombination mit dem Willen zu Überschaubarkeit von Verantwortlichkeiten und Aufgabe von Kontrolle.

Die Dinge geregelt kriegen ist dann ganz einfach. Viel einfacher, als GTD meint.

Code bubbling - Von der Software zur Schaumware

Was passiert mit Code unter Druck? Er wandert ins UI. Das ist eine Erfahrung, die ich gerade in der letzten Zeit immer wieder gemacht habe. Wenn ich mir Code in Projekten oder auch in Übungsaufgaben ansehe, dann findet der sich in umso größerer Menge im UI oder UI-nah, je höher der (Termin)Druck im Projekt ist. Wie Bläschen in der Limo wandert er nach oben in die Präsentationsschicht (wenn man in Schichten denken will).

Ist ja auch klar: Wo keine Zeit ist, da fehlt Muße zum Denken. Ohne Denken, keine Planung. Ohne Planung, keine Vorstellung darüber, wie Code organisiert sein könnte.

Die einzige Struktur die zwangsweise jedoch immer vorhanden ist, ist die Struktur des UI. In Ermangelung von Alternativen trägt man also Code in die durch das UI vorgegebenen Strukturelemente (Steuerelemente) ein.

Das UI wird damit quasi zur Blume der Software: Dort schäumt der ganze Code, für den man in Ermangelung anderer Strukturelemente grad keine Zeit hatte, einen geeigneteren Ort zu finden.

Aber wie mit dem Schaum im Glas ist es schwer, den Code im UI in tiefere Schichten zu drücken. Ist er erstmal dort oben, dann bleibt er dort auch. Der Schau auf dem Bier verschwindet irgendwann zwar von allein, die Codeblasen im UI jedoch nicht. Und je länger der Druck im Projekt anhält, desto mehr Code, der eigentlich tiefer angesiedelt sein sollte, blubbert nach oben.

So ist es denn kein Wunder, dass manche Software eigentlich Schaumware (neudeutsch: foamware) ist.

Schade . Denn zumindest minimale Strukturen unterhalb des UI zu finden, in und an denen Code auch unter Druck geeigneter und vor allem leichter testbar aufgehängt werden kann, ist gar nicht so schwer. Sogar mit ein bisschen "mechanischem" Separation of Concerns ist da schon einiges zu erreichen. Denn eines ist gewiss: Code in einem Eventhandler eines Steuerelementes ist nie eine gute Sache, wenn der Code nicht unmittelbar mit dem Steuerelement oder seinen "Geschwistern" im UI zu tun hat.

Prost!

Blaues Wunder VSone 09

Das war sie wieder, die VSone 2009, die Frühjahrsentwicklerveranstaltung von ppedv. In München, am gewohnten Ort im Forum des Deutschen Museums - aber mit viel mehr Teilnehmern als in den letzten Jahren! Knapp 500 sollen gekommen sein. Es war eine gemütliche Atmosphäre in der Kinolobby unter dem ehemaligen IMAX-Kino.

Das Vortrags- und Workshop-Programm war gewohnt vielfältig, die Sprecherriege gemischt. Aus dem fernen Seattle war aber sogar Chris Sells angereist, um Microsofts Oslo vorzustellen.

Wer allerdings geglaubt hatte, zwei Tage lang eine ruhige Kugel bei Technologievorträgen schieben zu können, der erlebte sein blaues Wunder! Am Abend des ersten Konferenztages gab es kein Halten mehr: die Karneval-Narren waren los. Ja, sogar in München. Neno Loje, mich, Jürgen Kotz und Christian Wenz traf es wie alle anderen Teilnehmer. Auf der Abendveranstaltung galt "Hutpflicht":

Entschädigt für diese "Verunstaltung" unserer Charakterköpfe wurden wir dann jedoch zum Glück durch schmissige Darbietungen der Tanzgruppe des Karnevalsvereins Dorfen. Soviele Frauen waren bisher selten zu sehen auf Entwicklerveranstaltungen ;-)

Diesermaßen motiviert, waren die restlichen zwei Tage dann eine Kleinigkeit. Die Teilnehmer konnten sogar meinen Vortrag über die Concurrency Coordination Runtime (CCR) ohne Powerpoints ertragen und waren am Freitag von 9h bis 17h superaufmerksam in meinem Workshop zum Thema Anwendungsarchitektur und Parallelprogrammierung. Als im Workshop dann auch noch die Premiere des Xcoordination Application Space tadellos lief, war ich endgültig überzeugt von der VSone als gelungener "Kessel Buntes" Veranstaltung für .NET Entwickler und Sharepoint-Profis.

Beispielcode und Flipchart-Fotos des Workshops können hier heruntergeladen werden: http://www.ralfw.de/download/VSone09Workshop.zip. Es ist auch eine Vorabversion des Application Space dabei. Dessen Zweck ist es, Anwendungen sehr, sehr einfach von synchronen lokalen Komponenten über asynchrone lokale bis zu verteilten asynchronen Komponenten zu skalieren. Der Application Space ist Architekturinfrastruktur, die es wesentlich einfacher machen soll, in die Multi-Core- und Multi-Tier Programmierung einzusteigen. Aber davon ein andermal mehr.