[OOP 2009] De ja vu

Neulich lief im Fernsehen eine Sendung zur Intelligenz von Tieren. Und in einem der Experimente waren die Versuchstiere vor die Aufgabe gestellt,  in einem Labyrinth den Ausgang zu finden. Während viele Tierarten das Problem durchaus mit Bravour meisterten, scheiterten andere kläglich, sehr zum Amüsement der Zuschauer. Wer als Informatiker an dieser Stelle zum Lachen neigt, für den habe ich eine schlechte Nachricht. Dieselbe Beobachtung  lässt sich nämlich auch machen, wenn wir von einem erhöhten Standpunkt das ein oder andere Softwareentwicklungsprojekt betrachten. Jeder weiss wie wichtig effektive Kommunikation ist. Dennoch scheitern gerade daran nicht wenige  Projekte.  Dass Testen und Refactoring essenzieller sind als Amok laufender Featurismus, erkennt jeder unbeteiligte Entwickler. Sobald man dieselben Personen auf ihre eigenen Projekte loslässt, erwacht der Spieltrieb sowie der innere Drang nach überbordernder Funktionalität. Täglich hören wir Lobesgesänge auf agile Prozesse und strukturiertes Vorgehen. Warum schaut die Praxis bisweilen so  wenig agil aus? Klar, es liegt am Management! Oder doch eher an den vielen Technologien, die allesamt so untauglich sind? Vielleicht aber auch an den vielen unfähigen Kollegen? Haben wir erst einmal ein Projekt erfolgreich versenkt, so decken wir den Mantel des Schweigens darüber anstatt uns der Ursachenforschung zu widmen. Warum tapsen so viele intelligente Humanoide immer wieder in dieselben Fallen, amüsieren sich aber gleichzeitig über andere weniger smarte Spezies? Warum haben wir Gedächtnisstützen wie die vom "reinvent the wheel", halten uns daran aber in der Praxis oft wenig. Douglas Adams hat einmal gesagt, dass es typisch sei für die Menschheit, dass die meisten die Wiederverwendung von Erfahrungen anderer ablehne. Natürlich, es gibt Hoffnungsschimmer wie etwa Softwaremuster. Insgesamt sehen wir hier aber nur die berüchtigen Tropfen auf dem heissen Stein.

Für die Spezies der Consultants hat das alles einen positiven Effekt. Solange wir derart ungeschickt bei der Softwareentwicklung agieren, brauchen sich Berater keine Sorgen um ihre Zukunft zu machen. Vielleicht sollten wir demnächst eine neue Art von IT-Rolle erfinden: den IT Counseler, um zumindest die negativen weil demotivierenden Effekte abzumildern.

So weit mein Wort zum Sonntag.

[OOP 2009] Software by Big Bang

Sie sind Softwareentwickler und meinen, die Finanzkrise könnte Ihren Job gefährden?

Dann sind Sie leider bereits einem grossen Irrtum zum Opfer gefallen. Der wahre Feind des Softwareentwicklers ist der latente Trend zu "Software by Big Bang". Statt Personenjahre über Personenjahre in aufwändige Eigenentwicklung zu stecken, nutzen Sie besser die Möglichkeiten der Automatisierung! Ein Knopfdruck genügt und die generierte Anwendung steht bereit. Warum "Urknall"? Wenn es möglich ist, aus dem Nichts alles zu schaffen, dürfte sich dies doch für unsere Disziplin nicht als unmöglich erweisen. Ist nicht, genau genommen, alles bereits mit dem Urknall inittiert worden, selbst das vorliegende Posting und auch Ihre Software? Wir alle und unsere Leistungen repräsentieren also eher Kollateralschäden als kreative Schöpfungen.

Die Devise muss demzufolge heissen, mit der Welle zu schwimmen und nicht gegen sie. Ganz nach  dem Motto "Generierst Du schon oder entwickelst Du noch?"

Die Lösung auf alle Probleme - und hier bitte in Ihrer Fantasie die Fanfaren erklingen lassen - heisst MDD (in Worten "Model Driven Development") in Kombination mit DSL (in Worten "Domain Specific Language").

