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