UI-first Design ganz ohne schlechtes Gewissen

Endlich sagt es mal einer deutlich: Softwareentwicklung beginnt beim UI. Jeff Atwood spricht es in seinem Coding Horror Blog deutlich aus: Programmierung ist "UI-First Software Development".  Zwar wussten wir das irgendwie schon seit 17 Jahren - aber es ist gut, wenn es endlich auch mal jemand so deutlich sagt. Microsoft hat es uns zwar im Grunde nie anders demonstriert - von VB 1.0 bis WPF, AJAX und Silverlight. Aber ein Unbehagen blieb dennoch. Denn seit mindestens 10-12 Jahren gibt es auch genügend Stimmen, die immer wieder mahnen, dass das UI nicht so wichtig sei, dass man damit doch nicht die Softwareentwicklung beginnen solle. Ja, ja, ja... aber... hm...

Diese Unsicherheit löst sich auf, wenn wir das unselige Akronym RAD ersetzen durch RUID. Denn was VB 1.0 und Delphi und WinForms und Expression usw. bieten, ist nicht Rapid Application Development. Rapidly kann man damit zwar arbeiten - aber RAD war nie (!) dazu gedacht, bei der Architektur zu helfen. Design von Strukturen - denn dafür könnte das D in RAD auch stehen - war nie Sache der RAD-Tools. Nur das visuelle Design, die Oberfläche war gemeint. Eigentlich. Doch dann hat jemand zwischen R und D ein A für Application gesetzt und damit das Kind in den Brunnen geworfen. Bei RAD sollte es um alles gehen, um ganze Anwendungen.

Damals mögen Anwendungen vielleicht noch entweder so simpel gewesen sein, dass man keine weitere Struktur gebraucht hat als die, die sich durch Platzierung von Steuerelementen und Auswahl ihrer Events ergab. Oder Anwendungen waren doch kompliziert, wobei das wirklich Komplizierte sich jedoch in einem DB-Server abspielte und nicht weiter vom Entwickler "designt" werden musste. Was blieb war der (kleine) Anteil der Applikation, mit der der Benutzer interagiert.

Letztlich ist es aber einerlei. RAD für mehr als eine Hilfe beim Entwurf des Aussehens (!) einer Anwendung anzusehen, war immer schon falsch oder zumindest ein Missverständnis. Und das wurde eigentlich auch relativ bald bemerkt. Dadurch geriet dann RAD bzw. das UI in Verruf. Schade. Denn in einer Hinsicht hatte die missverstandene RAD-Botschaft Recht: Das UI muss am Anfang der Softwareentwicklung stehen. Ja, "muss", denn das UI ist ein Kontrakt.

UI-first für den Kunden

Jeff bringt es auf den Punkt: "Remember, to the end user, the interface is the application." Für den Kunden ist Software vor allem durch das UI greifbar. Von dem, was dahinter steht, hat er noch weniger eine Vorstellung als von dem, was hinter einem Armaturenbrett ein Auto wirklich ausmacht. Wo aber Unwissen herrscht, da ist Unsicherheit nicht weit. Und Unsicherheit ist wiederum der beste Nährboden für Konflikte. Wer also Konflikten aus dem Weg gehen möchte, der versuche nicht, den Kunden über die Interna der von ihm bestellten Software aufzuklären. Solche Wissensvermittlung kommt schnell an ihre Grenzen und interessiert den Kunden auch nicht wirklich. Er empfindet sich als vom Wesentlichen ablenkende Belehrung. Viel effektiver beugen Sie Konflikten vor, indem Sie mit dem Kunden darüber reden, wozu er einen unmittelbaren Bezug hat: das UI.

In einem Projekt möglichst früh mit dem Kunden ausführlich über das UI zu sprechen, ist aber nicht nur eine vertrauensbildende Maßnahme und beugt Konflikten vor, sondern hat darüber hinaus konkreten Nutzen. Die Arbeit am UI definiert nämlich den wesentlichen Kontrakt zwischen Mensch und Software. Ohne hohe Usability ist alle grundsätzlich vorhandene Funktionalität nutzlos. Das werden Sie bestätigen, wenn Sie schon einmal in einem Land waren, dessen Sprache Sie nicht beherrschten, und dort in einem guten Restaurant speisen wollten. Solange das Restaurant die Menükarte nicht in einer Ihnen verständlichen Sprache bereitgehalten hat, war sein guter Service für Sie nutzlos oder zumindest nicht kontrollierbar. Die Usability des Restaurants war bei aller Qualität seiner "Funktionalität" niedrig.

Damit Ihrem Kunden das nicht mit Ihrer Software passiert, sollte UI-Design am Anfang der Implementierung stehen. Um den Aufwand dafür klein zu halten, hat Jeff dafür z.B. Papierprototypen vorgeschlagen:

Quelle: Jeff Atwood, www.codinghorror.com

Ob Sie nun aber Papier benutzen oder Powerpoint oder Visio oder andere Demowerkzeuge, das ist egal. Hauptsache der Kunde bekommt möglichst früh das Gefühl, das am Ende Ihrerer Arbeit wirklich benutzbare Software herauskommt. Und Sie bekommen möglichst schnell ein Gefühl dafür, was der Kunde wirklich will. Denn Kunden können meist nicht gut abstrakt beschreiben, was Sie sich wünschen. Dafür sind sie jedoch sehr gut darin zu erkennen, ob etwas so ist, wie sie es sich vorgestellt haben. Mit einem UI-Prototypen nun geben Sie Ihrem Kunden etwas zum Erkennen. Die Software wird für ihn greifbar. Und das auch noch sehr früh und für Sie quasi ohne Risiko.

UI-first Design reduziert also Konfliktpotenzial, dient dem Verständnis beider Seiten, was eigentlich zu erreichen ist, verspricht höhere Usability und reduziert den Frust durch Änderungen später im Software-Lifecycle. Damit aber nicht genug...

UI-first für den Entwickler

Der Nutzen von UI-first Design reicht über Vertrauensbildung, Anforderungsverfeinerung und Usability-Steigerung hinaus. Wichtig beim UI ist nämlich nicht nur das Aussehen und die grundsätzliche Dienstleistung, wichtig sind die Trigger, der Event-Fluss, die konkreten Funktionen, die ein Benutzer anstößt. Das UI ist nicht nur ein Kontrakt mit dem Kunden, der menschenlesbar beschreibt, was wie getan können werden soll mit einer Software. Das UI ist auch ein maschinenlesbarer Kontrakt innerhalb der Software. Genau wie ein Kontrakt zwischen zwei Komponenten:

Während ein "normaler" Komponentenkontrakt allerdings meistens aus Interfaces besteht, definiert den UI-Kontrakt meist ein WinForms-Formular. Seine Eventhandler-Methoden beschreiben die Funktionalität eines Dialogs. Interaktionen mit dem Benutzer finden immer über solche Methoden statt, die der Benutzer durch Tastendrücke oder Mausaktionen oder auch Spracheingabe triggert.

Was eine Service-Komponente nun für Funktionen bieten sollte, bestimmen ihre "Kunden". Im vorstehenden Bild ist der "Kunde" von M die Komponente L. Der Kunde von L ist K, der von K... ist der Benutzer. Die Funktionalität von M, ihre Funktionen sind damit mittelbar abhängig vom... Benutzer. Wenn Sie effizient arbeiten wollen, d.h. nicht potenziell unnötige Funktionalität in M implementieren möchten, dann tun Sie gut daran, die Kontraktdefinition nicht mit M zu beginnen, sondern mit L, nein, mit K, also dem UI. Denn aus den Funktionen des UI ergibt sich erst, welche Leistungen K von L benötigt. Und daraus ergibt sich erst, welche Leistungen M bieten muss. Lean Software Development entwickelt nur das, was unbedingt nötig ist. Das aber finden Sie heraus, indem Sie Ihren Entwurf beim Benutzer mit dem UI beginnen.

Dafür ist eine gestaltungsorientierte Darstellung wie sie Jeff sie skizziert hat eigentlich schon zu detailliert. Vor allem ist sein Bild zu statisch. Es zeigt nur einen Schnappschuss des Zustands eines UI. Funktionalität im Sinne von "Was kann ich jetzt tun?" ist daraus nur mühsam ablesbar.

Deshalb sollten Sie beim UI-first Design nicht nur über die Gestaltung sprechen, sondern auch die Interaktionsmöglichkeiten explizit festhalten. Welche Funktionen stehen einem Anwender zur Verfügung? Das Programm von Jeff erlaubt einem Anwender anscheinend, sich zu authentifizieren und etwas zu suchen. Der rote Login-Dialog liegt allerdings nur platt auf der Suchmaske. Welche Trigger dieser Kontrakt bietet, ist nicht zu erkennen. Hier zwei Beispiele, wie die Skizze von Jeff verstanden werden könnte:

Der "maschinenrelevante" Kontrakt des UI besteht danach vor allem aus den Funktionen:

• Open() des Hauptfensters bzw. des Login-Dialogs
• Login() für die Anmeldung
• Search() zum Suchen

Mit diesen Funktionen (für ein K) in der Hand kann nun die Frage gestellt werden, welche Funktionen nachgeschaltete Komponenten (wie L und M) bieten sollten.

Ohne ein explizites UI-Design würde solche Überlegung viel schwerer fallen. Sie müssten dafür quasi in die Glaskugel blicken. Sie könnten nur spekulieren, was von einer Komponente wie M oder L gefordert sein könnte. Das ist bottom-up oder inside-out Entwicklung, die leicht zu sehr allgemeinen Lösungen führt - und damit unnötig ineffizient ist.

Outside-in, d.h. beim UI beginnend, kommen Sie zu Kontraktdefinitionen mit minimal nötiger Funktionalität. Das ist produktiv.

UI-first Design dient nicht nur weichen Faktoren wie Usability oder Vertrauen, sondern harter Architektur. Wenn Sie mit dem UI beginnen, müssen Sie in Zukunft also kein schlechtes Gewissen mehr haben. Allerdings sollten Sie auch nicht mehr tun, als hier beschrieben. Das UI ist nicht die Applikation, sondern die Applikation hat nur eine dünne UI-Schale.

