OOP 2008: SOA = System Oriented Attitude

Implodiert der SOA-Stern aufgrund von Überfrachtung mit Erwartungen bald? Endet er als schwarzes Loch und reißt viele Investitionen mit sich? Hm... Solange SOA als eine Sache von Technologien angesehen wird, kann ich mir solche eine dunkle Zukunft durchaus vorstellen.

Ich habe natürlich nichts gegen Technologien wie Web Services, ESB und Standards wie SOAP, WSDL. Alles ganz wunderbar. Dass die sich nicht alle in gleicher Weise durchsetzen und jetzt zum Beispiel REST und POX in aller Munde sind, macht ja nichts. So läuft halt die Evolution. Sie lässt sich nicht am Reißbrett planen. Nur weil SOAP eine gute Idee war, heißt das nicht, dass es auch alle glücklich macht.

Wenn SOA scheitern sollte - wobei zunächst zu klären wäre, wie "Scheitern" eigentlich erkannt werden kann, was es bedeutet -, dann liegt das meiner Meinung nach nicht an diesen Technologien und Konzepten. Ein Messer ist nicht schuld, wenn ich mich mit ihm schneide. Meine unsachgemäße Nutzung des Messers ist dann mein Problem. Dasselbe gilt für die ESB, SOAP, WCF & Co. Ein Messer kann ich richtig und falsch nutzen. Genauso die SOA Technologien/Konzepte. Und ein Messer macht noch keine "Ente a l'orange". Für ein leckeres Mahl muss man Kochen können und nicht nur Werkzeuge haben.

Können die Unternehmen und Projektteams, die auf den SOA-Zug gesprungen sind, aber nun auch kochen? Die Industrie hat ihnen eine ganze Werkzeugpalette für SOA-Menüs in die Hand gedrückt - doch wie steht es mit dem Kochen? Da habe ich nämlich meine Zweifel, ob die Befähigung zum Kochen auch schon genauso weit verbreitet ist, wie die Werkzeuge.

Nicht, dass die SOA-Köche nicht die Knöpfe an den Werkzeugen bedienen könnten. Das lernen sie in teuren Schulungen. Mir geht es eher um eine noch grundlegendere Haltung. Als Hobbykoch kann ich auch irgendwie Messer und Pürierstab bedienen. Aber was kommt am Ende raus? Das big picture, der ganzheitliche Blick aufs Kochen, der fehlt mir. Solange ich nur irgendwie satt werden will, ist der auch egal. Aber wenn ich ein wirklich schönes Menü zusammenstellen und auch noch zubereiten will... dann muss ich einen solchen Blick haben.

Dito beim Thema SOA. Nein, bei SOA ist das sogar noch viel wichtiger. Denn Software ist soviel komplexer als selbst ein Meistergericht. Ich glaube deshalb, dass SOA solange kein wirklich breiter Erfolg wird, solange es mit bestimmten Werkzeugen und einer gewissen Softwaregröße assoziiert wird. SOA als Service Oriented Architecture zu bezeichnen, empfinde ich deshalb als kontraproduktiv. "Service" suggeriert, dass es um spezielle Technologien geht. "Architecture" suggeriert, dass damit nur ab einer bestimmten Größenordnung zu rechnen ist.

Dabei kann SOA nicht wirklich ein Erfolg werden, wenn man sich nur darum kümmert, wie Software im Großen gebaut und zusammengeschaltet werden soll. Genausowenig kann ökologisches Verhalten eine Sache von Großunternehmen allein sein. Ökologisches Verhalten beginnt bei jedem Einzelnen im täglichen Leben... und kommt dann auch bei großen Institutionen an. Auf die Softwareentwicklung übertragen bedeutet das: Solange "Serviceorientierung" nicht eine Sache jedes einzelnen Entwicklers ist, wird sie im Großen keinen nachhaltigen und breiten Erfolg haben.

"Serviceorientierung" im Kleinen, d.h. für jeden Entwickler, ist aber natürlich nach derzeitiger Definition ein Widerspruch in sich. Deshalb plädiere ich für eine Neuinterpretation des Akronyms "SOA". Ich würde es gern als "System Oriented Attitude" verstehen. "Attitude" steht dabei für Haltung, d.h. eine ganz grundlegende Sicht auf die Welt der Softwareentwicklung im Allgemeinen. Und "System" steht für eine Betrachtung von "Software als System" und zwar als komplexes System mit vielen Hierarchie-/Abstraktionsebenen. Und auf jeder dieser Ebenen muss ständig gegen die (schleichende) Zunahme von Komplexität (oder Entropie) gekämpft werden. Das ist keine Sache von Enterprisearchitekten, sondern jedes Entwicklers. Immer.