Das Rezept für ein sorgenfreies Informatikerleben lautet also: Man nehme eine Prise Metamodellierung, erzeuge unter ständigem Umrühren einen Anforderungsteig, lege das Ganze in den Cookie Generator und schon ist alles angerichtet - natürlich im doppeldeutigen Sinne.

Im richtigen Leben funktioniert das alles nicht so glatt, weil das Problem zwei Seiten hat. Zum einen ist der Ansatz nur für gut durchdrungene, kleine Domänen sinnvoll. Dass es durchaus schwierig sein kann, eine gemeinsame DSL zu definieren, dürfte jeder bestätigen, der das in einer Beziehung schon einmal versucht hat. Zum anderen muss man sich irgendwann die Frage stellen, wer denn den Generator baut, in dem letztendlich die ganze Komplexität steckt. Da bekommt das Sprichwort vom "unter den Teppich kehren" eine ganz neue Wendung.  Man sollte also auf dem Teppich bleiben und die Erwartungshaltung so mancher Entwickler oder Entscheidungsträger zügeln. 

Gab es da nicht schon andere "silver bullets" ähnlichen Kalibers. Komponenten, Services, 4GL, UML, .... Jede Technologie wurde zunächst zum Allheilmittel stilisiert, um sich dann wenig später einen kräftigen Kater einzufangen.

Das ganze IT-Buzzword-Bingo führt nämlich mitunter dazu, dass Manager die versprochenen Verheissungen tatsächlich ernst nehmen und diese von der eigenen Entwicklung einfordern. Mit der virtuellen, weil nicht existenten Silberkugel kann man also allerhöchstens wild gewordene ITler zur Strecke bringen, nicht aber die Menge aller Probleme des Software Engineering.

Hat das was mit Soft Skills zu tun? Klar! Kleiner Tipp: studieren Sie einmal die Auswirkung von übertriebener Technikeuphorie  auf die Managementebenen. Wenn Sie positive Effekte wahrnehmen, sollten Sie sofort mit dem Lottospielen beginnen oder eine Karriere als Stuntman starten. Erwartungsmanagement gehört also zu den wichtigen Aufgaben des professionellen Softwareentwicklers.

 

MDD, Komponenten, Services sind alles brauchbare Technologien, aber nur wenn man ihre Grenzen kennt und sie entsprechend einsetzt. Ansonsten heisst es dann: riez ne va plus.

[OOP 2009] Der Softwareingenieur ist zu allem fähig

Sobald Sie für Ihr Projekt oder Organisation neue IT-Spitzenkräfte akquirieren wollen, sollten Sie sich zuvor eingehende Überlegungen zu deren wichtigsten Fähigkeiten und Eigenschaften machen. Aus nahezu unzähligen Projekten habe ich die folgenden Erfahrungswerte zusammengestellt. Scheuen Sie sich nicht, ohne schlechtes Gewissen davon Nutzen zu ziehen und Sie als Ihre eigenen Elaborate auszugeben:

