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