Services sind da nur ein Mittel auf einer Hierarchieebene. Komponenten sind ein anderes, kaum wirklich genutztes. Klassen ein weiteres. Solange Anwendungen aber Spaghetti-Klassenmodelle enthalten und binäre Komponenten nicht wirklich zur Strukturierung von Software eingesetzt werden und noch Unsicherheit über die Rolle eines SQL Servers, der C#-Code ausführen kann, herrscht... solange ist nicht zu erwarten, dass die bisherige SOA-Idee es schon in den Olymp der Softwareentwicklung geschafft hat. SOA ist mehr als ESB und SOAP. Wer SOA nicht als systemorientierte Haltung begreift und sie bei jedem Projekt - ob klein oder groß - von vornherein atmet, der wird keinen wirklichen Erfolg mit serviceorientierten Architekturen haben.

Meine Empfehlung daher: Wer Serviceorientierung haben will, der fange mit einer Beschäftigung mit der Systemtheorie  und systemischem Denken an. Als durchaus ernüchternden Start kann ich Dörners "Logik des Misslingens" empfehlen. Das Buch macht sensibel für Komplexität.

OOP 2008: Agilität + Architektur?

Im Blog der OOP 2008 fragt Michael Stal nach der Lösung für die Addition "Agilität + Architektur". Architektur setzt er dabei vor allem in Bezug zur Zahl der an ihr beteiligten Köpfe vom einzelnen Architekten bis zur ganzen Entwicklergruppe eines Projektes.

Ohne nun sagen zu wollen, dass Agilität oder Softwarearchitektur leichte Geschäfte seien, habe ich bei dieser Frage aber doch gestutzt. Warum scheint sie überhaupt so schwer zu beantworten? Sie zu stellen suggeriert geradezu einen Gegensatz zwischen Agilität und Architektur. Wenn Agilität mit Flexibilität zu tun hat, steht dann Architektur für Inflexibilität? Hm...

Ich glaube, um die Addition zu lösen, ist zunächst ein Schritt zurück notwendig. Agilität und Architektur müssen von ihrer Absolutheit befreit werden. Weder Architektur noch Agilität sind Selbstzwecke. Hier mein Versuch der Reduktion auf das Wesentliche:

Agilität ist vor allem eine Haltung, die Unsicherheit und Unwissen eingesteht. Sie erkennt an, dass Software sich ständig einer wechselnden Umwelt anpassen muss. Softwareentwicklung ist für sie nur als Handlung-Feedback-Kreislauf denkbar, da Software und Umwelt rekursiv gekoppelt sind. Agile Softwareentwicklung bedeutet konstantes bewusstes Lernen mit allem, was dazu gehört (z.B. eine Vielfalt von Wahrnehmungsorganen, Reflektion, Fehler).

Architektur beschäftigt sich mit Plänen. Pläne sind Abstraktionen für Zukünftiges und Gegenwärtiges. Eine Softwarearchitektur ist zunächst die Beschreibung der zukünftigen Struktur einer Software. Und später ist sie (im besten Fall) nah an ihrer Implementation und dient als Landkarte. Beide Funktionen erfüllt sie durch Abstraktion: Die Architektur ist nicht die Implementation, sondern beschreibt sie nur vereinfacht.

Und was bedeutet das konkret? Wenig. Denn diese Definitionen haben nicht den Zweck, Konkretes zu liefern. Eine agile Haltung mag zum Konzept der Iterationen führen - aber über die Länge einer Iteration kann und soll sie keine Aussage machen. Und Architektur mag zwischen lokalen und entfernten Aufrufen unterscheiden - aber über die zu nutzende Technologie macht der Begriff Architektur keine Aussage.

Sowenig Konkretes mag nun den einen oder anderen verwundern oder gar ärgern. Was nützen denn allgemeine Konzepte für die harte Projektrealität? Oder ist denn nicht eine Collective Code Ownership der beste Weg zur gemeinsamen Arbeit an Software?

Sicherlich, am Ende müssen konkrete Handlungsanweisungen stehen. Doch zur Beantwortung der allgemeinen Ausgangsfrage nach der Summe von Agilität und Architektur bzw. dem Verhältnis zwischen beiden, sind nur gleichfalls allgemeine Definitionen hilfreich.