Mehr Warum statt Wie - Vom Wert der Informationen aus erster Hand [OOP 2008]

Was macht eigentlich den Einstieg in neue Technologien oft so schwierig? Ja, da ist natürlich immer ein Zeitproblem. Unter Projektdruck sich auch noch mit Neuem zu beschäftigen, ist schwierig. Aber wenn wir davon einmal absehen, nur für einen Moment... denn Projektdruck macht ja alles schwierig.

Also: Was macht den Einstieg in Neues oft schwierig? Ich glaube, es liegt daran, dass die, die das Neue verkünden, sich zuwenig Zeit für das Warum nehmen. Sie sind viel mehr daran interessiert, das Wie darzustellen. Die Gründe dafür sind vielfältig: Das Wie ist schillernder, positiver, als das Warum, bei dem ja immer das Problem mitschwingt. Das Wie ist womöglich auch leichter zu verstehen und/oder zu vermitteln. "So geht das mit ADO.NET!" ist doch viel simpler als "Das sind die Probleme beim Datenbankzugriff bisher und in naher Zukunft, deshalb muss der neue Weg folgende Eigenschaften haben..." Und schließlich will das Publikum doch eh nur das Wie kennen, um endlich mit dem Neuen auch besser zu werden - oder?

Das sind alles plausible Gründe, so scheint mir, warum wir immer mehr vom Wie hören, statt vom Warum. Aber ist das denn auch gut? Nein. Das Neue - die nächste Datenzugriffstechnologie und das nächste Kommunikationskonzept usw. - erfordert ja immer Veränderung. Bisheriges muss zugunsten des Neuen aufgegeben (oder zumindest verändert) werden. Bei Veränderungen wollen Menschen jedoch ein Wörtchen mitreden. Sie wollen sich nicht herumkommandieren lassen. Sie wollen verstehen, sie wollen abwägen, sie wollen es sacken lassen, sie wollen auch selbst entscheiden können.

Wer da aber vor allem das Wie predigt, ignoriert diese Bedürfnisse. Das Wie transportiert nur versteckt das Warum und behindert somit das Verständnis. Das Wie lässt keinen Raum für Alternativen und beschneidet somit den Wunsch nach Entscheidungsspielräumen. Und so bietet das Wie wenig Wachstumanreiz für die Motivation zur Veränderung.

Wer zu Veränderungen anregen will, der beginne also immer mit dem Warum, mit dem Problem. Je klarer er das Problem kommunizieren kann, je mehr Verständnis für das Problem im Publikum ist, desto wirksamer später die Präsentation der Problemlösung, des Neuen. Das ist mir gerade auch nochmal bei Lektüre von "The Art of Change" deutlich geworden.

Vor einiger Zeit hatte mich diese Erkenntnis allerdings schon einmal umgetrieben; damals war sie allerdings noch etwas dumpfer, intuitiver. Da habe ich nämlich überlegt, was mir in der Ausbildungslandschaft fehlt. Wie würde ich gern etwas lernen? Wie würde ich z.B. in eine Evaluation eines Konzeptes oder einer Technologie einsteigen? Und die Antwort auf diese Fragen war: Ich möchte natürlich am Ende das Wie erfahren, aber ich möchte vor allem zuerst mehr über das Warum erfahren.

Wenn ich schon mehr zu einem Konzept oder einer Technologie hören möchte, dann habe ich zwar schon ein grundsätzliches Problembewusstsein. Sonst würde ich ja keinen Drang verspüren, etwas darüber zu lernen. Aber ist mein Problem denn wirklich auch das Problem, welches Konzept bzw. Technologie lösen? Vielleicht wünsche ich mir das ja nur, aber missverstehe sie. Also sollte ein Lehrer nicht einfach mein selbstverständliches Wie-Bedürfnis stillen, sondern zunächst (bzw. auf Wunsch) ausführlich alle Facetten des Warum dahinter (er)klären.

Was ist das Problem hinter ADO.NET? Warum sieht dieses oder jenes bei ADO.NET so und nicht anders aus? Was ist das Problem hinter der Microsoft CCR? Warum sieht sie dann so und nicht anders aus? usw.

Wer könnte nun aber am besten das Warum erklären? Wer könnte am besten die Notwendigkeit zur Lösung von Problemen rüberbringen? Wer könnte die Beweggründe hinter den konkreten Ausprägungen des Wie optimal darlegen? Effizientes lernen - die ewige Anforderung derjenigen unter Projektdruck - fordert ja, dass man von den Besten lernt. Wer sind also die Besten, um nicht nur das Wie, sondern auch das Warum zu erklären?

Von wem würde ich also gern lernen? Das war damals die Frage, die mich im Anschluss umtrieb. Als Antwort sind mir dann Daniel Düsentrieb und Doc Brown von "Zurück in die Zukunft" eingefallen. Die sind vielleicht ein bisschen spinnert - aber sie sind genial und wissen es am besten. Eine Erfindung möchte ich mir am liebsten vom Erfinder erklären lassen. Er soll mir Rede und Antwort stehen. Er kennt das Problem auf dem Effeff, denn sonst hätte er keine Lösung erfunden. Und er weiß, warum die Lösung so aussieht, wie sie aussieht, sonst hätte er sie nicht so gestaltet.

Zwar ist der Erfinder auch immer stolz auf seine Erfindung, aber das macht nichts, finde ich. Soll er auch sein. Denn dann ist er mit Energie dabei, die auf mich überspringen kann. Ich höre mir also zunächst einmal lieber einen Erfinder an, als einen Übersetzer. Unabhängigkeit und Außensicht sind auch wichtig; aber wenn ich erstmal etwas verstehen möchte, dann brauche ich Einsicht und Tiefblick - wenn es irgend geht. Und die bietet mir vor allem der Erfinder höchstpersönlich.

Daraus ist dann eine Idee erwachsen, die inzwischen sogar umgesetzt ist. Aus dem Wunsch heraus, von den Besten, von den Erfindern zu lernen, habe ich mir sozusagen mindestens für mich selbst, aber natürlich auch für alle anderen, die an Einsicht und Tiefblick interessiert sind, eine Workshop-Reihe kreiert. Sie heißt - soviel Englisch muss schon sein in unserer Branche, oder? - "Straight from the Horse´s Mouth" (SFHM), was soviel bedeutet wie "Informationen aus erster Hand". Im Microsoft-Umfeld ist diese Redensart immer dann in Gebrauch, wenn man z.B. für eine Konferenz darüber nachdenkt, einen Referenten von Microsoft aus Redmond einzufliegen. Das Argument dafür lautet dann "Da hören wir es dann straight from the horse´s mouth, das hat doch besonderen Wert für die Teilnehmer."

Warum aber immer nur Microsoft? Außerdem ist es schwer, Erfinder von Microsoft-Technologie zum Reden zu bringen. Erstens passiert dort viel in Teams, zweitens sind die Teams groß, drittens sind Erfinder heißbegehrt und damit oft nicht verfügbar.

Es muss auch nicht immer Microsoft sein. Es gibt soviele Konzepte und Technologie, die nicht von Microsoft stammen und dennoch oder gerade deshalb Wert sind, einen näheren Blick drauf zu werfen. Und so finden sich in der Workshop-Reihe bisher gerade keine Microsoft Produkte, sondern solche, denen ich a) mehr Aufmerksamkeit wünsche und bei denen b) der Erfinder oder Chefentwickler selbst klar erkennbar ist und sich auch noch mitteilen will und kann. Bei Professional Developer College haben wir die Reihe also mal begonnen mit:

db4o ist ein objektorientiertes Datenbanksystem, Open Source und meiner Meinung nach bei zuwenigen Projekten auf dem Radar, wenn es um Objektpersistenz geht. Deshalb ein SFHM-Workshop für db4o.

Vanatec bietet mit OpenAccess (VOA) einen ausgereiften O/R Mapper quasi der ersten Stunde. Auch wenn jetzt Microsoft mit Linq to Sql uns alle überrollt, ist ja aber die Microsoft-Lösung nicht der Weißheit letzter Schluss. Es lohnt sich also, die Alternativen zu evaluieren. Und warum dann nicht einen soliden Mapper anschauen, der viele Konzepte bietet, die Linq to Sql nicht in petto hat - und dann auch noch mit dem Chefentwickler selbst sprechen? Deshalb ein SFHM-Workshop für VOA.

Ranorex ist ein Automatisierungswerkzeug für UI-Tests. Nicht-visuellen Code automatisch mit NUnit & Co zu testen, hat inzwischen ja schon ziemlich die Runde gemacht. Viele tun es schon. Aber UI-Tests zu automatisieren, das ist nochmal ein anderer Schnack. Aber Ranorex kann das. Und zwar ziemlich intuitiv gerade für .NET-Entwickler. Ranorex erzeugt nämlich Testscripte in .NET-Sprachen bzw. ermöglichst die UI-Fernsteuerung aus .NET-Code heraus. Sehr cool! Und dann entwickeln das auch noch Leute in Österreich. Vater und Sohn - und inzwischen mit einem ganzen Team. Deshalb ein SFHM-Workshop für Ranorex, bei dem der Erfinder und Chefentwickler das Tool selbst erklärt.

Ich glaube fest daran, dass - woimmer es geht - die Information aus erster Hand erstmal die beste ist. Mit der sollte man Anfangen. Sie vermittelt ein Maximum an Hintergrundinformationen, Problemstellung und Warum. Deshalb SFHM. Und dann... später, ja, später kommen dann unabhängige Meinungen dazu. Das ist gut und wichtig. Aber davon haben wir ja genügend zu den meisten Themen.

Ich bin froh, dass ich die Chance ergriffen habe, eine Erkenntnis so in eine Tat umzusetzen. Nun bin ich gespannt, ob das auch anderen nützt...

Hört, hört! - Komponentenorientierung einmal anders

Es ist ja kein Geheimnis, dass ich ein großer Freund der Komponentenorientierung bin ;-) Aber sooft ich auch darüber spreche oder schreibe, es bleibt schwierig, Komponentenorientierung schnell begreifbar zu machen. Erklärungen am Flipchart sind trotz aller Mühe mit Verbildlichungen immer noch abstrakt. Wenn dann Code ins Spiel kommt, ist Komponentenorientierung zwar deutlich konkreter - aber es dauert halt, bis der Code geschrieben oder in seinen Zusammenhängen erklärt ist. Wie also das Verständnis von Komponentenorientierung beschleunigen?