• Die wichtigste Eigenschaft des Ingenieurs ist absolute Verschwiegenheit. Eine größere Konmunikationsfähigkeit des Bewerbers sollte Sie von Anfang an stutzig machen. Zum einen bezahlen Sie diese Leute fürs entwerfen und programmieren, nicht fürs reden, und zum anderen richten kommunikationswillige Neonbabies zu viel Schaden an, speziell wenn Kunden ins Spiel kommen.
• Gerade bei Softwarearchitekten dürften technische Kenntnisse eher kontraproduktiv wirken. Der wahre Experte nutzt UML-Werkzeuge wie Powerpoint und Visio, um unvoreingenommen Lösungen zu realisieren. Techniknähe hingegen führt zu experimentierfreudigen Entwicklern, die der Firma nur kostbare Arbeitszeit stehlen.
• Vorhergehende Projekterfahrungen führen zu demotivierten Mitarbeitern. Unerfahrene Fachleute können ihren Traum noch leben und in utopischen Visionen schwelgen. Nur dadurch lassen sich Überraschungen in den laufenden Entwicklungen gewährleisten. Aus demselben Grund gehört Lernen aus Fehlern zu den Grundübeln jeder Teamkultur. Erstens machen Softwareentwickler keine Fehler und zweitens wiederholen sie Fehler nicht, selbst wenn sie zuvor welche gemacht haben sollten. Und drittens lassen sich Fehler zu Feature umdefinieren wie große Hersteller beweisen.
• Entwicklungsprozesse und ganz besonders die agilen sollen nur gewissen Softwareherstellern eine kontinuierliche Integration grüner Scheine sicherstellen. Softwareexperten, die Prozesse für nötig halten, dürften eher an Provisionen von besagten Protagonisten interessiert sein. Das Wasserfallmodell ist das einzig selig machende, auch wenn uns verirrte Sektisten eines Besseren belehren wollen.
• Testen ist nur etwas für Verlierertypen und Bürokraten, nicht für unternehmerisch denkende IT-Experten. Wer sorgfältig agiert, braucht nicht zu testen. Oder gehören Sie zu jener pedantischen  Spezies, die Reinigungskräften auf der Suche nach übrig gebliebenen Schmutzresten hinterher schleicht. Testsucht ist also eher mit Waschzwang vergleichbar.
• Anforderungsanalyse ist nur was für richtige Männer, nichts für Weicheier aus der IT-Abteilung. Ein Softwareentwickler sollte also gar nicht erst versuchen, Anforderungen im Detail zu verstehen, sondern nur das umzusetzen, was sie oder er zu verstehen glaubt. Weil hinterher jeder Änderungswunsch von Kunden zu grossen  Aufwänden führt, sollten sie sich schon jetzt einen Tresor zulegen, um die daraus resultierenden zusätzlichen Gewinne sicher zu verwahren.
• Teamfähigkeit impliziert Geselligkeit und unterstützt revoluzerische Verhältnisse. Achten Sie daher auf uneigenständige, infantile Mitarbeiter, die stets  an Ihrem Rockzipfel hängen. Einzig Tyrannei und Diktatur in Softwareprojekten kann dafür sorgen, dass die Karwane erfolgreich weiterzieht. Wie ein ehemmaliger Bundeskanler doch so trefflich bemerkte: letztes Jahr befanden wir uns einen Schritt vor dem Abgrund und dieses Jahr sind wir schon einen Schritt weiter.

Es gäbe noch viele weitere Fakten und Empfehlungen anzuführen, doch ist es für den Autor Zeit, seine nächtliche Ruhestätte aufzusuchen und zuvor noch dem Gott der Informatik zu fröhnen - dem Paulaner!

[OOP 2009] Layers & Co

Ich weiss nicht ob Sie es schon wussten, aber in größeren Organisationen ist das Layers-Architekturmuster sehr verbreitet. Ganz oben in schwindelerregender Höhe thront das Management und delegiert Aufgaben gerne nach unten (absteigende Nahrungskette). Die unterste Schicht wiederum ist für die Umsetzung zuständig, versteht nur selten die Sprache der obersten Schicht, versteckt sich also in der Regel hinter einer Low-Level Perspektive. Wegen des zumeist strikten Layerings befinden sich dazwischen ganz viele weitere Ebenen. Gerade die Layers in der Mitte fühlen sich in ihrer Sandwich-Position nur selten wohl und neigen dazu, den Informationsfluß in beiden Richtungen zu misszuverstehen oder sogar zum Stillstand zu bringen, was zu Fehlinterpretationen in den obersten und untersten Hierarchien führt. Moral von der Geschicht: strikte Layers bringen's nicht.

Daher ist es ratsam, Mediatoren in solche Organisationen einzuschleusen. Diese wissensdurstigen Mitmenschen saugen geradezu jede noch so unbedeutende Information in sich auf und geben sie auch an alle weiter, die sie hören wollen oder nicht. Dumm nur, wenn Mediatoren die Information vorverdauen oder gar verfälschen. Dann wird aus diesem Unterfangen so ziemlich schnell ein Eigentor. Wer kennt nicht die neuesten Gerüchte die eigenen Person betreffend, die sich als völlig realitätsfern erweisen. Nicht zu vergessen die unterschiedlichen Interzeptoren, die gerne interessante Neuigkeiten erhaschen, um sie dann gewinnbringend für eigene Zwecke zu adaptieren.