Agilität ist also quasi ein Synomym für Lebendigkeit, das Leben, denn Leben heißt permanente Anpassung, heißt konstantes Lernen, funktioniert nur durch Versuch und Irrtum. Doch Achtung: Eine Bakterie, ein Molch, ein Elefant, sie alle leben und verhalten sich doch ganz unterschiedlich. Alle sind angepasst an ihre Umwelt. Im Umkehrschluss bedeutet das, Agilität tut gut daran, wenn sie sich dem Lernen verpflichtet fühlt, keine Absolutheiten zu verkünden, sondern zunächst "nur" zur Ermittlung (!) angemessener Verhaltensweisen zu animieren. Was angemessen ist, bestimmt die Umwelt, zu der die Verhaltensweisen passen müssen.

Architektur auf der anderen Seite ist ebenfalls ein Synonym für Anpassung. Sie beschreibt das, was nach aktuellen Kenntnisstand über eine Umwelt eine zu ihr passgenaue Software ist. Doch nicht nur das! Architektur ist auch ein Synonym für Nachhaltigkeit und damit ein Gegengewicht zum "sprudelnden Leben". Zwar führt "sprudelndes Leben", also autopoietische Systeme ohne externe Kontrolle, auch zu Passgenauigkeit - aber das nur unter hohen Verlusten und über lange Zeiträume. Um Passgenauigkeit in kürzerer Zeit zu erreichen, ist Bewusstheit nötig. Und die liefert Architektur. Architektur ist insofern eine zutiefst menschliche Disziplin. Sie verlangt Vorausschau und balancierte Entscheidungen.

Vor dem Hintergrund dieser Betrachtungen, wird die Antwort auf die Ausgangsfrage plötzlich recht einfach:

Agilität ohne Architektur ist möglicherweise das Ideal. Die Architektur einer Software ist dann emergent; sie "mendelt sich aus" in einem evolutionären Prozess. Allerdings braucht das viel, viel Zeit und viele, viele Irrtümer. Die genetische Programmierung kann davon ein Lied singen. Mit Agilität ohne Architektur einen Kunden zu seinen Lebzeiten zufrieden stellen zu wollen, ist nur für triviale Projekte realistisch. Agilität ohne Architektur ist also eine Utopie.

Architektur ohne Agilität ist wie die Reflektionen eines Einsiedlers in seiner Höhle. Bewusstsein ohne Handlung und Feedback und Fehlerkorrektur ist nutzlos und realitätsfern - wenn nicht sogar ein Widerspruch in sich. Der Wasserfall war insofern immer eine naive Kontrollphantasie.

Agilität + Architektur ist damit keine Frage, sondern die Antwort. Software-Entwicklung, d.h. ein Prozess der bei einem Ausgangspunkt startet und dessen Ende meist möglichst weit in der Zukunft liegen soll, ist ein Bildungsprozess. Und Bildung passiert nicht einfach, sondern muss sich an den Gesetzen des Lebens orientieren - es gibt z.B. keinen Nürnberger Trichter - und ein Ziel haben, d.h. Vorstellungen darüber, wie das Ergebnis aussehen soll. Agilität liefert die Lebendigkeit und Architektur die Zielvorstellung für den Software-Bildungsprozess.

Wie lang in diesem Prozess dann ein Handlung-Feedback-Zyklus ist, bestimmt die Umwelt. Wieviele Köpfe über einer Architektur zu zerbrechen sind, bestimmen Problem und Umwelt. Wer unabhängig von konkreter Umwelt und konkretem Problem aufsteht und sagt, so und so lang muss eine Iteration sein oder so und soviele Personen müssen die Architektur definieren, der handelt wider das Leben. Der ist dogmatisch. Das ist zwar auch eine Haltung - aber eine, die eher früher als später auf Ungereimtheiten und Widerstände stößt.

Sicherlich lassen sich aus den allgemeinen Definitionen von Agilität und Architektur Rahmenbedingungen oder gar Gesetzmäßigkeiten ableiten. Sie setzen sinnvollen Antworten auf Fragen wie nach der Länge einer Iteration oder der Zahl der Architekten Grenzen. Doch diese Antworten sind weniger universell als viele vielleicht gern hätten.

