[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?