Günstig ist in vielen Fällen des (IT-)Alltags das Strategiemuster, das eine einheitliche Fassade bietet, hinter der sich die Untiefen des eigenen Handelns verstecken lassen.

Um einen bekannten Komödianten zu zitieren. Ich könnte noch viele Beispiele für solche soziointeraktive Muster nennen, wenn ich nur welche wüsste.

Interessant ist auf jeden Fall, dass das soziale Zusammenspiel in Organisationen sich mit Mustern beschreiben lässt.

Und da soll noch mal einer sagen, wir Informatiker hätten es nicht so mit den alltäglichen Dingen oder wären sogar soziale Underperformer.

[OOP 2009] Design by Committee

Was kommt raus wenn ein paar Dutzend Vertreter einer affenähnlichen Spezies im Vollrausch Software entwickeln?

C++ und MS-DOS!

Für den angemessenen Umgang mit besagter Software bedarf es freilich wieder der Einnahme bewusstseinsverändernder Drogen.

Frederick F. Brooks, der vor etlichen Jahen die besagte Silver Bullet auf uns Informatiker  abgefeuert hat, vertritt die Ansicht, dass die meisten guten Entwürfe in der Geschichte der Menschheit unter der  Federführung exzellenter Einzelpersonen (also known as Exzentriker) entstanden sind. Er erwähnt in diesem Zusammenhang Kathedralen, den Apple Mac und die Programmiersprache Java.

"So what?", denkt sich der  jetzt der deutschsprachige Leser. Offensichtlich bedarf es Teams, um größere Bauwerke zu entwerfen, aber auch Einzelpersonen, um diese Teams ins Ziel zu lenken. Teams ohne Führung neigen zu "suboptimalen" Entwürfen, was wir auch in Politik und Finanzwirtschaft jüngst miterleben durften. q.e.d.

Es bedarf also auch in der erfolgreichen Softwareentwicklung Teams und geeigneter Führungspersönlichkeiten. Fähigkeiten wie Mut, Führungsstärke, Kommunikation oder Teamfähigkeit sind also nicht nur Faktoren, die bei Sonntagsreden weidlich breit getreten werden, sondern in der IT-Realität sich als unabdingbar erweisen.

Aber Achtung! Führung braucht Kontrolle, wenn nicht Produkte Golem-scher Prägung das Licht der Welt erblicken sollen.

Der Blick auf Technologie und Werkzeuge vermittelt zwar ein angenehmes Gefühl, aber Softwareentwicklung bleibt nicht zuletzt  zu gut hochdeutsch ein "Collaborative Game".

[OOP 2009] Ja mei, ist denn schon wieder OOP?

Wie Weihnachten kommt auch die OOP jedes Jahr völlig überraschend. Wie Weihnachten, weist auch die OOP immer nette Überraschungen auf. Und wie immer, darf ich selbst als aktiver Teilnehmer partizipieren. Ob das eine gute oder schlechte Nachricht ist, müssen die Teilnehmer freilich selbst entscheiden.

Auf jeden Fall finde ich das Motto der Konferenz ganz besonders spannend. "Skills" sind schließlich der Schlüssel für erfolgreiche Projekte. Für die Spezies der Softwarearchitekten reicht es eben nicht aus, technologische Fähigkeiten zu haben. Gerade der Bereich Soft Skills und ein grundlegendes Verständnis über Wirtschaftlichkeit sind unentbehrlich. Ein Architekt braucht Führungsstärke, Mut, Leidenschaft und Leidensfähigkeit - gerade um andere Rollen im Projekt von der Architektur zu überzeugen. Nur werden diese Skills zu selten in Ausbildung und Beruf vermittelt.

Da kommen dann mitunter folgende Varianten zum Vorschein:

Papiertiger haben gute Ideen, bringen diese zu Papier, sind aber nicht in der Lage, andere zu motivieren oder zu überzeugen

Stubenhocker erstellen in ihrem dunklen Kämmerlein die besten Konzepte, wundern sich aber, dass die bösen Entwickler da draussen fast nichts davon umsetzen.