So bleibt am Schluss nur die Feststellung: ohne Agilität+Architektur geht es nicht. Aber wirklich einfach wird das Geschäft der Software-Entwicklung dadurch noch nicht. Wer Software entwickeln will, muss sich damit anfreunden, dass es nicht um schnell hergestellte tote Maschinen geht, sondern um langlebige, komplexe Systeme für eine sich im steten Wandel befindliche Umwelt. Software-Entwicklung hat mit Leben + Planung, mit Lebensplanung zu tun. Und das schließt Ungewissheit und Unsicherheit, also auch Fehler mit ein.

Jahresendzeitveranstaltungen - Heiße Themen für einen kalten Winter

Die Außentemperaturen sinken trotz Klimawandel - aber für Entwickler bleibt die Jahresendzeit heiß. Denn drei heiße - oder coole? ;-) - Veranstaltungen liegen noch vor uns:

	Am 11. und 12. November findet im Vorfeld der prio das letzte öffentliche Rhetoriktraining für Softwareprofis des Professional Developer College statt. Noch sind Plätze zu den prio-Sonderkonditionen frei! Sicheres Auftreten, effektive Kommunikation des eigenen Wissens vor Kollegen und Community-Publikum ist erlernbar. Detailinfos findet sich hier und einen Erfahrungsbericht gibt es im Blog des College. Meine Co-Trainerin Renate Klein und ich freuen uns auf zwei intensive und spannende Tage.
	Am 12. November schließt das Rhetoriktraining vor der prio mit einer öffentlichen Abendveranstaltung ab. Die Teilnehmer des Trainings halten je einen Abschlussvortrag vor Publikum, um ihre neu erworbenen Fähigkeiten in einem realistischen Szenario unter Beweis zu stellen. Teilnehmer der prio, aber auch alle anderen Interessierten, sind daher herzlich eingeladen, am 12. November um 20h im Kurhaus Baden Baden kostenlos einem bunten Potpourri an Vorträgen zu lauschen. Wir als Trainer, aber auch die Seminarteilnehmer würden uns über ein reges und großes Publikum freuen! Auszug aus der Liste der Abschlussvortragsthemen: Agile Softwareentwicklung mit Scrum und VSTS SalsaFX - Mehr Nutzen durch mobile Intelligenz WinForms-Benutzeroberflächen automatisch testen Business Intelligence auf der Microsoft-Plattform
	Am 13. und 14. November findet dann die prio conference statt. Als Content Manager habe ich mich ins Zeug gelegt, um ein spannendes Programm zum Thema "Softwarequalität" zusammenzustellen. Noch sind auch hier Plätze für Kurzentschlossene frei. Also, auf nach Baden Baden! Im Casino kann man im November nicht nur Geld gewinnen, sondern auch viel Wissen ;-) Ich hoffe, wir sehen uns dort!
	Und am 17. Dezember findet dann noch eine Veranstaltung der besonderen Art statt. In Hamburg. Dort wird .NET im Kino gezeigt. .net goes to the movies oder kürzer: .net@movies. Mit dem Thema Web Security für .NET-Entwickler möchte Ihnen das Professional Developer College mit den Top-Referenten Dominick Baier und Christian Wenz nochmal so richtig für den kalten Winter einheizen ;-) Die Veranstaltung ist bewusst als "klein, aber fein" angelegt: max. 25 Teilnehmer können zu den eindringlichen Sicherheitsstrategiedemonstrationen und intensiven Diskussionen Einlass finden. Rechtzeitige Anmeldung sichert also hier ganz besonders einen Platz. Als Veranstalter dieses Events würde mich ganz besonders freuen, wenn wir uns dort sähen.

 

So, und jetzt, damit Sie nicht denken, ich würde immer nur in "Veranstaltungssphären schweben", hier noch der Beweis, dass ich mich immer noch mit Code beschäftige :-) In meinem englischen Blog habe ich einmal einen kurzen Überblick über die Instrumentierung von Code mit der .NET TraceSource gegeben. Das lag mir schon länger auf dem Herzen, denn gerade die Entwicklung von größeren, nicht visuellen Komponenten macht es manchmal schwer mitzuverfolgen, was eigentlich während ihrer Ausführung passiert. Wenn tausende Arbeitsschritte durchzuführen sind, verliert der Debugger einen Stück seines Wertes. Dann gilt es, "Muster in Signalen aus dem Code" zu finden. Mit einer TraceSource ist das aber gar nicht schwer.

Viel Spaß beim Ausprobieren. Und bis zu einer der Jahresendzeitveranstaltungen... :-)

Bewerbung einmal anders - .NET-Job in Hamburg