Mit Musik! Denn schon Johannes Heesters wusste: "Mit Musik geht es am besten!" Aber nicht nur die Verzauberung schöner Fraun, sondern auch die Komponentenorientierung. Und das geht so:

Ja, ich habe keine Kosten und Mühen und Peinlichkeiten gescheut, diese didaktisch hoffentlich sehr wertvolle Demonstration von Komponentenorientierung zu produzieren :-) Mein Dank gilt dabei vor allem meiner Tochter Verena, die mir nicht die Flötentöne, sondern die Geigentöne beigebracht hat. Denn ich bin des Geigens nicht mächtig, wie man unschwer erahnen kann, oder?

Was hat das mit Komponentenorientierung zu tun?

Meine Darbietung des Stückes "Bell Ringers" besteht aus Komponenten. Jede Note darin ist eine Komponente. Ich habe das Stück ja nicht gespielt (schon gar nicht vom Blatt), sondern Note für Note einzeln aufgenommen. Hier die Produktionsschritte:

1. Anforderungen: Der Notentext war meine Anforderung. Ziel war, das Stück am Ende komplett zu gehör zu bringen.
2. Analyse: Aus den Anforderungen habe ich die Komponenten abgeleitet. Ich habe alle verschiedenen Noten extrahiert. Wenn das Stück vielleicht aus 40 Noten unterschiedlicher Tonhöhe und Dauer besteht, dann sind es aber nur vielleicht 8 verschiedenne Tonhöhen gewesen.
3. Implementation: Jede Komponente habe ich einzeln implementiert. Für jede der verschiedenen Tonhöhen habe ich mit von Verena zeigen lassen, wie man sie auf der Geige spielt. (Bei einer haben wir uns aber, glaube ich, vertan. Naja, macht nix ;-) Dann habe ich die Kamera angeschaltet und nur genau diesen einen Ton gespielt. Unterschiedliche Notenlängen habe ich dabei nicht unterschieden. Ich habe einfach den Ton lang genug gespielt, so dass ich später dieselbe Aufnahme für achtel, viertel oder auch halbe Noten benutzen konnte.
4. Integration: Schließlich habe ich die Komponenten zum großen Ganzen zusammengefügt. Im Videoschnittprogramm habe ich die 8 Videoschnippsel mit je einem Ton so aneinandergereiht, wie es der Notentext vorsieht. Jede Note kommt darin mehrfach vor, also habe ich sogar Komponenten wiederverwendet. Und es gibt sogar ganzen Notensequenzen, die sich wiederholen, also habe ich Gruppen von Komponenten (Superkomponenten oder Composite Components) auch wiederverwendet.

Der Aufbau des Gesamtstücks aus Komponenten ist natürlich unschwer zu sehen. Aber das soll auch so sein. Die "Experience" ist damit eine andere als bei einer Einspielung in einem Stück. Macht das etwas? Das hängt vom Anspruch ab.

Wer ein Musikstück "aus einem Guss" haben will, also höchsten Kunstgenuss, der muss sich einen Experten suchen, der es spielen kann. Und dieser Experte hat viel Zeit und Mühe investiert, sein Instrument zu lernen. Und das Einspielen bzw. Üben hat dann auch nochmal einige Zeit gebraucht. Was auf der Bühne so leicht aussieht, ist harte und langwierige Arbeit. Deshalb müssen Künstler auch das Einstudierte öfter spielen, weil sich sonst der Aufwand nicht gelohnt hat.

Also: Genuss aus einem Guss hat die höchste Qualität - braucht aber ein großes Budget und viel Geduld.

Vorteile der Komponentenorientierung

Ich habe nun keine Jahre beim Geigeüben verbracht. Ich habe auch keine Zeit ins Einstudieren des Stückes investiert. Ich habe stattdessen das Stück analysiert und dann die Komponenten in ausreichender Qualität implementiert und integriert. Fertig. Das Ergebnis ist zwar nicht aus einem Guss - aber immer noch gut genug und vor allem flexibel!

Erstens habe ich also viel weniger Zeit aufgewandt für ein immer noch passables Ergebnis. Ich hätte sogar die einzelnen Noten von verschiedenen Laien gleichzeitig (!) einspielen lassen können. Jede einzelne hätte dann von einem Musiker separat auf ihre Qualität geprüft werden können. Nur die besten Einzelnoten/Komponenten wären am Ende ins Ganze eingegangen. (So geschieht es auch bei Profieinspielungen im Studio. Man glaube nicht, dass das, was man auf einer CD hört, einfach so im Studio nach viel Üben "runtergespielt" wurde. Es besteht aus vielen für sich genommen perfekten Schnippseln.)

Und zweitens hat das Ergebnis nun eine Struktur, die ich auch verändern kann. Da überhaupt einzelne Komponenten vorhanden sind - die Videoschnippsel mit den einzelnen Tönen -, kann ich jede getrennt von den anderen modifizieren. Ich kann sie austauschen, in der Länge verändern, umarrangieren oder woanders wiederverwenden.

Genau das ist es nun, was Komponentenorientierung in der Softwareentwicklung will: Statt "Genuss aus einem Guss" (Monolith) lieber eine flexiblere, schneller zu produzierende und leichter zu testende Struktur aus integrierten Einzelkomponenten.

Verstehen Sie jetzt? ;-)

 

PS: Diese Analogie für die komponentenorientierte Softwareentwicklung hinkt nur in einer Hinsicht: Beim Musikstück sieht/hört man einen Unterschied zu einer Einspielung "in einem Rutsch". Bei einer komponentenorientierten Anwendung hingegen ist äußerlichen kein Unterschied zu einer monolithischen zu bemerken.

PPS: Um ehrlich zu sein, hatte ich bei der Produktion des Videos keinen Gedanken an Komponentenorientierung verschwendet. Wie im Vorspann zu lesen, wollte ich einfach eine Hommage an Lasse Gjertsen bringen. Sein Video bei YouTube finde ich einfach klasse.

Dann bin ich aber heute morgen zufällig nach längerer Zeit über mein Video gestolpert und bei einem Gespräch darüber mit meiner Freundin kam mir der Gedanke: Hey, das ist ja komponentenorientiert. Würde mich also freuen, wenn auf diese zufällige Weise aus einem Spaß jetzt etwas Nützliches würde.

Entwickler machen keine Sprünge - oder: Warum Technologien manchmal so schwer zu verkaufen sind [OOP 2008]

Warum sind manche Dinge eigentlich so schwer in der Softwareentwicklung? Verteilte Anwendungen sind imperformant, SOA wird als Maximierung Webservice-Endpunkten verstanden, Anwendungen sind objektorientiert, aber leider unwartbar, ein automatischer Build ist in vielen Projekten ein Fremdwort usw. usf. Warum? Liegt es an unausgereiften Konzepten und ungenügenden Technologien?

Ich glaube, nicht. Mein aktueller Gedanke ist vielmehr, dass allzuoft in der Softwareentwicklung das Unmögliche versucht wird. Sie versucht unrealistische Sprünge zu machen. Entwickler können aber nicht springen. Sie können nur einen Schritt nach dem anderen gehen.

Um zu verstehen, was ich damit meine, zunächst ein kleiner Ausflug in die Psychologie... Sie können aber auch - ein letztes Mal ;-) - springen und gleich beim für die Softwareentwicklung relevanten Abschnitt "Ebenen der Softwareentwicklung" weiterlesen.

Bewusstseinsstufen

Bei der Lektüre von Ken Wilber bin ich mal wieder über Integrale Psychologie und das Modell der Bewusstseinsstufen gestolpert. Nach ihr können Menschen in unterschiedlichen Bereichen (auch Linien genannt, z.B. kognitive Intelligenz, emotionale Intelligenz) auf unterschiedlichen Bewusstseinsstufen sein (auch Ebenen genanannt, z.B. Mythisch, Rational). Wieviele Bewusstseinsstufen es genau sind, dazu haben verschiedene Schulen auseinandergehende Meinungen. Über drei ganz grobe herrscht jedoch wohl Einigkeit:

• Bewusstseinsstufe 1: Prä-Konventionell, egozentrisch
• Bewusstseinsstufe 2: Konventionell, gruppenzentrisch
• Bewusstseinsstufe 3: Post- oder Trans-Konventionell, weltzentrisch

Die geistige Entwicklung eines Menschen verläuft in vielen Linien von der niedrigsten Stufe zu höheren. Auf den unterschiedlichen Linien kann er auf verschiedenen Ebenen sein. Die höchste Ebene - allemal in sehr feingranularen Bewusstseinsstufenmodellen - erreichen allerdings nur die allerwenigsten.

Ausgangspunkt der Entwicklung bei allen Menschen ist eine egozentrische Weltsicht. Auf dieser Ebene sind Menschen selbstbezogen, ihr eigenes Wohl ist ihnen am wichtigsten. Neugeborene und auch noch Kleinkinder sind ganz natürlich auf dieser Ebene. Alles muss sich um sie drehen. Sie müssen komplett versorgt werden, also fordern sie das auch ein. Alles geht auf dieser Ebene - solange es unsere Bedürfnisse befriedigt.

Erst allmählich lernen wir dann, von uns selbst abzusehen. Da sind noch andere Menschen in unserer Umgebung, die gehören zu uns. Wir dürfen sie nicht aus dem Blick verlieren, weil es uns sonst schlecht erginge. Die gruppenzentrische Bewusstseinsstufe wird erklommen. Um mit den anderen auszukommen oder sie uns gar wohlgesonnen zu stimmen, lernen wir, uns an Regeln zu halten. Diese Konventionen sind gruppenspezifisch und halten sie zusammen. Familien, Clans, Dorfgemeinschaften, Nationen oder Glaubensgemeinschaften sind Beispiele für solche Gruppen, denen wir uns auf der 2. Bewusstseinsstufe zugehörig fühlen.