Danger Seekers trauen sich alles zu. Nur leider ist ihnen auch alles zuzutrauen. Oft führen sie Architekturen ein, die sich im nachhinein als großes Risiko erweisen.

Und das nur als Auswahl aus der Artenvielfalt. Der Geist war willig, aber ... den Rest kennen Sie schon.

Interessanterweise scheitern die meisten Projekte eben nicht an technologischen Aspekten sondern an architektonischen Runinen, Politik, Mißverständnissen, Organisationshürden, ungeeigneten Entwicklungsprozessen. Und hinter all dem stecken Personen und Rollen, die für erfolgreiche Projektarbeit entsprechende Skills benötigen.

Kennen Sie da auch noch ein paar typische Variationen von Architekten oder anderen Spezies aus dem Software Engineering?

[OOP 2008] New Kids on the Blog

Blogs sind eine der bekannten Ausprägungen des Web 2.0. Nun gibt es eine Vielzahl von Blogs, von Themen wie Herzschmerz über Politik bis Technik. Von Belanglosem bis Weltbewegendem. Auch im Bereich Softwareentwicklung haben sich inzwischen einige Blogs etabliert. Das gilt natürlich auch für Podcasts, aus meiner Sicht eine eher audiovisuelle Form des Blogging. Ich selbst betreibe z.B. einen Blog über Softwarearchitekturen. Meine Frage: Was sind empfehelnswerte Podcasts und Blogs aus dem Gebiet Software Engineering. Was muss man hören oder lesen, was sollte man lieber ignorieren? Natürlich darf an dieser Stelle das exzellente  SE Radio nicht fehlen. Vorschläge?

[OOP 2008] Ultra Large Scale Systems

Ein Thema hat dann doch gefehlt auf der OOP. Das Thema ULS (Ultra-Large-Scale-Systems), welches das amerikanische DoD vor 2 Jahren in Form einer Studie beleuchtet hat. "Ja, was ist denn das?", werden Sie sich jetzt möglicherweise fragen. ULS-Protagonisten wie Linda Northrop vom CMU SEI würden höchstwahrscheinlich einen metaphorischen Vergleich anstellen. Während bisherige Softwareentwicklung grosser Systeme eher mit dem Bau von einzelnen Infrastrukturen oder Gebäuden zu vergleichen ist, stellt ULS den Bau ganzer Städte dar.  Es geht also nicht um Systeme, sondern um Systeme von Systemen. Es geht um Netze, in denen Menschen selbst zu Netzknoten werden. Es geht darum, dass statt einer zentralistischen Kontrollinstanz Dezentralität dominiert. Das sind Systeme, die ungebremste Evolution aufweisen. Klar, dass darin emergentes Verhalten eine wichtige Rolle spielt, ebenso wie die Tatsache, dass Anforderungen durchaus kollidieren können. Es geht also um Ameisenstaaten.  Riesige Gesundheitsinfrastrukturen integriert im Internet, ergänzt um Telemedizin oder integrierte Telematiksysteme stellen potenzielle Anwendungsgebiete dar. Welche Fragen stellen ich dabei der Softwareentwicklung? Viele, die wir heute nur bedingt lösen können. Und darüber hinaus, genügt Informatik nicht. Hier sind verschiedene Fachrichtungen notwendig. SOA-Systeme "denken" dabei schon ein wenig in eine ähnliche Richtung. Das Internet stellt gewissermassen ein kleines ULS dar. Das ist doch nur für grosse Infrastrukturen relevant! Falsch, denn die gleichen Konzepte lassen sich auch im kleinen nutzen. Insofern stellt Rxploration der ULS-Ansätze ein interessantes Forschungsgebiet dar, gerade für zivile Anwendungen.

[OOP 2008] Nach der OOP ist vor der OOP