Im schönen Hamburg wartet eine .NET-Herausforderung. Die Softwareschmiede Keep IT Simple (KITS) hat eine .NET-Entwicklerposition zu besetzen. Aber das allein wäre natürlich noch nicht Grund genug für ein Posting in meinem Blog. Zum einen ist KITS die Firma meines Mitgesellschafters Oliver Schmidt beim Professional Developer College. Zum anderen aber - und das ist viel wichtiger - sucht KITS Bewerber für sein Stellenangebot auf ungewöhnliche Weise!

KITS schreibt die Stelle nämlich nicht einfach aus und wartet dann auf eine Flut fingerdicker Bewerbungsmappen. Stattdessen stellt KITS einen Fragebogen ins Internet und bittet Interessenten für das Stellenangebot, ihn auszufüllen - und sich ansonsten weiterer Postsendungen zu enthalten.

Hier der Link zum Fragebogen:

http://www.prodevcollege-jobs.net/Angebote/KITS_Oktober2007.aspx

Was das? Der Fragebogen ist Teil der Dienstleistungen, die unser Professional Developer College im Bereich Recruitement anbietet. Wir machen ja nicht nur Rhetoriktrainings, sondern haben auch noch andere Ideen, die wir in kleinen Schritten implementieren. Und eine dient der Erleichterung der Bewerberauswahl für Softwarestellenangebote.

Unserer Meinung hat das traditionelle Verfahren der Bewerbung mit Bewerbungsmappen drei gravierende Nachteile:

1. Bewerbungsmappen kosten den Bewerber viel Zeit und Geld.
2. Bewerbungsmappen kosten den Stellenanbieter viel Zeit.
3. Bewerbungsmappen sind schwer vergleichbar.

All diese Nachteile lösen sich nun durch eine Bewerbung per Fragebogen in Luft auf:

• Der online Fragebogen kostet den Bewerber zwar einen Moment für´s gewissenhafte Ausfüllen, aber darüber hinaus kein Geld. Aber auch die Mühe ist nicht vergebens ausgewandt, selbst wenn der Bewerber die Stelle nicht bekommt. Denn die Bearbeitung des Fragebogens ist eine wertvolle Reflektion über die eigenen Fähigkeiten. Der Bewerber betrachtet sich für einen Moment von außen, durch die Brille des Stellenanbieters, und lernt so etwas über sich.
• Der Stellenanbieter muss sich nicht durch Seiten und Seiten gut gemeinter Bewerbungen wühlen, um hier und da für ihn relevante Informationen zu extrahieren. Stattdessen sieht er auf einen Blick in den ausgefüllten Fragebogen, wo ein Bewerber welche Qualifikationen in Bezug auf die Stelle hat. Durch den Fragebogen bekommt die Bewerbung eine übersichtliche Struktur, die dem Stellenanbieter dient.
• Da die von mehreren Bewerbern ausgefüllten Fragebögen dieselbe Struktur haben, kann der Stellenanbieter sie nebeneinander legen und sehr einfach vergleichen. Er bekommt sie sogar als XML-Dateien zugeschickt und kann sie mit einer speziellen Software aus- und bewerten lassen.

In größeren Unternehmen mit eigener Personalabteilung kann durch solche online Fragebögen auch die Bewerberauswahl effektiver als bisher auf die verschiedenen Schultern verteilt werden. Hatte bisher die Software-Abteilung eine zu besetzende Stelle gemeldet und die Personalabteilung den Rest gemacht und oftmals erst sehr spät den Stellenanbieter wieder in den Auswahlprozess einbezogen, so hat die Fachabteilung jetzt wieder mehr Kontrolle. Statt nur die zu besetzende Stelle zu melden, definiert die Software-Abteilung jetzt gleich einen für sie (!) relevanten Fragebogen. Die Personalabteilung kann ihn dann ergänzen und stellt ihn online.  Trudeln Bewerber, d.h. ausgefüllte Fragebögen ein, leitet die Personalabteilung die einfach zu einer fachlichen Vorauswahl an die Software-Abteilung weiter. Die muss sich dann nicht durch Bewerbungsmappenberge quälen, sondern nur hübsch strukturierte Fragebögen vergleichen und sich diesen oder jenen Bewerber für ein Telefonat oder persönliches Gespräch wünschen.

Wir - also Oliver und ich, d.h. das Professional Developer College - meinen, dass diese "Lastumkehr" für alle Stellenangebote, die konkret benenn- und durchaus auch quantifizierbare Kompetenzen suchen, eine enorme Vereinfachung des ersten Schrittes der Bewerberauswahl darstellt. Alle Beteiligten können nur Gewinnen.