Geht die Bewusstseinsentwicklung weiter, dann erkennen wir, dass die Welt nicht nur aus unserer Gruppe besteht. Da sind andere Gruppen mit anderen Konventionen. Wir lernen unsere bisherigen Konventionen zu transzendieren. Die Gruppe wird ein Teil der größeren Welt. Unser Bewusstsein lässt Pluralität nicht nur zu, sondern freut sich an ihr; wir sind weltzentrisch. Das bedeutet nicht, dass wir nach keinen Regeln mehr leben würden. Regeln verlieren nur ihren Absolutheitsanspruch. Wir wählen unsere Regeln selbst - und fühlen uns frei, sie zu hinterfragen und neu zu definieren.

Unmöglich zu springen

Keine dieser Bewusstseinsebenen ist gut oder schlecht. Sie stellen einfach nur Entwicklungsstufen dar. Es sind Haltepunkte auf einem Lebensweg. Wie lange jemand auf ihnen verweilt, ist ganz unterschiedlich. Zu welcher Bewusstseinsstufe er in welcher Linie es während seines Lebens schafft, auch das ist ganz unterschiedlich.

Zentral für das Verständnis dieser Ebenen ist, dass keine übersprungen werden kann. Wir können nicht ohne egozentrisch gewesen zu sein einfach bei Gruppenzentrizität beginnen. Jeder muss auf allen Ebenen unterhalb seiner aktuellen gewesen sein. Es gilt - wenn auch auf einen unüblichen Bereich angewandt - das alte natura non facit saltus.

Ein Vergleich mit der Musik Ebene 1: Sehr kleine Kinder leben in ihrer eigenen Musik- oder besser Tonausdruckswelt und produzieren eher Krach. Sie kennen noch keine musikalischen Konventionen. Sie sind egozentrisch, wenn sie einfach Spaß an Klanghölzern oder Trommeln haben - der allerdings Erwachsene die Flucht ergreifen lässt. Durch Anleitung betreten Kinder dann die Welt der Kinderlieder. Sie singen einfach. Und wenn es ihnen immer noch Spaß macht, dann singen sie laut und häufig und auch unerschrocken falsch. Sie haben die Egozentrik noch nicht verlassen. Ebene 2: Im nächsten Schritt lernen Kinder dann ein Instrument und betreten damit die Ebene der Konventionen. Sie werden mit Regeln vertraut gemacht, wie Musik in ihrer Gruppe sich anzuhören hat. Diese Regeln sind für abendländische Kinder anders als für indische. Zunächst sind die Melodien einfach, dann werden die Musikstücke immer komplizierter. Von der klassischen Musik bis zur Pop-Musik regieren die Konventionen. Ebene 3: Aber auch Jugend Musiziert Preisträger oder gar Orchestermusiker können sich noch weiterentwickeln. Sie können zum Einen über ihre Musikkonventionen hinausblicken und die Vielfalt der Musiktraditionen schätzen oder gar anwenden lernen. Weltmusik ist das Ergebnis. Zum Anderen können sie ihre Konventionen transzendieren und z.B. Gefallen an Jazz finden oder sich an 12-Ton-Musik versuchen. Auch wenn Jazz und 12-Ton-Musik immer noch Regeln unterliegen, definieren sie doch eine höhere "Musikbewusstseinsebene" als Volkslieder, weil sie deren Konventionen anerkennen, reflektieren und dann über sie hinausgehen.

Jede Bewusstseinsstufe definiert sozusagen einen Horizont, bis zu dem und innerhalb dessen Umkreis wir die Welt wahrnehmen. Was wir wahrnehmen, beziehen wir immer auf das innere dieses Gesichtskreises. Auf der präkonventionellen Ebene beziehen wir alles auf uns; unser Wohlbefinden steht im Mittelpunkt. Alles wird daraufhin eingeordnet: Ist es gut für uns, ist es schlecht für uns? Dasselbe gilt für die Gruppe auf Ebene 2 und für die Welt auf Ebene 3.

Bewusstseinsebene bedeutet, dass wir unfähig sind, die Welt anders zu sehen. Wir können nicht umhin, alles auf uns oder unsere Gruppe zu beziehen. Deshalb sind wir ja auf Ebene 1 oder 2. Bewusstseinsstufen sind wie Brillen, die wir nicht abnehmen können. Allerdings können wir uns immer höher entwickeln, sozusagen die Tönung der Brille ändern und ihren Blickwinkel erweitern.

Der Prä-/Trans-Trugschluss

Auf welcher Bewusstseinsebene befindet sich nun ein Mensch? Um bei den drei groben Ebenen zu bleiben: Ist er egozentrisch oder konventionell oder transkonventionell? Interessanterweise kann man das nicht so einfach bestimmen, sagt die Theorie. Denn oberflächlich (!) können prä- und transkonventionelle Menschen in ihren Sichtweisen/Antworten/Handlungen gleich aussehen.

Auf die Frage, "Darf man bei Rot über die Ampel gehen?" würden die Antworten von Menschen auf Ebene 1, 2 und 3 lauten: Ja, Nein, Ja.

• Ebene 1: "Ja, klar! Ist mir doch egal, was die Ampell zeigt. Ich geh´ rüber, wenn´s mir passt."
• Ebene 2: "Nein, man darf nur gehen, wenn die Ampel grün zeigt. Wo kämen wir hin, wenn niemand mehr auf die Verkehrsregeln achten würde?"
• Ebene 3: "Ja, man darf auch bei Rot gehen, wenn die Umstände es zulassen oder gar gebieten."

Anhand der knappen, oberflächlichen Ja/Nein-Antwort lassen sich prä- und transkonventionelle Menschen also nicht so einfach unterscheiden. Die Theorie nennt das den Prä-/Trans-Trugschluss: Menschen werden aufgrund ihrer Antwort auf Ebene 3 angesiedelt, obwohl sie sich noch auf Ebene 1 befinden.

Macht das etwas, die Antwort ist doch gleich? Ja. Einen Egozentriker nicht zu erkennen, kann sehr schädlich sein. Hinter seinem Ja im obigen Beispiel steht kein Verantwortungsbewusstsein; das gehört einfach nicht zu seiner Bewusstseinsstufe. Wenn jemand auf einer unteren Ebene meint, er sei schon auf einer höheren, kommt es also mindestens zu Missverständnissen und Friktionen, wenn nicht gar zu ausgewachsenen Konflikten. Ebene n hat einfach einen anderen Horizont als Ebene n+1. Was auf Ebene n+1 sichtbar ist, mag Ebene n unsichtbar sein. Dann wird es schwer, solches (noch nicht) Sichtbare zu verstehen. Menschen auf einer Ebene müssen sich überfordert fühlen, wenn sie mit Fragen und Konzepten höherer Ebenen konfrontiert werden. Einem Erstklässler das Weltfinanzsystem erklären zu wollen, kann nicht gelingen.

Ein Vergleich mit der Musik Dem musikalischen Laien erscheint womöglich das quasi ununterscheidbar gleich, was kleine Kinder an Musik produzieren und was atonale Musiker von Weltrang wie Arnold Schönberg komponieren. Der übliche musikalische Laie steht jedoch auf Ebene 2 und versucht nun Ausdrücke der ihm bekannten Ebene 1 mit der ihm (noch) unverständlichen Ebene 3 zu vergleichen. Das muss scheitern; es ist also kein Wunder, dass es zu Prä-/Trans-Verwechslungen kommen kann.

Aber nochmal: Sich auf einer Ebene zu befinden, ist weder gut noch schlecht, richtig oder falsch. Alle Menschen fangen auf der untersten Stufe an. Und aus den unterschiedlichsten Gründen entwickeln sie sich mehr oder weniger weit.

Ebenen der Softwareentwicklung

Mir scheint das Modell der Bewusstseinsebenen und Entwicklungslinien so plausibel und nützlich, dass ich es nun auf die Softwareentwicklung anwenden möchte. Ich glaube, es gibt Ebenen der Softwareentwicklung, es gibt unterschiedliche "Bewusstseinsebenen" für Softwareentwickler, d.h. Stufen ihrer Entwicklung.

Zunächst einmal sehe ich dafür in der Softwareentwicklung eine eigene Linie. Ich nehme einfach mal soetwas wie einen SEQ, einen SoftwareEntwicklungsintelligenzQuotienten an. So wie Menschen einen unterschiedlichen IQ oder EQ (Emotional intelligence) haben, so haben Softwareentwickler auch einen SEQ. Der mag zu einem gewissen Teil unveränderlich sein, aber ganz sicher kann er durch Ausbildung und Übung stark entwickelt werden.

Wie andere Bewusstseinslinien läuft die des SEQ nun auch von niedrigen zu höheren Bewusstseinsebenen, d.h. Stufen mit einem immer weiteren Horizont und tieferer Reflektion. Hier mal ein Vorschlag für diese SEQ-Ebenen. Ich benenne sie einfach mit dem Konzept, das ich bei ihnen für jeweils besonders charakteristisch halte. Sie stellen für mich den zentralen Lerninhalt oder Fokus dar.

 

Die Entwicklung des Softwareentwicklers beginnt beim Algorithmus, d.h. bei Anweisungssequenzen. Er lernt, Statements zur Lösung eines Problems aneinander zu reihen: Ausdrücke, Zuweisungen, Kontrollstrukturen. Das EVA-Prinzip und die Trennung von Daten und Funktionen gehören auf diese Stufe.

Auf der nächsten Ebene werden Anweisungen zu Gruppen zusammengefasst und durch Unterprogramme wiederverwendbar gemacht. Der Softwareentwickler lernt, wie er selbst Funktionen als Zusammenfassungen von Anweisungen definieren kann. Auf der Algorithmus-Ebene hat er sie nur genutzt. Zur Ebene 2 gehören auch Konzepte wie Scope und die Unterscheidung zwischen Stack und Heap.

Die nächste Ebene ist wieder durch eine Zusammenfassung charakterisiert: Objekte/Klassen fassen Daten und Funktionen zu Strukturen auf dem Heap zusammen. Das ist der entscheidende Schritt über Ebene 2 hinaus. Vererbung halte ich für nicht so essenziell, dass sie schon auf dieser Ebene gemeistert werden müsste.