Zwei Wochen sind bereits vergangen seitdem die OOP 2008 ihre Pforten geschlossen hat. Mit einem gewissen Abstand fällt es leichter, ein Fazit zu ziehen. Was waren dieses Jahr die thematischen Schwerpunkte, wie lautet also die Hitparade der Themen? Wenn man alles Revue passieren läßt, gehört sicherlich SOA zu den Topthemen der Konferenz und dies in allen möglichen Facetten. Aber auch das alte aber immer hochaktuelle Thema Softwarearchitekturen nahm neben Agilen Prozessen einen breiten Raum ein. Insgesamt habe ich den Eindruck, dass sich dieses Jahr die Techie-Themen der Art "Neue coole Technologie X" eher im Hintergrund hielten, während die tatsächlichen Praxisprobleme beim Software Engineering im Vordergrund standen. Ein bisschen gegen den Strom schwamm allerdings die durchaus intensive Thematisierung dynamischer Sprachen. Die gehören in den Firmen noch nicht unbedingt zum Mainstream, könnten aber bald größeren Einfluß gewinnen. Schließlich sind Sprachen wie C++, C# oder Java zwar mächtig, für einige Probleme aber viel zu unproduktiv. Was mir sehr gut geafllen hat, ist der Blick über den Tellerrand, in Form von Keynotes und Vorträgen, die sich auch Aspekten jenseits der Technik widmeten. Seien wir ehrlich, in den meisten Projekten stellt das Beherrschen von Technologien zwar eine Herausforderung dar, aber die meisten Probleme resultieren eher aus Fehlleistungen anderer Art. Insgesamt hat die OOP den Spagat geschafft, zwischen technischen und nicht-technischen Themen ein breites Spektrum abzudecken, ohne aber den roten Faden zu verlieren. Dadurch hebt sich die Veranstaltung wohltuend von den sonstigen Hardcore-Technik-Events ab.  

[OOP 2008] Back to the Future - Forward to the Past

Die OOP 2008 vorbei und schon steht die OOP 2009 vor der Tür. Was waren die Highlights der diesjährigen Veranstaltung? Eigentlich lassen sich diesmal gar nicht so richtig einzelne Themen identifizieren. War es Scrum? Oder SOA? Oder Agilität? Mir fällt die Antwort schwer, zumal die OOP eine ganze Reige spannender Themen zu bieten hatte.

Was aber noch viel spannender sein dürfte: welche kommenden Trends erwarten uns für die OOP 2009 und später? Alles nur nicht SOA oder Agilität, würde man fast sagen. Aber im Ernst wie lauten die Trendthemen für die nächste Zukunft?

Sind es dynamische  Sprachen?

Oder neue Middlewareansätze?

Oder Produktlinien?

Oder ganz was anderes?

[OOP 2008] Languages are a Programmer's Best Friends

Wer das berühmte Buch der Pragmatic Programmers kennt, dürfte sich an die Empfehlung erinnern, der Informatiker solle sich jedes Jahr eine neue Programmiersprache aneignen - wer das Buch übrigens nicht kennt, sollte es sich unbedingt anschaffen.

An diese Empfehlung habe ich mich gehalten und in den letzten Jahren Ruby, D, ein wenig Groovy sowie Lisp gelernt und mich neuerdings mit Scala beschäftigt. Nicht, dass ich jetzt täglich Projekte in unterschiedlichen Programmiersprachen anstreben würde. Jede dieser Sprachen integriert innovative Konzepte, die zu einer neuen Sicht auf die Dinge verhelfen und nicht zuletzt zu einer intellektuellen Herausforderung. Allerdings muss ich gestehen, dass ich ursprünglich vom Sprachdesign und Compilerbau komme, und dadurch zum Sprachen-Junkie mutiert bin.

Was aber könnte ich mir für 2008 vornehmen? Ein heisser Kandidat könnte Erlang sein, eine Sprache, die sich speziell für verteilte und parallele Systeme eignet. Kein Wunder, stammt Erlang doch aus den Federn vom Telekommunikationserfahrenen Joe Armstrong. Von Klaus Rohe wurde mir F# ans Herz gelegt, eine funktionale Sprache für .NET.

Gibt es noch weitere Kandidaten? Was bringt interessante Konzepte mit und was könnte in Zukunft etablierten Sprachen das Fürchten lernen? Vielleicht bekomme ich hier ja ein paar gute Tipps.