Wer Interesse hat, heute schon seine Stelle mit so einem Fragebogen auszuschreiben, melde sich einfach kurz bei mir (s. Impressum von www.ralfw.de). In den nächsten Wochen werden wir diese Möglichkeit aber auch noch offizieller anbieten. Dazu gehören dann eine Applikation zur Definition von Fragebögen, das Hosting der Fragebögen und eine Auswertungsanwendung.

Wir freuen uns auf Feedback. Und Oliver freut sich über viele Bewerber :-)

Gesetze der Softwareentwicklung II

Das erste Gesetz der Softwareentwicklung ist scheinbar trivial und doch sehr wichtig. Nach ihm können wir nur eine "gute Software", d.h. eine Software mit wartbaren Strukturen für Anforderungen entwickeln, die wir kennen. Trivial ist das, weil es sich nicht nur selbstverständlich anhört, sondern im Grunde auch ist. Wichtig ist die explizite Formulierung dieses Gesetzes aber dennoch, weil die gängige Praxis in vielen Projekten im nicht Rechnung trägt. Denn da die Softwareentwicklung quasi schon sprichwörtlich nie alle Anforderungen kennt, sind die Softwarestrukturen immer suboptimal. Suboptimale Strukturen machen die Pflege von Software schwer und schwerer, also - so sollte man denken - investieren Projekte immer wieder Zeit, um die suboptimalen Strukturen zu verbessern. Sie würden dann quasi innehalten und für die implementierten Anforderungen die Strukturen verbesseren (Refaktorisierung), bevor weitere Anforderungen erfüllt werden. Dieses Innehalten kommt jedoch nur selten, sehr selten vor. Es scheint gegenüber dem Kunden (oder dem Chef als Vertreter der Kundschaft) keinen Wert zu haben. Deshalb wird dafür nicht systematisch Zeit eingeplant. Das Resultat: Die Struktur der Software verfällt über die Zeit. Die Entropie in ihr nimmt ständig zu, die Unordnung wächst (siehe auch Gesetz 4 der Softwareentwicklung).

Aber lassen wir diese Entwicklung von Qualität für einen Moment außer acht. Nehmen wir Gesetz 1 mal einfach nur als trivial hin. Nehmen wir auch einfach mal an, wir würden alle Anforderungen für eine Software kennen. Schaffen wir es dann wirklich, eine optimale Struktur für unsere Software zu planen? Nein.

Gesetz 1 definiert die entscheidende Voraussetzung für optimale Softwarestruktur, d.h. langlebige Software. Gesetz 1 sagt, ohne die Kenntnis aller Anforderungen kommen wir zu keiner langfristig guten Struktur. Anforderungskenntnis ist aber nur eine notwendige Voraussetzung, keine hinreichende. Denn leider gilt nicht nur Gesetz 1, sondern auch...

Gesetz 2: Optimale Strukturen lassen sich nicht aus Anforderungen ableiten

Selbst also, wenn wir die Anforderungen an Funktionalität, Performance, Wartbarkeit usw. kennen, dann können wir immer noch keine optimale Struktur für die Implementation ermitteln. Dafür gibt es zwei Gründe:

a. Auch wenn wir meinen, die Anforderungen zu kennen, kennen wir sie nicht wirklich. Wir kennen sie nicht wirklich, weil entweder der Kunde sie (noch) nicht wirklich kennt; er weiß also selbst nicht, was er will bzw.  braucht. Oder der Kunde hat die ihm tatsächlich bekannten Anforderungen - natürlich unwissentlich und ungewollt - nur unvollständig mitgeteilt. Oder es gab schlicht Übermittlungsfehler, die Anforderungen sind bei uns nicht verlustfrei angekommen; wir meinen sie zu verstehen, missverstehen sie aber in Wirklichkeit. Auf die eine oder andere Weise kann es also leicht passieren, dass wir zurück bei Gesetz 1 sind: Wir kennen die wahren Anforderungen nicht, sondern nur eine Untermenge. Damit lässt sich kein optimaler Start machen.