Ebene 4 bricht mit dem rein sequenziellen Programmiermodell. Bisher hier war die Reihenfolge, in der Anweisungen abgearbeitet wurden, klar aus dem Quellcode ablesbar. Mit Funktionszeigern können Funktionen jedoch so parametrisiert werden, dass man ihrem Quellcode nicht mehr ansehen kann, woentlang der Kontrollfluss in welchem Fall genau fließt; das kann nämlich vom Inhalt von Funktionsvariablen abhängen. Ruft eine Anweisung eines solche Variable auf, feuert sie über diesen Callback einen Event, der an einer Stelle bearbeitet wird, die nur dem bekannt ist, der die Variable gesetzt hat. Das kann eine aufrufende Funktion sein. Da virtuelle Methoden Funktionszeiger voraussetzen, scheinen mir Vererbung und abstrakte Klassen auch in diese Ebene zu gehören.

Ebene 4 der SEQ schließt für mich die grundlegendere Stufe der Egozentrik ab. Bis hier konnte der Softwareentwickler sich mit seinem Code allein wähnen. Das ändert sich mit Ebene 5...

Auf der nächsten Ebene lernt der Softwareentwickler, dass Funktionen auch gleichzeitig ausgeführt werden können. Sie können auf verschiedenen Threads zusammen versuchen, ein Ziel zu erreichen. Dafür müssen sie Regeln einhalten. Parallelität braucht Konventionen für die Koordination der konkurrierenden Funktionen und den gemeinsamen Ressourcenzugriff.

Aber nicht nur Funktionen können parallel laufen. Auch die Softwareentwicklung findet parallel statt. Komponenten (d.h. binäre Codeeinheiten mit separater Spezifikation) sind zur Organisation paralleler Entwicklung sehr hilfreich. Sie isolieren Entwickler und Entwicklungen von einander (Komplexitätsreduktion), machen produktiver (echte Parallelentwicklung aller Komponenten) und erleichtern punktgenaues Testen (durch separate Kontrakte begünstigte Attrappen). Um quasi industriell im Team zu entwickeln, sind also Konventionen einzuhalten: Architektur, Komponentenstruktur, IoC, Attrappen sind solche Konventionen, die die Zuammenarbeit erleichtern.

Auf der nächsten Ebene wird der bisherigen "Parallelität im Kleinen" zu Steigerung von Responsiveness und Performance eine "Parallelität im Großen" gegenübergestellt. Anwendungen, die aus mehreren Prozessen bestehen, verteilen ihren Code zur parallelen Ausführung, um skalierbarer oder noch performanter zu sein. Am einfachsten ist die Kommunikation zwischen diesen Prozessen mittels RPC. Für eine grundsätzliche Verteilung muss zu den bis hierher vertrauten Konzepten also nur wenig dazugelernt werden. C/S, COM+, Webservices und .NET Remoting gehören auf diese Ebene. Die Konventionen von Ebene 7 sind z.B. die Kontrakte der verteilten Kommunikation und die Planung des Deployments bzw. der Administration. Die Prozesse in einer verteilten Anwendung müssen sich auf einander verlassen können.

Mit Ebene 7 ist die Entwicklung gruppenzentrischer Entwicklerbewusstheit abgeschlossen. Der Softwareentwickler hat gelernt, dass er mit seinem Code nicht allein ist. Zur Laufzeit und im Entwicklungsprozess gibt es Parallelität, die zur Einhaltung von Regeln zwingt. Wer diese Regeln bricht, muss nicht nur für sich Konsequenzen gewärtigen, sondern beeinflusst immer auch andere.

C/S und RPC sind Konzepte für überschaubare Anwendungen. Was aber, wenn die Applikationen weiter wachsen? Nachrichtenorientierung ist das Mittel, um über eine kleine Gruppe von Prozessen hinaus zu blicken. Sie akzeptiert, dass es auch andere Plattformen geben kann; sie akzeptiert, dass verteilte Kommunikation ganz anderen Kriterien folgen muss als lokale. RPC versucht die Verteilung mit Mitteln der lokalen Kommunikation zu kaschieren. Entwickler glauben dadurch, mit ihren lokalen Konventionen auch verteilte Anwendungen realisieren zu können. Das ist aber ein Trugschluss - und mit dem räumt die Nachrichtenorientierung auf. Sie transzendiert also die ego- und gruppenzentrischen Konventionen und Konzepte und öffnet den Blick für eine weitere Welt mit anderen Regeln, die einen bewussteren Umgang erfordern.

Nachrichtenorientierung ist trotz ihrer Kritik an RPC allerdings zunächst immer noch der Punkt-zu-Punkt-Kommunikation verhaftet. Auch nachrichtenorientiert angesprochene WCF-Servicemethoden sehen mehr oder weniger aus wie lokale Funktionen. Das ändern Event-driven Architectures (EDA). Wie lokale Events kehren sie das Denken um. Services werden nicht mehr direkt kontaktiert, sondern auf Warteschlangen oder Bussen (Enterprise Service Bus) registriert. Das entkoppelt Clients und Services massiv; die Client-Service-Regeln wird transzendiert. Die Orts- und Plattformunabhängigkeit steigt.

Mit SOA werden schließlich verteilte Funktionalitäten auf höherer Ebene wiederum zusammengefasst. Zeit und Ort und Granularität für Dienstleistungen unterliegen keinen Konventionen mehr, die Prozess, Maschine oder Plattform vorgeben könnten. Services können über das Internet weltweit verteilt werden. Softwareentwicklung ist damit auf einer wahrhaft weltzentrischen Ebene angekommen.

Konsequenzen des Ebenenmodells für die Softwareentwicklung

Ob die Ebenen der Entwicklung eines Softwareentwicklungsbewusstseins nun genau so geschnitten sind oder in dieser Reihenfolge aufeinander liegen sollten, finde ich nicht so wichtig. Ich halte den obigen Vorschlag für ausreichend gut, um ihn als Erklärungs- und Planungsmodell zu nutzen. Er muss nicht final, sondern nur angemessen sein. Nicht welche Ebenen genau es gibt, sondern dass es überhaupt Ebenen gibt, ist entscheidend.

Dass mein Vorschlag von einigen derzeit kanonischen Vorstellungen abweicht, ist mir bewusst. Dennoch habe ich die Ebenen so angeordnet, weil sie mir so am plausibelsten bzw. natürlichsten erscheinen. Aber ich bin offen für Alternativvorschläge.

Was nützt der ganze Aufwand aber nun? Wozu dieses Modell? Ich meine, es hilft, heutige Probleme zu erklären und sie zukünftig zu vermeiden. Darüber hinaus bzw. deshalb hilft es aber auch, Ausbildung zu planen.

Seiner Erklärungskraft liegen drei Annahmen zugrunde:

1. Annahme - Entwicklungsstreuung: Softwareentwickler befinden sich auf ganz unterschiedlichen Ebenen.
2. Annahme - Fehlerhafte Selbsteinschätzung: Softwareentwickler wähnen sich oft auf einer höheren Ebene, als sie tatsächlich schon erreicht haben.
3. Annahme - Fehlerhafte Fremdeinschätzung: Softwareentwickler werden von anderen auf einer höheren Ebene als der erreichten angesiedelt.

Dass Softwareentwickler sich auf unterschiedlichen Ebenen befinden, kann - so glaube ich - kaum strittig sein. Ausbildungen und Erfahrungshintergründe sind einfach unendlich vielfältig.

Angesichts eines gewöhnlich weniger differenzierten Entwicklungsbildes werden die Konsequenzen solch unterschiedlicher Entwicklung falsch eingeschätzt. Wo es nur 2 oder 3 sehr allgemeine Entwicklungsstufen gibt, z.B. Junior Programmer, Senior Programmer und, hm, Architect, da fällt auch die Wahrnehmung von Unterschieden (oder weniger neutral: Defiziten) anders aus. Man glaubt allemal, sie ließen sich relativ leicht ausgleichen. Eine Schulung in einer neuen Technologie und fertig.

Das halte ich aber für einen fundamentalen Trugschluss. Zusammen mit der Prämisse, dass Entwicklungsstufen nicht übersprungen werden können und den vorstehenden Annahme, ist für mich vielmehr deutlich, warum verteilte Anwendungen trotz oder wegen WCF immer noch vielen Entwicklern Probleme machen. Und mir ist nun auch klar, warum die SOA-Botschaft nicht so ankommt, wie sie ankommen könnte oder sollte.

Wenn WCF (Ebene 8) Entwicklern nahegebracht werden soll, die gerade mal Ebene 4 (Events) gemeistert haben, dann kann das nicht wirklich funktionieren. Wenn SOA (Ebene 10) gepredigt wird, wo gerade mal RPC (Ebene 7) verstanden wurde, dann kann das nicht wirklich funktionieren.

Technologie- und Konzeptverkäufer kennen ihr Publikum zu wenig. Sie sind ihnen oft um Ebenen voraus. Das liegt an der nur groben Klassifizierung von Entwicklerbewusstheit/-erfahrung. Es kommt nicht darauf an, WCF oder SOA usw. einfach nur Entwicklern mit einer bestimmten Zahl von Berufsjahren zu predigen. Es kommt darauf an zu erkennen, auf welchem Bewusstseinslevel sie sind, ja, sein können.

Bewusstseinslevel mag mit Berufsjahren korrelieren - aber einen Kausalzusammenhang gibt es so einfach nicht. Wer SOA säen will, der sollte also nicht fragen, wieviele Berufsjahre im Publikum der Durchschnitt sind, sondern ob der Durchschnitt der Entwickler Ebene 9 erreicht hat. Denn nur wer Ebene 9 gemeistert hat, kann wirklich auf Ebene 10 klettern. Allen anderen ist das Verständnis für das, was Ebene 10 will, mehr oder weniger verschlossen.

Und nochmal: Das ist keine Wertung. Auf der einen oder anderen Ebene zu sein ist weder gut noch schlecht. Schlecht ist allerdings eine fehlerhafte Selbst- oder Fremdeinschätzung. Ihre Folge sind nämlich falsche Anwendungen von Technologien und Konzepten. Und das kostet viel Zeit und Geld.

Zu erkennen, auf welcher Ebene sich ein Entwickler befindet, ist nun durch den Prä-/Trans-Trugschluss nicht leicht. Entscheidet er sich für den Einsatz einer Technologie (z.B. RPC), weil er die Alternativen abwägen konnte (Trans) oder weil er keine Alternativen hatte (Prä)?

Ergebnis 1: Ich glaube, dass Tools, Technologien und Konzepte heute vielfach falsch eingesetzt werden, weil Entwickler versuchen mit ihnen umzugehen, deren SEQ-Bewusstseinsstufe ihrem Einsatz noch nicht entspricht. Da hilft dann auch kein Schnellkurs, der würde nämlich einen Sprung versuchen. Springen ist aber unmöglich. Helfen kann nur, die fehlenden Ebenen schrittweise zu erklimmen.

Niemand schätzt sich oder andere willentlich falsch ein. Fehleinschätzungen wird vielmehr durch eine undifferenzierte Betrachtung der Entwicklung von Programmierkompetenz Vorschub geleistet. Und auch der Glaube an eine ausreichende Ausbildung tut seinen Teil dazu.

Mein Informatikstudium vor 20 Jahren (also noch vor der Objektorientierung) hat mich lediglich durch die ersten drei Ebenen  (Algorithmus, Funktion und Event/Callback) geführt. Von Parallelität und RPC habe ich dort nichts gehört. Ein Arbeitgeber (oder Technologieanbieter) hätte aber natürlich zurecht angenommen, dass ich auch die Ebenen dank meiner Ausbildung gemeistert habe. Ein Trugschluss.

Heute ist es nicht sehr anders. Von einem Dipl-Informatiker oder BA-Absolventen kann man nicht mehr Ebene 4 erwarten. Darüberliegende Ebenen werden vielleicht in Vorlesungen gestreift, doch das ist nicht gleichzusetzen mit ihrer Meisterung. Eine SEQ-Bewusstseinsebene wirklich zu erreichen bedeutet, mit ihren Technologien und Konzepte wirklich gründlich Erfahrungen gesammelt zu haben. Kann das aber durch die Bank von Informatikstudenten in Bezug auf Parallelverarbeitung oder Komponentenorientierung gesagt werden? Kaum.

Wie gesagt: Es geht nicht darum, dass diese Ebenen in der Ausbildung nicht gestreift würden. Aber solide Bewusstseinsbildung findet nicht statt. Solange in der Ausbildung nicht ausgiebig Erfahrung mit Semaphoren, Deadlockvermeidungsstrategien oder Koordinationsdatenstrukturen gesammelt wird, kann von einem Bewusstsein auf Ebene 5 nicht gesprochen werden. Dasselbe gilt für Contract-first Design, IoC, IDL, Attrappen und schließlich automatische Builds, die aus meiner Sicht zu Ebene 6 gehören.

Projektverantwortliche nehmen aber legitimerweise an, dass zur Ausbildung gehört, alle Ebenen der Softwareentwicklung so tiefgehend zu behandeln, dass am Ende Softwareentwickler stehen, die zumindest sicher auf Ebene 8, wenn nicht sogar auf Ebene 9 oder 10 zu verorten sind.

Leider ist das nicht die Realität. Deshalb kommt es zu Fehleinschätzung. Deshalb kommt es zu teuren Fehlnutzungen von Technologien und Konzepten.

Ergebnis 2: Die Ausbildung sollte ein klares Ebenenkonzept wie oben entwickeln und am state-of-the-art ausrichten. Und sie sollte dafür sorgen, dass ihre Absolventen je nach Abschluss ein gut ausgeprägtes und SEQ-Bewusstsein auf erwartbarer Ebene haben. Erwartungshorizonte für die einzelnen Ebenen sollten mit der Industrie abgestimmt oder zumindest öffentlich sein. Die derzeitigen Curricula sind ein guter Ausgangspunkt, aber ihnen mangelt es an einem expliziten Ebenenkonzept. Sie lassen sich deshalb schwer vergleichen und stehen in keinem Gesamtzusammenhang. An ihnen kann nicht abgelesen werden, wieviel Anteil an einem Maximalbild sie haben.

Ergebnis 3 und Fazit: Ich halte es für sehr nützlich, die Softwareentwicklung insgesamt und den einzelnen Softwareentwickler ins Verhältnis zu einem SEQ-Bewusstseinsstufenmodell zu stellen. Ob es das obige oder ein anderes ist - egal. Solange die Prämisse anerkannt wird, dass es überhaupt Stufen gibt und höhere nicht "angesprungen", sondern ausschließlich durch Schritte über niedrigere erreicht werden können, solange ist es mir recht. Eine Differenzierung in mehr als 4-5 Ebenen setze ich ebenfalls voraus.

Mir hat diese Strukturierung der Softwareentwicklung jedenfalls schon sehr geholfen. Wenn es zu Missverständnissen kommt oder ich Unverständnis bemerke, dann kann ich jetzt viel gezielter abklopfen, wo es hakt. Durch Fragen kann ich leicht klären, auf welcher SEQ-Stufe Gesprächspartner stehen. Wenn ich das weiß, kann ich zusammen mit ihnen überlegen, wie ich ihnen auf die für ihre Situation nötige Ebene hinaufhelfe. Das mag dann etwas Zeit kosten - am Ende ist es aber unumgänglich. Entwickler machen einfach keine Sprünge.

dotnetpro.tv lernt von Willi, oder: Zufällige Begegnung relativer Prominenter

dotnetpro.tv macht ja gerade eine Kreativpause. Nach mehr als 30 Folgen habe ich einfach mal über ein Redesign nachdenken wollen. Eigentlich hatte ich auch schon eines in petto... aber dann habe ich Willi getroffen. Willi ist nämlich einer meiner Helden aus dem Fernsehen. Oder genauer: Willi ist der Moderator einer tollen "Welterklärungsserie" für Kinder - "Willi wills wissen" -, die ich immer mit meiner Tochter schaue. Die Sendung mit der Maus war sozusagen gestern ;-) Heute ist Willi. (Naja, und "Wissen macht Ah!" und "pur+" - jedem Sender seine "Welterklärung" ;-) Aber alle gut gemacht. Da kann man echt was lernen. Sehr kurzweilig!)

Neulich hab ich also Willi auf dem Münchener Flughafen getroffen. Allerdings war ich der einzige, der ihn erkannt hat. Keine Paparazzi, die ihn umlagert hätten. Nix. Keine Köpfe, die sich ihm nachdrehten. Kein Getuschel "Hast du den gesehen? Der ist doch aus dem Fernsehen..."

Zuerst dachte ich nur, "Hm... den kenn ich doch. Sollte ich ihn grüßen? Hab ich den grad auf der VSone gesehen?" Aber dann fiel mir zum Glück sofort ein, woher ich den kenne, dass es der Willi war. Schließlich hab ich dann Mut gefasst und ihn einfach angesprochen. Willi war total nett - wie man ihn halt aus seinen Sendungen kennt -, bedauerte, keine Autogrammkarten dabei zu haben - war aber sofort bereit für den obigen Schnappschuss. Der war allerdings gar nicht so einfach (deshalb schaue ich auch etwas verkniffen), weil ich mit der Handykamera tüfteln musste, um uns beide abzulichten. Autogramme waren außerdem auch gestern, würd ich sagen. So ein gemeinsames Bild mit dem persönlich Helden hat doch viel mehr, oder?

Wie die Reaktionen bzw. Nicht-Reaktionen auf dem Flughafen allerdings zeigten, ist Prominenz relativ. Ein andermal saß ich am Gate neben Klinsi und der Bayern-Elf. Da war deutlich mehr los. Autogrammjäger allerorten. Aber um Willi war es still. Mag auch etwas über die Kinderaffinität zumindest der Fluggäste aussagen. Hm... Mich hat auch keiner erkannt. Das sagt etwas aus über die .NET-Affinität der Fluggäste, meine ich mal ;-) So kommt es eben auf die größe der Gruppe an, in der man gekannt ist. Ein paar Tausend .NET-Entwickler im deutschsprachigen Raum, ein paar Hunderttausend Kinder im deutschsprachigen Raum - oder Millionen Menschen weltweit. Naja... egal... zurück zu dotnetpro.tv.

Von Willi lernen

Eigentlich hab ich Willi vor allem angesprochen, um ihm danke für seine tolle Sendung zu sagen - und anschließend meiner Tochter ein kleines Abenteuer erzählen zu können ;-)

Aber dann hat mich diese Begegnung angestoßen, nochmal über dotnetpro.tv nachzudenken. Wie gesagt, eigentlich hatte ich das neue Format schon in der Tasche. Was mir nun aber aufging war, dass dabei etwas unter den Tisch fallen würde, was ich an Willis Sendung so gut finde: Menschen in ihrem Umfel.

Willi erklärt die Welt (vom Bierbrauen über den Rangierbahnhof bis zur Beerdigung) vor Ort. Er ist bei den jeweiligen Experten vor Ort dort, "wo sie es tun". Er spricht mit ihnen an ihrem Arbeitsplatz während sie arbeiten. Kein Studio, keine Abstraktion, keine Schaubilder. Willi steht mit im Prozess und versucht es auch mal selbst.

Das funktioniert natürlich auch durch seine ansteckend gute Laune. Aber viel wichtiger ist, dass er die Menschen unmittelbar und im doppelten Sinn "im Bild" hat. Wir lernen einfach besser, wenn Menschen uns etwas vorleben und zeigen. Sobald sie sich rausziehen aus der Erklärung, desto abstrakter wird es. Schon eine Stimme aus dem Off, selbst wenn noch Menschen zu sehen sind, erhöht die Distanz.