b. Selbst wenn wir nun aber die Kundenanforderungen wirklich, wirklich kennen sollten - was selten genug der Fall ist -, dann gibt es immer noch ein Problem bei ihrer Umsetzung: unsere Tools und Technologien. Unsere Branche ist wie kaum eine andere geprägt von ständigen Neuerungen. Materalien (APIs) und Werkzeuge (IDE, Sprachen usw.) sind in ständig wachsendem Fluss. Wir haben immer weniger Zeit, sie wirklich solide zu erlernen. Das bedeutet aber, dass wir immer wieder auf unangenehme Überraschungen bei ihrem Einsatz stoßen. Sie funktionieren nicht wie angenommen. Strukturen lassen sich aber nur für Bekannte Einsatzformen von Materialien und Werkzeugen planen. Wenn wir unseren Werkzeugkasten aber immer weniger beherrschen, er ständig wächst, dann können wir für ihn und mit ihm keine optimalen Strukturen entwerfen. Beispiel: Wer meint, der neue O/R Mapper funktioniert so und so und darauf aufbauend eine Architektur plant und dann stellt sich bei der Implementation heraus, der O/R Mapper funktioniert leider nicht so... der verlässt sehr schnell die scheinbar optimale Struktur und begibt sich in den Wald der ad hoc Anpassungen. Die widersprechen aber selbstredend jeder optimalen Struktur.

Wenn Gesetz 1 trivial erscheint, dann sollte Gesetz 2 zumindest bescheiden machen. Wir sollten nie annehmen, überhaupt die triviale Anforderung von Gesetz 1 erfüllen zu können. Es gibt genügend Gründe, warum wir entgegen jeder Annahme eben doch nicht alle Anforderungen kennen. Und selbst wenn... dann beherrschen wir unsere Materialien und Werkzeuge, die sich quasi immer im Vorläufigen bewegen, nicht wirklich. Wenn wir ein Problem nicht schon 2-3 Mal mit durchaus unterschiedlichen Technologien gelöst haben, oder wenn wir neue Probleme nicht schon 2-3 Mal mit derselben Technologie gelöst haben, dann können wir überhaupt keine optimalen Strukturen planen.

Optimale Strukturen sind nur dort möglich, wo wir sichere Kenntnis haben. Wer die Problemdomäne aber nicht 100% kennt oder wer seine Werkzeuge nicht 100% kennt, der kann nur suboptimale Strukturen entwerfen. Teams, die Auftragsentwicklungen machen, kennen die immer wechselnden Problemdomänen nicht, da ist Suboptimalität gar nicht zu vermeiden. Andere Teams machen jahrelang dasselbe; sie kennen die Problemdomäne aus dem Effeff. Sie leiden dann zumindest darunter, dass sie bei wachsenden Anforderungen keine wirkliche Konstanz in den Implementierungstechnologien haben.

Gesetz 1 und Gesetz 2 machen also deutlich, dass optimale Strukturen kaum geplant werden können. Kommunikationsschwierigkeiten und ewige technologische Unerfahrenheit stehen dem allemal im Wege.

Aber was, wenn wir mal träumen? Was, wenn wir mal ganz naiv annehmen, dass wir die Anforderungen doch wirklich, wirklich kennen und auch noch die Meister unserer Technologien sind? Dann tritt Gesetz 3 in Kraft.

.net kommt ins Kino! Wer kommt mit?

Endlich ist es soweit: Das Professional Developer College lädt zum ersten Mal zu einer Vortragsveranstaltung ein. Unter dem Titel ".net at the movies" - oder kurz: .net@movies - sollen Themen für .NET-Entwickler und -Architekten in ungewöhnlichem Rahmen und persönlicher Atmosphäre vermittelt und diskutiert werden.

Denn bei .net@movies ist der Titel Programm: Die Vortragsveranstaltung findet im ehrwürdigen Streit´s Kino in Hamburg statt. Moderne Technologie trifft Unterhaltungstradition. Stars aus der .NET-Community zum Anfassen für Teilnehmer in Kinosesseln, in denen schon Stars aus Hollywood gesessen haben. Das Streit´s ist ein Premierenkino, das schon Dustin Hofmann, Sophia Loren, Jürgen Prochnow Platz geboten hat.

"Facts & Fun" kommen bei .net@movies also zusammen:

Harte Fakten liefern am 17. Dezember 2007 ab 9h Dominick Baier und Christian Wenz zum Thema Web Security. Ein immer noch heißes Thema, von dem das College meint, dass es mit .net@movies in einem kleinen Rahmen auf den Punkt gebracht werden kann. Denn klein ist der Rahmen, da die Teilnehmerzahl auf 25 beschränkt ist, um wirklich allen ein Maximum an persönlichem Kontakt und Intensität zu bieten.