Gerade das wollte ich aber (wieder) bei dotnetpro.tv einführen: eine Stimme aus dem Off. Das mache ich jetzt aber nicht mehr. Dank Willi bleiben nun nicht nur die Menschen mehr im Programm bei dotnetpro.tv, sondern werden auch noch mehr. Ich werde mich wieder - wie damals bei dotnet.tv - vor die Kamera verfügen. Und der Experte wird auch vor der Kamera bleiben. Und wir werden beide nicht aus dem Off sprechen. Und ich möchte auch erreichen, dass wir beide am "Expertengegenstand" zusammen und sichtbar "arbeiten". So ist's bei Willi, so soll es auch in Zukunft mehr bei dotnetpro.tv sein. Mehr Menschen, mehr Interaktivität vor der Kamera. Sozusagen das Beste aus dotnetpro.tv und dotnet.tv garniert und verfeinert mit Willi-inspirierter Interaktion direkt "an der Sache".

Jetzt sind noch ein paar Produktionsdetails zu klären - und dann kann es wieder losgehen mit dotnetpro.tv.

Warum Veränderung es schwer hat in der Softwareentwicklung [OOP 2008]

Grad lese ich "The Art of Change" von Loebbert und muss innehalten, weil mir aufgeht, was oft schiefgeht. In den Gesprächen auf der VSone und anschließenden Architekturworkshop habe ich immer wieder Aussagen gehört wie: "Ich würde gerne anwenden, was Sie sagen, aber in unserem Unternehmen geht das nicht. Der Chef/der Projektleiter/... sagt immer, dass das früher ja auch nicht nötig war."

Auf die genaue Begründung, die dem Chef/Projektleiter usw. in den Mund gelegt wird, kommt es nicht an. Gemeinsam ist allen, dass den Führungspersonen keine Einsicht in die Notwendigkeit eine Veränderung in den Mund gelegt wird.

Angesichts meiner Lektüre habe ich mich nun gefragt, was es so schwierig macht, Veränderungen in der Softwareentwicklung anzuregen und durchzuführen. Meine heutige Erkenntnis: Es ist so schwierig, weil es Missverständnisse gibt und Wahrnehmungsorgane fehlen.

Ordnungen der Veränderung

Missverständnisse beim Gespräch über Veränderungen rühren von einer undifferenzierten Betrachtung her. Die an der Softwareentwicklung beteiligten glauben nämlich oft, dass Veränderungen nicht nötig seien, weil sie ja ohnehin schon die ganze Zeit in einer Projektsituation leben, die von Veränderungen nur so strotzt. Warum also noch mehr verändern, wenn die ständigen Veränderungen heute schon an den Rand des Machbaren gehen?

Undifferenziert ist diese Sichtweise, weil sie alle Veränderungen in einen Topf schmeißt. Neue Funktionalität, neue Technologien, neue Teamorganisation: das alles ist einerlei.

Um notwendige Veränderungen plausibler zu machen, scheint mir daher zunächst wichtig, genauer hinzuschauen. Ich teile Veränderungen daher mal in 5 Ordnungen ein:

0. Ordnung: Veränderungen im Sinne eines Kunden sind für mich Veränderungen 0. Ordnung. Ein neues Feature, eine Fehlerkorrektur, höhere Performance... wird Software modifiziert, um funktionale und nicht funktionale Anforderungen zu implementieren, sind das Veränderungen 0. Ordnung. An ihnen ist aber nicht nur der Kunde interessiert. Sie sind es auch, auf die Führungskräfte besonders ihren Blick richten.

1. Ordnung: Bei Veränderungen 1. Ordnung werden Materialien verändert. Holz wird zu einem Schrank verarbeitet, APIs und Daten zu einer Software. Wenn einer ein Werkzeug in die Hand nimmt (z.B. Visual Studio), damit Material bearbeitet (z.B. den WinForms API) und zu einem Produkt zusammenfügt, dann ist das eine Veränderung 0. Ordnung. Das, was zu tun ist, ist klar. Es muss nur einfach getan werden. Dabei verändern sich die Rohstoffe hin zum Produkt im Sinne der Kundenanforderungen. Das ist die tägliche Arbeit der Softwareentwickler. Veränderungen 1. Ordnung werden vorgenommen, um Veränderungen 0. Ordnung zu bewirken.

2. Ordnung: Veränderungen 1. Ordnung finden in einem Rahmen statt. Das ist die Grundstruktur oder auch Architektur einer Software. Wenn sich dieser Rahmen ändert, dann ist das eine Veränderung 2. Ordnung. Sie ändert nichts an der Rohstoffveränderung/-verarbeitung, nichts an den Features einer Software, sondern nur die strukturellen Zusammenhänge, in denen die Veränderungen 0. und 1. Ordnung stattfinden. Ziel von Veränderungen 2. Ordnung ist das technische Fundament, auf dem Software ruht.

3. Ordnung: Was hergestellt wird, ist eingebettet in einen Herstellungsprozess. Veränderungen an ihm sind Veränderungen 3. Ordnung. Hierzu zähle ich z.B. die Einführung von Unit Tests oder Continuous Integration oder den Umstieg von VSS auf TFS. Werden diese und andere Konzepte bzw. Werkzeuge eingeführt, die die Art ändern, in der Code produziert wird, dann geht es um Veränderungen 3. Ordnung.

4. Ordnung: Schließlich kann sich auch noch der Rahmen ändern, in dem der Herstellungsprozess abläuft. Wenn Teamorganisation und Vorgehensmodell verändert werden sollen, dann sind das Veränderungen 4. Ordnung. Früher ad hoc Tests, heute Unit Tests - das ist eine Veränderung 3. Ordnung. Aber früher ad hoc Programmierung, heute eXtreme Programming, das überhaupt den Ausschlag für Unit Tests gegeben hat - das ist eine Veränderung 4. Ordnung. Ändern sich die Rollen, ändern sich die Vorgehensschritte (z.B. durch Einführung einer QS oder eines Change Management oder von time boxes Releases), dann sind das Veränderungen 4. Ordnung.

5. Ordnung und höher: Veränderungen höherer Ordnung betreffen nicht mehr unmittelbar das Softwareentwicklungsteam, sondern seine Umwelt. Dazu gehören zum Beispiel Firmenzusammenschlüsse oder die Einführung von Teleworking.

Mit diesen Ordnungen von Veränderungen in der Hand, können Sie in Zukunft sehr einfach die Empfehlungen einordnen, die Sie lesen oder hören. Sie lesen einen Artikel über Scrum - und Sie wissen sofort, dass es um Veränderungen 4. Ordnung geht. Sie lesen einen Artikel, der den Einsatz von BizTalk Server empfiehlt - und Sie wissen, dass die Umsetzung der Empfehlung eine Veränderung 2. Ordnung bedeutete. Den üblichen Artikeln in Fachzeitschriften nach dem Motto "Mehr Performance durch xyz" oder "Best Practices für den Einsatz von abc" geht es um Veränderungen 1. Ordnung.

Ordnungsbeziehungen

Die Ordnungen der Veränderung bilden eine Hierarchie, die ich einmal als Pyramide darstelle:

Höhere Ordnungen sind darin das Fundament für Veränderungen niederer Ordnung. Veränderungen der Ordnung n führen zu Strukturen, die Voraussetzung für Veränderungen der Ordnung n-1 sind. Oder anders ausgedrückt: Veränderungen der Ordnung n-1 sind eingebettet bzw. basieren auf vorherigen Veränderungen der Ordnung n:

• Veränderungen an funktionalen und nicht funktionalen Features einer Software setzen Veränderungen an den "Softwarerohstoffen" voraus.
• Veränderungen an und mit "Softwarerohstoffen" sind immer eingebettet in einen Architekturrahmen und insofern auch abhängig von Veränderungen an ihm.
• Veränderungen am Architekturrahmen setzen voraus, dass sie auch getestet, produziert und deployt werden können. Sie basieren also auf einem angemessen veränderten Produktionsprozess.
• Veränderungen am Produktionsprozess sind nur möglich, wenn sich auch das Vorgehensmodell um ihn, also die Teamorganisation verändert.

Um Veränderungen n-ter Ordnung durchzuführen, sind also ggf. vorher Veränderungen (n+1)-ter Ordnung vorzunehmen.

Den Ordnungen der Veränderungen entsprechen natürlich Ebenen von Systemen (bestehend aus Strukturelementen und Beziehungen) und Prozessen. Diese Systeme und Prozesse sind es, die verändert werden. Insofern beschreibt die obige Pyramide auch eine Hierarchie von Systemen/Prozessen, die aufeinander aufsetzen:

• Das System der kundenrelevanten Features basiert auf einem System von Codeeinheiten.
• Das System der Codeeinheiten basiert auf bzw. manifestiert ein Modellsystem, die Architektur.
• Die Architektur ist eingebettet in ein Produktionssystem und QS-Prozesse.
• Produktion und QS sind Ergebnis der Zusammenarbeit innerhalb des sozialen Systems Projektteam.

Keine Veränderung ohne Druck

Veränderungen sind kein Selbstzweck. Niemand verändert sich - allemal kein Unternehmen -, ohne einen Druck wahrzunehmen, der eine Veränderung zumindest nahelegt, um in Zukunft weniger Druck zu verspüren.

Woher kommt der Druck, um Veränderungen verschiedener Ordnung anzustoßen? Vor allem kommt Druck natürlich von außen. Der Kunde äußert Anforderungen, die in Veränderungen 0. Ordnung resultieren, die auf Veränderungen 1. Ordnung basieren. Ebenso sind es vor allem die expliziten Kundenanforderungen, die Veränderungen der 2. Ordnung anstoßen. Aber auch neue Optionen der Technologieanbieter können sie ermuntern.

Doch schon für Veränderungen 2. Ordnung sind die Impule von außen vergleichsweise schwach. Ganz zu schweigen von Veränderungen höherer Ordnung. Kein Kunde wünscht sich eine bestimmte Produktionsweise oder ein konkretes Vorgehensmodell.

Bei gegebenen Systemen und Prozessen ab Ebene 2 stellt sich daher die Frage: Woher kommt Veränderungsdruck? Warum sollten Veränderungen 2., 3. oder 4. Ordnung überhaupt durchgeführt werden?

Und genau da liegt das Hauptproblem vieler Softwareprojekte, scheint mir. Ein mangelnder Druck von außen ist der Grund für die oben erwähnte Aussage von Entwicklern. Ein Blick auf die Pyramide zeigt auch: Für den Kunden - und somit für Führungskräfte - unmittelbar relevant ist nur die Ebene 0. Nur (oder vor allem) Veränderungen 0. Ordnung werden von ihnen wahrgenommen.