Mehr Infos zur Veranstaltung im Blog des Professional Developer College:

http://prodevcollege.blogspot.com/2007/10/netmovies-episode-i-web-security.html

Wir freuen uns sehr, noch in diesem Jahr, die episode I von .net@movies "herausbringen" zu können. Eine Veranstaltung in diesem Rahmen hat College-Mitgründer Oliver Schmidt und mir schon lange am Herzen gelegen. Und jetzt ist es soweit! Zwar bietet der Herbst schon einige Events zum Thema Web-Programmierung - aber davon lassen wir uns nicht schrecken. Wir glauben fest, dass ein so wichtiges Thema im Rahmen einer so klar kontourierten und fokussierten Veranstaltung auch im Dezember noch Entwickler interessieren wird. Welche größere Freude zum Jahresabschluss bzw. kurz vor einem neuen Jahr könnte es denn auch geben, als endlich mehr Sicherheit für die eigenen Anwendungen zu bekommen?

Es wird ein kleiner und daher sehr persönlicher und intensiver und langer Event zu einem zentralen Thema für Web-Applikationen - mit starken Experten "zum anfassen".

.net kommt also wirklich ins Kino. Kommen Sie mit!

Harmonie pur auf der Wies´n - Es traf sich das Vanatec EAC

Es gibt das reale, normale Leben und es gibt die Wies´n. Denn wie anders ist zu erklären, dass Menschen und Beziehungen in einem Festzelt in München auf dem Oktoberfest so anders aussehen können als gewohnt? Sehen Sie selbst...
Die Chefredakteure der Konkurrenzmagazine dot.net Magazin (links: Peter Monadjemi) und dotnetpro (rechts: Tilman Börner) prosten sich in trauter Eintracht zu:

(Bild entfernt auf Wunsch eines Abgebildeten.)

Oder hier: Peter Monadjemi und ich haben es mehrere Stunden lang sehr gut nebeneinander ausgehalten. Das Schunkeln ist kaum mit jemand anderem so schön wie mit Peter ;-) Und das, obwohl ich doch gar nicht für sein Magazin schreibe und nicht auf der Entwicklerveranstaltung seines Chefs auftreten darf. Auf dem Oktoberfest ist das aber nebensächlich:

(Bild entfernt auf Wunsch eines Abgebildeten.)

Aber nicht jedem bekommen die Getränke dort gleichermaßen. Bei aller guten Laune, die dotnetpro-Autor Jörg Neumann hatte...

...ist ihm das Kirschwasser nicht so recht bekommen. Schade.

Aber vielleicht hat es ja nur daran gelegen, dass Jörg keine ordentliche Grundlage gelegt hatte. Auswahl genug gab es dafür nämlich und Neno Loje - mit dem ich am Tag vorher noch eine dotnetpro.tv Folge gedreht hatte - bewies Voraussicht, sie zu nutzen:

Anlass für diese Zusammenballung von Medien und bekannten Experten aus dem .NET-Bereich das jährliche Treffen des Vanatec Expert Advisory Councel (EAC). Vanatec (www.vanatec.com) ist Hersteller eines der führenden O/R Mapper für .NET. Hier Chefentwickler Jan Blessenohl, der sich von der Arbeit an seinem Tool OpenAccess auch einmal ausruhen muss:

Um die Qualität von OpenAccess kontinuierlich zu verbessern und dabei so nah am Markt wie möglich zu bleiben, hatte Vanatec schon im Gründungsjahr das EAC bestehend aus einer Handvoll Experten ins Leben gerufen. Und so trifft sich das EAC jährlich mindestens einmal, um aus erster Hand zu erfahren, was sich bei OpenAccess/Vanatec getan hat, was die nächsten Pläne sind - und natürlich, um Feedback aus der Praxis zu geben.
Aber das strengt natürlich an. So ein ganzer Tag mit einem Haufen .NET-Experten am runden Tisch in hitzigen Diskussionen muss deshalb ein Gegengewicht bekommen. Das schafft Vanatec dann mit einem gemeinsamen Besuch beim Oktoberfest. Was könnte auch naheliegender sein, da Vanatec ja in München angesiedelt ist. Und so lösten sich auch in diesem Jahr wieder die eventuellen fachlichen Differenzen vom Tage in oktoberfestlicher Harmonie auf. Schön war´s!
PS: Hier noch der Beweis, dass ich auch da war :-)

Prosit!