Wahrnehmungsorgane für Veränderungsdruck

Ich denke, es mangelt an Wahrnehmungsorganen für Veränderungsdruck. Das hauptsächlich ausgeprägte ist das Ohr für den Kunden. Wenn er sich räuspert, dann wird die Veränderungsmaschinerie angeworfen. Dann sind Veränderungen 0. Ordnung gefragt - egal wie.

Aber wo Veränderungsdruck von außen kommen kann, kann er natürlich auch von innen kommen. Veränderungen n-ter Ordnung können "von innen" Druck auf andere Ebene ausüben, d.h. Veränderungen (n-1)-ter oder (n+1)-ter Ordnung motivieren. Doch diese Form von Druck muss man natürlich wahrnehmen können.

Veränderungen erzeugen Unterschiede. Manche dieser Unterschiede können dann einfach so groß sein, dass sie einen Unterschied auf anderer Ebene nach sich ziehen sollten. Quantitative Unterschiede sind dafür gute Kandidaten. Ein Beispiel aus der Verkehrswelt: Solange es nur wenige Autos gab, regelte der Verkehr sich quasi von selbst. Nur durch eine größere Quantität der Autos war es dann jedoch ab einem bestimmten Punkt nötig, explizite Regelungen einzuführen. Verkehrspolizisten und Ampeln waren die Folge. Veränderungen n-ter Ordnung (Zahl der Autos) zogen also Veränderungen (n+m)-ter Ordnung (Regelungskonzept) nach sich.

Warum sollte Software davon ausgenommen sein? Wenn bei einer Softwaregröße g zu einem Zeitpunkt tg Systeme und Prozesse auf allen Ebenen passend waren, dann heißt das doch ganz selbstverständlich nicht, dass bei einer Softwaregröße h>g zum Zeitpunkt th>tg dieselben Systeme und Prozesse immer noch passend sind.

Dasselbe gilt für weniger konkrete Umwelteinflüsse als funktionale Kundenanforderungen. Zeitrahmen oder Budget sind Umwelteinflüsse, denen ein Softwaresystem auf allen Ebenen angepasst sein sollte. Ändern sich Zeitrahmn und Budget, so kann das eigentlich nur durch Veränderungen unterschiedlicher Ordnung kompensiert werden.

Vom Entwickler bis zum Chef sollten daher alle Beteiligten bei jeder Veränderung in der Umwelt fragen, Veränderungen welcher Ordnungen dadurch für das Projektteam bzw. Softwaresystem angezeigt sind. Wahrnehmungsorgane für Veränderungsdruck auszubilden ist also gar nicht so schwierig. Eigentlich genügt es zunächst, Unterschiede nicht nur in der Umwelt, sondern auch "im System" überhaupt ersteinmal wahrzunehmen. Auch und vor allem, wenn sie nicht antizipiert oder selbst verursacht sind.

Ist es schwieriger geworden, neue Features einzubauen? Nimmt die Menge an Code zu, von der nicht mehr ganz klar ist, wozu sie dient? Steigt der Aufwand, um Performancelecks zu finden? Meldet der Support Fehler, die eigentlich schon länger behoben sein sollten?

Das sind Fragen, die, wenn mit Ja beantwortet, Unterschiede aufzeigen, die Veränderungsdruck darstellen, auch wenn er nicht unmittelbar von einem Kunden ausgeht.

Kunden (und ihre Stellvertreter wie Verkauf oder Chef) üben Veränderungsdruck auf Software aus. Aber je älter und größer eine Software wird, desto mehr Druck übt sie auf sich selbst aus. Das ist dann Druck von innen.

Solcher Druck ausgehend von Ebene n kann dann nahelegen, Veränderungen (n+1)-ter oder (n-1)-ter Ordnung durchzuführen. Manchmal ist seine Reichweite aber auch größer. Ändert sich das Vorgehensmodell (4. Ordnung), hat das wahrscheinlich Auswirkungen auf die Produktion (3. Ordnung) oder gar auf die Architektur (2. Ordnung). Umgekehrt können neue architektonische Konzepte (2. Ordnung) wie Contract-first Design Veränderungen am Produktionsprozess (3. Ordnung) nach sich ziehen.

Für unterschätzt halte ich in jedem Fall den Veränderungsdruck von innen, der durch "Massezuwachs" (oder Komplexitätszuwachs) über die Lebenszeit eines Projektes entsteht. Und der Druck, den immer knappere Zeitvorgaben und volatile Kundenwünsche ausüben, schlägt sich noch nicht in angemessenen Änderungen der Ordnung 2-4 nieder.

Die Übersetzung von Druckwahrnehmung (wie bewusst oder unbewusst auch immer) in Veränderungen unterschiedlicher Ordnung geht also oft schief.

Ordnungsaspekte für das Multithreading [OOP 2008]

Auf der VSone 2008 habe ich gerade einen Vortrag über Software Transactional Memory (STM) gehalten und meine Open Source Implementation NSTM vorgestellt. Der Vortrag war gut besucht; das hat mich sehr gefreut und ermutigt, weiter an NSTM zu arbeiten. Ein wenig Hilfe von anderen Entwicklern wäre dabei natürlich schön... Bei den Collections, die für einen STM neu entwickelt werden müssen, ist einiges zu tun. (Vom .NET Fx angebotene Collections wie List<T> oder Queue<T> können nicht einfach "von außen" transaktional gemacht werden, da ihre internen Strukturen nicht auf STM basieren. Nur eine grundsätzliche thread-safety lässt sich von außen durch pauschale Sperren herstellen.)

Nun finde ich Ordnung/Überblick immer gut. Deshalb habe ich mich gefreut, beim Blick auf die VSone Agenda eine persönliche Erkenntnis gehabt zu haben. Da war nämlich nicht nur ich mit einem Multithreading-Vortrag vertreten, sondern auch Bernd Marquardt zum Thema OpenMP. Dazu kommt noch, dass ich neulich ein wenig über Microsofts Concurrency Coordination Runtime (CCR) gelesen hatte.

Meine Erkenntnis war nun, dass ich in diesen/zwischen diesen Technologien ein Muster erkannt habe. Und Muster als Strukturierungen der Realität finde ich immer gut. Die erzeugen in mir immer ein Gefühl von Entspannung und Aha nach dem Motto "Achsoooo, so ist das! Eigentlich ganz einfach..." :-)

Das Muster, das ich nun gesehen habe, betrifft die Einteilung von Multithreading-Themen. Herb Sutter hat ja auch schonmal eine Einteilung in "The Pillars of Concurrency" gemacht. Die gliedert die Parallelverarbeitung nach Zwecken. Das ist aber nur eine mögliche Dimension, finde ich. Eine andere ist die Einteilung nach "technischen Aspekten".

Für mich teilt sich Multithreading danach auf in drei grundsätzliche Problembereiche:

1. Code auf Threads verteilen: Code in einem eigenen Thread laufen zu lassen, kann so einfach sein, wie ThreadPool.QueueUserWorkItem() aufzurufen. Zum ersten Aspekt des Multithreading gehört aber mehr. Denn Code explizit auf Threads zu verteilen ist letztlich umständlich oder gar eine intellektuelle Herausforderung. Viel effizienter wäre es doch, wenn Sie sich über die Parallelisierung von Code gar keine Gedanken machen müssten. Mit implizitem oder zumindest deklarativem Multithreading wäre Ihnen eine Last genommen. OpenMP oder Active C# sind dafür hilfreiche Technologien. Mit ihnen erzeugen Sie Threads nicht mehr explizit im Code, sondern sagen viel pauschaler "Hier soll etwas automatisch parallel laufen. Irgendwie."
2. Parallelen Code koordinieren: Paralleler Code läuft selten isoliert. Er muss vielmehr in seinen Aktivitäten koordiniert werden. Threads müssen sich abstimmen, in dem was sie tun. Sie wollen einander Aufforderungen schicken oder aufeinander warten. Der .NET Fx bietet dafür z.B. WaitHandle verschiedener Art. Aber andere Technologien machen es noch einfacher, z.B. die Ports der CCr oder Protokolle in Active C#. Ganz allgemein geht es bei der Koordinierung immer um Signale in Warteschlangen, auf die man warten kann.
3. Gemeinsame Ressourcen parallel nutzen: Wenn Threads dann laufen und sich koordinieren, womit arbeiten Sie dann? Häufig auf gemeinsamen Ressourcen. Die können sie aber nicht einfach so ohne Beachtung der anderen Threads egoistisch nutzen! Parallele Nutzung gemeinsamer Ressourcen läuft immer Gefahr, Inkonsistenzen zu erzeugen  - wenn sie sich nicht koordiniert. Koordinationstechnologien helfen also bei der gemeinsamen Ressourcenutzung. Aber eigentlich ist explizite Koordination genauso ineffizient wie explizite Parallelisierung. Auch hier ist also Abhilfe gefordert. Software Transactional Memory oder auch Space Based Collaboration sind Ansätze, die die Parallelnutzung leichter machen. Sie bieten Abstraktionen, hinter denen konkurrierende Zugriffe und ihre explizite Koordination verschwinden.

Wenn ich zukünftig irgendwo etwas über Multithreading lese, dann werde ich mich sofort fragen, um welchen dieser drei Aspekte es dabei geht. Irgendwie ordnet sich für mich dadurch das Thema besser als bisher.

Und ich habe damit Oberbegriffe in der Hand, die ich auch auf Herb Sutters Zwecke anwenden kann. Wie ist´s z.B. mit der Skalierbarkeit? Welche Aspekte haben Einfluss auf sie? Größere Skalierbarkeit ergibt sich z.B. immer durch weniger Koordination und weniger gemeinsame Ressourcen. Oder wie ist´s mit Responsiveness? Dafür ist es vor allem wichtig, Code einfach parallelisieren zu können. Dann nutze ich Parallelität nämlich eher, um responsive zu bleiben.

Würde mich freuen, wenn diese Aspekte Ihnen auch ein wenig helfen würden, die Multithreading-Welt "geordneter" zu sehen.