Architekturbewusstsein verkörpern

Gibt es wirklich keine Zukunft für Software-Architekten? Ilker Cetinkaya hat in seinem Blog-Artikel so geurteilt.

Wohlgemerkt meint er die Rolle bzw. Position des Software-Architekten, nicht den Aspekt Software-Architektur. Im Gegenteil!

"[Ich empfinde] es als absolut notwendig, die Aufgaben der Architektur nicht auf Positionen oder Personen zu restriktieren, sondern sie als allgemeines Aufgabenfeld in der Software-Entwicklung zu betrachten."

"Schlußendlich sollte es in einem agilen Team meiner Auffassung nach das Ziel sein, auch die Aufgaben der Architektur gemeinschaftlich im Team umzusetzen. "

Ich finde Ilkers Beitrag besonnen. Sein Standpunkt gefällt mir. Ich sehe es grundsätzlich genauso. Deshalb ist mir auch wichtig, mit einem Training wie dem für Agile Architektur Entwickler zu adressieren. Wenn alle zusammensitzen und Architektur planen, kommen mehr Ideen zusammen, das geteilte Verständnis für die Architektur steigt und das gemeinsame Verantwortungsgefühl für das Ergebnis ist höher.

Nichts schlimmer als Astronautenarchitekten, die keinen Bezug zur Entwicklung mehr haben. Nichts konfliktträchtiger als Architekturen, die nach dem Motto "friss oder stirb" über einen Organisationszaun den Entwicklern vor die Tastaturen gekippt werden. Die Entfremdung zwischen Architektur und Anforderungen und Code lauert überall.

Und dennoch... Ein bisschen zucke ich noch bei Ilkers Ergebnis. Weil ich fühle, dass was Ilker beschreibt, für mich an den Persönlichkeiten und Kompetenzen der real existierenden Entwickler vorbeigeht. Ich zucke, weil ich eine Differenz zwischen Wollen und Können sehe.

Viele wollen das, was Ilker beschreibt. Es klingt in der Sache richtig und es hat Appeal für die Persönlichkeit vieler Entwickler, die pragmatisch sind und sich nicht lange mit Organisation aufhalten wollen. Sie sind sensibel für die Verluste, die Distanz zwischen den Beteiligten erzeugen kann.

In meiner Beratungs- und Trainingspraxis sehe ich dann allerdings, dass eben nicht alle Entwickler gleich sind. Sie unterscheiden sich in ihrer technischen Kompetenz, sie unterscheiden sich in ihrer Methodenkompetenz, sie unterscheiden sich in ihrem Charakter und in ihren Bedürfnissen. Und das ist ja auch gut so. Teams, die gemischt zusammengesetzt sind, liefern bessere Ergebnisse.

Verschiedenartigkeit ist grundsätzlich zu begrüßen - sie führt aber auch zu Konflikten und es bleiben blinde Flecken. Wie wird das kompensiert? Wer führt Konflikte zu einem Ergebnis? Wer leuchtet blinde Flecken aus?

Für die Konflikte gibt es Moderatoren. Das weiß inzwischen jeder. Die können aus einer Gruppe kommen oder von außen. Sie stellen sicher, dass Gruppentreffen eine zielführende Form haben. Moderator ist gewöhnlich 1 Person. Dass eine Gruppe sich selbst durch gleich verteilte "Eingriffe" aller Mitglieder moderiert, ist eher selten. Meist gibt es einen de facto Moderator, der nicht mal ausgebildet sein muss. Dennoch erkennt ihn die Gruppe an.

Dieses Muster ist akzeptiert. Im besten Fall dominiert dieser Moderator die Gruppe nicht, sondern kann eine Balance halten zwischen seinem Mitgliedsstatus und seiner Moderatorenrolle. Er ist nur temporär Erster unter Gleichen in Bezug auf eine Aufgabe.

Ein Moderator verkörpert den Aspekt "Kommunikationsform", ohne dessen Berücksichtigung das Ergebnis einer Besprechung schnell suboptimal ausfällt.

Ich denke auch, wir können uns darauf einigen, dass nicht jeder die Rolle eines Moderators gleich gerne und/oder gut ausfüllt - selbst wenn der Aspekt allen Gruppenmitgliedern wichtig ist. Es braucht dafür eben eine gewisse Kompetenz.

Und wer leuchtet blinde Flecken aus? Die gibt es ja unweigerlich und sei es nur temporär. Wenn die Diskussion hoch her geht, dann fällt der eine oder andere Aspekt gern mal unter den Tisch. Ein Übriges tut dann das Tagesgeschäft mit seinem Druck in Richtung bestimmter Aspekte - und Ignoranz gegenüber anderen.

Einer dieser Aspekte ist aus meiner Sicht die Architektur. Architektur ist ein nicht-funktionaler Aspekt der Softwareentwicklung. Und darüber hinaus auch noch einer, dessen Qualität nicht so schnell zu einem Feedback vom Kunden führt. Wenn die Performance der Software nicht stimmt oder die Usability, dann sagt steht der Kunde sehr schnell auf der Matte. Rückkopplungszeit Stunden oder Tage.

Wenn aber die Architektur nicht stimmt... dann ist die Rückkopplungszeit Wochen, Monate oder gar Jahre. (Ja, ich glaube, man kann nicht-funktionale Anforderungen wie Performancelimits erfüllen, auch wenn die Architektur suboptimal ist. Das passiert sogar häufig.)

Weil nun die Rückkopplung bei der Architektur vergleichsweise lange auf sich warten lässt, fällt sie leicht unter den Tisch. Manager haben dafür oft wenig Sinn. Sie sind es aber, die sich letztlich durchsetzen. Jedenfalls normalerweise. Heute noch ;-)

Bei gegebener schlechter Ausbildung in puncto Softwareentwurf - das schließt für mich Architektur ein - und gegebenem Tagesgeschäftfokus ist für mich die Realität von Teamsitzungen, dass Architektur schnell zu einem blinden Fleck wird. Nicht sofort, nicht immer, aber tendenziell.

Dazu kommt, dass die Kompetenzen, die für den Entwurf von Software-Architektur nötig sind, nicht gleich verteilt sind bei Entwicklern. Es ist damit wie mit den Moderatorenkompetenzen. Das ist also ganz natürlich.

Und daraus leite ich nun wiederum ab, dass es wichtig ist, darauf zu achten, dass der Aspekt Software-Architektur verlässlich verkörpert wird.

Wie diese Verkörperung aussieht, ist mir egal. Es muss keine Position eines Software-Architekten geben. Es muss auch niemand zwangsläufig fix die Rolle eines Software-Architekten innehaben. An irgendwem muss das Thema jedoch hängen, glaube ich. Und zwar nicht am ganzen Team, sondern an einer Untermenge.

Alle sind mit der Plattform und der Domäne und hoffentlich Clean Code Developer ;-) vertraut. Jenseits dessen beginnen dann allerdings die Unterschiede. Es ist immer so, dass einer die GUI-Technologie besser beherrscht als andere. Und eine kann besser mit dem Build-Tool umgehen als andere. Und manche fühlen sich eher zum Umgang mit Datenbanken hingezogen als andere.

Genauso denkt eine konzeptioneller als andere. Und einem ist das big picture wichtiger als anderen.

Ich glaube, diese ganz selbstverständlichen Unterschiede sollten wir nicht leugnen. Wir sollten auch nicht glauben, sie wegschleifen oder auffüllen zu können. Dafür geht gerade das Thema Software-Architektur zu sehr an Persönlichkeitsmerkmale, die schon früh geprägt werden.

Um also nicht davon überrascht zu werden, dass das kollektive Kümmern um Architektur irgendwie nicht funktioniert hat, sollte jedes Teams schauen, dass es möglichst schnell herausfindet, wie es den Aspekt Architektur am besten verkörpert.

Manchmal mag es einen Entwickler geben, der sich den Schuh anzieht - und die anderen sind froh drüber, dass er sie beim Thema an die Hand nimmt. Manchmal mag es eine kleine Gruppe innerhalb des Teams sein. Oder vielleicht rotiert die Aufgabe durch das Team, so dass bei jeder Besprechung ein anderer das "Architektur-Gewissen" ist?

Eine andere Verkörperung muss natürlich in der Zeit stattfinden. Sie muss für alle Entwickler fester Bestandteil ihrer Wochenkalender sein. Das ist der erste Schritt.

In Summe helfen Experimente. Solange die dafür sorgen, dass die Verkörperung der Architektur nicht in eine außerkörperliche Erfahrung ;-) umschlägt, d.h. abhebt und entfremdet von Code und Anforderungen, solange ist alles erlaubt.

Software-Architektur geht alle an. Da bin ich ganz dabei. Allerdings möchte ich daraus ungern eine zwingende Form ableiten: weder eine Position des Software-Architekten, noch die komplette Abwesenheit jeder Rolle oder anderer Form von Kompetenzkonzentration oder Interessenverteilung. Architekturbewusstsein verkörpern, in geeigneter Form, darum geht es.

Solange am Ende das ganze Team ein solides Verständnis der Architektur hat und sie mitträgt, ist alles gut.

Es geht um Organisationsgesundheit

Was soll das eigentlich mit der Beratung, dem Coaching, dem Training? Das frage ich mich immer öfter. Was will ich damit bewirken? Worum geht es dabei in den Softwareteams? Erneuten Anstoß für diese Überlegungen hat mir ein Zahnarztbesuch vor einiger Zeit gegeben.

Dass ein Training WPF Kompetenz aufbaut oder Clean Code Developer Prinzipien vermittelt oder das Scrum-Rad ins Rollen bringt… das ist offensichtlich, aber nicht, was ich meine. Mir geht es um etwas, das dahinter steht. Denn: Warum soll aufgebaut, vermittelt, ins Rollen gebracht werden?

Ein Begriff fällt mir dazu dann immer wieder ein: Zweck. WPF, CCD, Scrum, TFS, .NET 4.5, XMPP, NoSql sind Mittel des Aspektes Softwareentwicklung in einer Organisation, damit die ihren Zweck erfüllen kann.

Nehmen wir als Beispiel ein kleines Softwarehaus. Das arbeitet seit 6 Jahren mit .NET, vorher mit VB. Erst hat der Chef selbst programmiert, jetzt hat er 6 Entwickler (die natürlich auch Support machen), dazu noch einen Mitarbeiter im Vertrieb und noch jemanden fürs Büro.

Was ist der Zweck dieses Unternehmens?

Ich denke nicht, dass die Antwort lautet, "Geld verdienen". Nein, das ist eben nicht der Zweck. Geld ist ebenfalls nur ein Mittel, um den Zweck zu erfüllen. Ein notwendiges Übel.

Ein möglicher Zweck könnte aber sein "CRM-Software für die PR-Branche herstellen". Aus diesem Grund gibt es das Softwarehaus. Das ist seine Bestimmung, mit der es der Inhaber einmal gegründet hat.

Dass "Geld verdienen" nicht zum Zweck gehört, wird Ihnen auch klar, wenn Sie einmal annehmen, dass die Firma immer noch nötig wäre, wenn ein Milliardär auf die Idee käme, sie aus seiner Portokasse einfach so zu finanzieren. Jedes Jahr bekäme der Geschäftsführer einen Scheck über 1.000.000 EUR zugestellt, der es ihm erlaubte, alle Kosten zu decken. Umsatz wäre nicht mehr zu machen. Und dennoch wären weiterhin alle Mitarbeiter nötig; Software würde immer noch geschrieben werden müssen. Denn sonst könnte der Zweck nicht erfüllt werden. Nur könnte die Software dann verschenkt werden.

Leider müssen die meisten Unternehmen ohne einen solchen Mäzen auskommen. Deshalb ist Umsatz nötig. Das bedeutet aber nicht, dass Geld verdienen der Zweck des Unternehmens ist. Der Zwang zum Umsatz ist vielmehr eine zu berücksichtigende Bedingung, unter der der Zweck erfüllt werden muss. Andere Bedingungen sind, dass Software durch Menschen hergestellt wird oder dass sie Marketing braucht, um ihre Anwender zu finden, oder dass jährlich eine Bilanz zu erstellen ist.

Der Zweck von etwas, ist diesem Etwas inhärent. Er gehört zu ihm, klebt an ihm, kommt und geht mit ihm. Deshalb ist auch "Den Lebensunterhalt sichern" kein Unternehmenszweck. Die Formulierung drückt vielmehr aus, dass das Unternehmen von jemandem als Mittel gesehen wird. Damit wird es austauschbar. Wer einen großen Lottogewinn macht, braucht das Unternehmen nicht mehr, um seinen (!) Zweck zu erfüllen.

Mir geht es ja aber eben nicht um den Zweck einer Person (oder ihr Sinnempfinden), sondern um den Zweck einer Organisation. Der kann nur in ihr stecken bzw. aus ihr heraus sich entwickeln.

Nun zurück zur Ausgangsfrage: Was soll das eigentlich mit der Beratung, dem Coaching, dem Training?

Ich denke, dabei geht es immer mehr oder weniger direkt darum, dass eine Organisation ihren Zweck besser erfüllen kann - und zwar im Rahmen gewisser Bedingungen. Innerhalb einer Umwelt bestehend aus einer Vielzahl von Bedingungen soll es der Organisation also besser gehen. Das bedeutet für mich: es geht um Gesundheit.

Ja, genau, mir scheint deshalb, mein Job ist sozusagen der eines Arztes oder Therapeuten für Organisationen.

Damit will ich mir nun keinen besonderen Nimbus andichten und ich brauche weder Kittel noch Stethoskop. Mit der Wahl der Analogie versuche ich lediglich, besser zu verstehen, was Organisationen für Probleme haben und wie die gelindert werden könnten.

Das erste, was aus der Analogie folgt ist - auch wenn es sich nicht schön anhört -, dass, wenn irgendwo der Schuh drückt und "der Berater" gerufen wird… dass dann die Organisation wohl krank ist. Das muss ja nicht immer gleich ein Herzinfarkt sein; Menschen gehen auch mit einem Schnupfen zum Arzt. Aber krank ist eben krank. Die Organisation leidet. Irgendetwas schmerzt - und zwar so sehr, dass man Hilfe sucht.

Aber was ist Krankheit? Oder umgekehrt: Wann ist eine Organisation nicht krank, sondern gesund? Was ist Gesundheit?

Mit der Frage begebe ich mich natürlich in einen Sumpf. Es gibt soviele Definitionen für Gesundheit. Allen voran die der WHO, die so allgemein ist, dass sie mir untauglich erscheint. Denn danach, so scheint mir, kann es keine gesunden Menschen geben:

“Gesundheit ist ein Zustand vollständigen körperlichen, psychischen und sozialen Wohlbefindens und nicht nur das Freisein von Beschwerden und Krankheit.”

Deshalb versuche ich mich einmal an einer eigenen kleinen pragmatischen Definition. Für meine Arbeit als Berater/Coach/Trainer möchte ich ja zumindest eine Chance haben, Gesundheit bei meinen Kunden herzustellen.

Gesundheit braucht Kontext

Zu meinen Gesundheitsbegriff, der ja auch nicht für Menschen, sondern Organisationen gedacht ist, gehört zunächst der Zweck. Gesundheit gibt es nur im Hinblick auf einen Zweck.

Und Gesundheit gibt es nur im Hinblick auf eine Umwelt, d.h. Bedingungen unter denen der Zweck erfüllt werden soll.

Mithin ist Gesundheit ein relativer Begriff. Ob eine Organisation gesund oder krank ist, kann nur beurteilt werden, wenn man Zweck und Umwelt kennt. "Organe" oder Kompetenzen nach einer absoluten Checkliste abzuhaken, kann zu falscher Diagnose führen.

• Analogie Tierwelt: Ist ein Tier krank, wenn es nicht sehen kann? Nicht unbedingt. Wenn es seinen "Lebenszweck" in seiner Umwelt problemlos ohne Sehfähigkeit erfüllen kann, ist es nicht krank, wie der Grottenolm beweist.
• Beispiel Unternehmen: Ist ein Unternehmen krank, wenn es sich nicht mit Social Media auskennt? Nicht unbedingt. Wenn es seinen Zweck in seiner Umwelt problemlos ohne Social Media erfüllen kann, ist es nicht krank. Lebender Beweis ist Schuhmacher Schwartau in meinem Stadtteil in Hamburg.

Gesundheit braucht Funktionstüchtigkeit

Bei gegebenem Zweck in gegebener Umwelt stellt sich natürlich die Frage, ob eine Organisation überhaupt in der Lage ist, ihn zu erfüllen. Kann sie, was immer erforderlich sein mag? Ist die Organisation grundsätzlich funktionstüchtig?

Wenn der Zweck eines Unternehmens Schuhreparatur ist, aber niemand weiß, wie das geht… dann ist das Unternehmen fundamental krank. Ob das eine somatische oder eher eine psychische Krankheit genannt werden sollte, lasse ich mal dahingestellt.

Wenn Schuhmacherkompetenz vorhanden ist, aber das Unternehmen über seine Verhältnisse lebt, also mehr ausgibt als einnimmt… dann ist das Unternehmen ebenfalls krank. Es fehlt ihm die Fähigkeit mit einem Aspekt der Umwelt umzugehen.

Zur Gesundheit gehört also auch, dass Methoden, Techniken, Werkzeuge in geeigneter Weise bedient werden können. Welche das sind, bestimmen nur Zweck und Umwelt. Es gibt keine Pflicht zu Social Media, Cloud Computing, NoSql, Mobile Clients, Kanban, Selbstorganisation usw. Sie sind lediglich Mittel zur Erfüllung des Zwecks unter bestimmten Bedingungen. Und wenn nicht klar erkennbar ist, wie das eine oder andere Mittel den Zweck befördert oder den Umgang mit Bedingungen verbessert, dann muss es nicht genutzt werden.

Zur Funktionstüchtigkeit gehört natürlich auch, dass die "Organe" eines Unternehmens angemessen verbunden sind. Gesunde Organe verpackt in Transplantationsbehälter nützen nichts. Sie müssen in einem Rahmen, Körper, aufgehängt sein, der ihr Zusammenspiel in Hinsicht auf den Zweck befördert. Auch das ist eine Kompetenz der Organisation, auch das ist wiederum ein "Organ".

Krankheit ist somit nicht notwendig das Problem eines Teiles. Wenn das Schuhreparaturgeschäft nicht läuft und der Schuhmacher sich nicht an Damenschuhe herantraut, dann ist die Diagnose einfach, falls das Geschäft nicht läuft. Hier führt ein Teil zur Krankheit des Ganzen.

Wenn aber Schuhannahme, Schuhreparatur und Reparaturausgabe eigentlich kompetent sind und es trotzdem nicht läuft… dann kann es noch daran liegen, wie sie im Firmenrahmen verdrahtet sind. Falls nämlich die Übergabe der Schuhe zwischen den Funktionen mittels eines großen Haufens geschieht, weil die Geschäftsführung kein Geld für Regale ausgeben will… dann kann es zu unschönen Verzögerungen kommen, weil Aufträge nicht geordnet abgearbeitet werden. Hier führt der Rahmen zur Krankheit des Ganzen.

Ein anderes Beispiel für ein Problem im Rahmenwerk könnte sein, dass der Chef verlangt, dass der Schuhmacher jedes Mal, wenn er eine Reparatur beginnt/beendet, zu ihm in den 4. Stock heraufkommt. Es muss doch kontrolliert werden, dass der Schuhmacher immer beschäftigt ist. Wenn der also nicht alle 15-20 Minuten im 4. Stock zu sehen ist… dann trödelt er. [1]

Aber stopp: Ich habe gesagt, dies sei ein Beispiel für ein Problem. Ist das aber gewiss? Die Regel hört sich nicht zweckförderlich an - doch vielleicht gibt es Bedingungen, unter denen sie nicht schädlich für die Gesundheit des Unternehmens ist. Ich denke, dafür müssen wir offen sein, bis wir Zweck und Bedingungen genau kennen. [2]

Gesundheit braucht Kompensationsfähigkeit

Alles wäre ja gut, wenn Zweck sowie Bedingungen einmal klar gemacht werden könnten, um dann einmal die Funktionstüchtigkeit darauf abzustellen.

So ist die Welt aber nicht. Unternehmen laufen nicht auf Schienen. Die Umwelt ist ständig in Bewegung. Am Zweck mag ein Unternehmen von sich aus festhalten können; doch die Bedingungen, unter denen es ihn erfüllen muss, wandeln sich. Mal gemächlich, mal plötzlich.

Zur Funktionstüchtigkeit muss daher noch eine weitere Eigenschaft kommen: Kompensationsfähigkeit. Und eben die habe ich beim Zahnarztbesuch im Gespräch kennengelernt.

Gesund ist ein System, wenn es Störungen kompensieren kann. Sich verändernde Bedingungen sollten die Zweckerfüllung möglichst nicht sofort kompromittieren.

In dieser Hinsicht finde ich die Definition von Gesundheit der WHO unzureichend. Sie sagt, ich sei gesund, wenn ich in vollständigem Wohlbefinden in meinem Bett liege.

Was aber, wenn ich dann aufstehen will und das nicht kann, weil meine Muskeln atrophiert sind oder mein Kreislauf versagt? Klar, dann bin ich nicht mehr gesund. Ich fühle mich nicht mehr wohl. Aber Sekunden vorher war ich es noch still liegend im Bett?

Kaum. Denn wenn mich ein völlig üblicher Bewegungswunsch über die Grenzen meiner Leistungsfähigkeit bringt, dann kann ich nicht gesund sein. Ein gesunder menschlicher Körper kann den Wechsel von Bettruhe zu Aufstehen kompensieren. Ein gesunder Körper kann auch die plötzliche Anforderung, das Ausrutschen auf einer Bananenschale zu kompensieren, mühelos erfüllen. Ebenso kann ein gesunder Körper eingedrungene Schnupfenviren kompensieren.

Gesundheit ist mehr als die Abwesenheit von Schnupfen. Sie ist die Anwesenheit von Kompensationsfähigkeit - so dass Schnupfen gar nicht erst entsteht.

Krankheit im üblichen Sinn ist also erst die Folge eines vorherigen Mangels an Kompensationsfähigkeit. Für mich beginnt Krankheit im unüblichen Sinn deshalb schon früher. Krank ist ein System schon dann, wenn es Kompensationsfähigkeit nicht aufgebaut hat oder verliert.

Wie viel Kompensationsfähigkeit nötig ist, hängt wieder vom Zweck im Rahmen einer Umwelt ab. Hier müssen Annahmen gemacht werden. Von einem Erwachsenen erwarten Sie zurecht, denke ich, dass er den Sturz über eine Bananenschale kompensieren kann. Ein Sturz aus 10m Höhe jedoch liegt jenseits gesunder Kompensationsfähigkeit.

Hier wird nun der Zweck von Angst deutlich. Sie bewahrt uns vor Situationen, die unsere Kompensationsfähigkeit übersteigen. Wir haben Angst, wenn wir am Rande einer 10m hohen Klippe ohne Brüstung stehen; deshalb vermeiden wir solche Situationen oder sind dann zumindest sehr vorsichtig. Aber wir haben keine Angst, unser Haus zu verlassen - auch wenn es sein kann, dass wir auf dem Bürgersteig auf einer Bananenschale ausrutschen.

Kompensationsfähigkeit bedeutet, Puffer zu haben. Das können physische oder psychische sein. Ein physischer Puffer ist Muskelkraft oder Fett. Ein psychischer ist Humor oder ein religiöser Glaube.

Und bei Unternehmen? Da sind zum Beispiel Geld, Motivation, Lagerbestände oder schlicht Überkapazitäten jeder Art Puffer.

Wo Geld vorhanden ist, da kann eine Umsatzdurststrecke abgepuffert werden. Wo Motivation vorhanden ist, da kann eine Auftragsspitze durch Mehrarbeit abgefedert werden. Wo Lagerbestand vorhanden ist, da kann eine Nachfragespitze ohne Verzögerung befriedigt werden. [3]

Zwischenstand

Bei der Beratung im weitesten Sinne geht es aus meiner Sicht immer um die Gesundheit des Unternehmens. Sie soll verbessert werden. [4]

Diese Analogie hilft mir. Ich finde sie pragmatisch. So liefert mir die Analogie z.B. eine Analysecheckliste. Wenn ein Unternehmen über Probleme klagt, kann ich schauen, wo die liegen:

• Mangelt es an Zweckverständnis?
• Mangelt es an Bedingungsverständnis?
• Mangelt es an der Fähigkeit, Bedingungen zu bewältigen?
• Mangelt es an Funktionstüchtigkeit?
• Mangelt es an Kompensationsfähigkeit?

Und daraus kann ich dann "Therapievorschläge" ableiten.

Ebenso ist die Analogie für mich eine Brille, durch die ich auf Tools, Technologien, Methoden, Konzepte schauen kann. Ich kann sie klassifizieren. Ich kann beurteilen, zu welchem Gesundheitsaspekt sie etwas beitragen. Wird mit WPF die Funktionstüchtigkeit erhöht oder das Zweckverständnis? Trägt Scrum etwas zur Bewältigung von Bedingungen bei oder steigt damit die Kompensationsfähigkeit?

Sicherlich hat jede Analogie ihre Grenzen. Aber derzeit glaube ich noch nicht, dass die bei der Gesundheitsanalogie erreicht sind. Sie scheint mir vielmehr gerade in puncto Kompensationsfähigkeit noch einiges zu bieten. Darüber muss ich weiter nachdenken.

Einstweilen können Sie sich ja mal fragen: Wie gesund ist das Team, das Unternehmen, in dem Sie arbeiten?

Fußnoten

[1] Oder ist es müßig, zwischen Rahmen und darin aufgehängten "Organen" zu unterscheiden? Am Ende sind Rahmen und "Organe" ein Ganzes und gleichberechtigt. Ohne Rahmen kein Ganzes, keine Zweckerfüllung nur durch die "Organe". Und ohne "Organe" nützt der schönste Rahmen auch nichts.

[2] In diesem Zusammenhang fällt mir die Agilität ein. Auch wenn ich meine, dass agile Entwicklung gesundheitsförderlich für viele Softwareentwicklungsorganisationen ist, so muss ich offen dafür sein, Zwecke und Bedingungen kennenzulernen, unter denen das nicht gilt. Deshalb ist es mir wichtig hinter die Fassade von Methoden und Konzepten zu schauen. Ich möchte verstehen, Mittel zur Bewältigung welcher Umweltbedingungen sie sind.

Hype entsteht insofern immer dann, wenn Mittel empfohlen werden ohne Ansehen ihrer Bindung an Zwecke oder Bedingungen.

[3] Nach fest kommt ab. Das kennen Sie als Heimwerker, oder? Ich denke, es gilt aber genauso: nach schlank kommt krank.

Denn wo der Schlankheitswahn im Unternehmen um sich greift, wo gekürzt und beschnitten wird, um Kosten zu reduzieren… da kann Gesundheit unbemerkt in Magersucht umschlagen - und der Patient hat typischerweise keine Krankheitseinsicht. Wo Puffer konsequent verkleinert werden, droht die Kompensationsfähigkeit zu leiden - und damit die Gesundheit. Auch und gerade, wenn doch heute noch alles zu funktionieren scheint.

Die nächste Änderung der Bedingungen kommt gewiss… Dann ist die Frage, ob die Organisation sie kompensieren kann.

[4] Ich bin übrigens nicht der einzige, der sich "im Dienste der Gesundheit von Unternehmen" fühlt. Bob Marshall, dessen Blog Think Different ich sehr schätze, bezeichnet sich schon als Therapeut und denkt über organizational health nach.

In dieselbe Richtung zielt das Buch "The Advantage" von Patrick M. Lencioni.

Und auch das Buch "Working Whole Systems" von Julian Pratt et al., das Organisationen als lebendig beschreibt, geht für mich in dieselbe Richtung.

Agil persönlich definiert

In meiner Kritik an Martin Fowlers Absage an die Wissenschaftlichkeit habe ich anklingen lassen, dass ich selbst eine Definition für Agilität hätte. Darauf bin ich nun ein paar Mal angesprochen worden. Nun muss ich wohl Butter bei die Fische machen und sie einmal beschreiben.

Meine Definition

Also gut… Hier sind meine persönlichen Kriterien für agiles Vorgehen oder eine Haltung der Agilität. Sie sind natürlich nicht rigoros im mathematischen Sinne. Das habe ich auch nicht von Martin Fowler erwartet. Aber ich halte sie für klar genug, um mit ihnen in der Hand an ein Projekt herantreten zu können für eine Prüfung, ob es agil durchgeführt wird.

Inkrementell

Die wesentliche Neuerung, die die Agilität in die Softwareentwicklung aus meiner Sicht gebracht hat, ist das Denken in und die Entwicklung von Durchstichen. Software wird nur in nützlichen Inkrementen ausgeliefert. Agilität liefert “Anforderungsscheiben”, d.h. sie macht vertikale Schnitte durch ein Softwaresystem. Als fertig und somit projektfortschrittsrelevant wird angesehen, was dem Kunden etwas wert ist.

Was war vorher? Vorher war die Entwicklung in Meilensteinen. Zum Begriff Meilenstein gehört aber nicht notwendig der Durchstich. Ein Meilenstein kann auch sein “Datenbankschicht fertig” oder “ESB aufgesetzt”. Solche Infrastrukturbelange mögen irgendwie wichtig sein, ohne Datenbankzugriff oder ESB läuft das Softwaresystem nicht. Allerdings interessieren die den Kunden nicht direkt; sie sind nicht nützlich. Er will seine Aufträge bearbeiten, Planungen durchführen, Ressourcen verwalten usw.

Eine Datenbank oder ein ESB sind einfach keine funktionale und auch keine nicht-funktionale Anforderung. Sie sind Mittel zur Realisierung von Anforderungen. Deshalb sind die für sich genommen nicht wertvoll.

Aus meiner Sicht ist es genau diese Unterscheidung, die Agilität vor allem auszeichnet. Den Blick auf die Erfüllung von Anforderungen zu konzentrieren und sich nicht von Mitteln ablenken zu lassen, das macht Agilität für mich aus.

Lernend

Die zweite Neuerung, die Agilität in die Softwareentwicklung gebracht hat, war aus meiner Sicht die Haltung des ewigen Schülers. Wer agil arbeitet, bewegt sich in einer Lernschleife:

1. Herausfinden, was gewünscht ist
2. Inkrement herstellen
3. Überprüfen, ob das Inkrement für den Kunden akzeptabel ist

In der agilen Softwareentwicklung gibt es also keine Phase, die je abgeschlossen wäre.

Agilität läugnet insofern nicht, dass Softwareentwicklung in sequenziellen Phasen abläuft. Man muss zuerst herausfinden, was gefordert ist, dann muss man die Realisierung planen, dann kann man den Plan implementieren [1] und erst danach kann man die Implementierung überprüfen und schließlich abnehmen lassen.

Aus Sicht der Agilität ist nichts gegen solche Phasen zu sagen. Sie sind sozusagen unterhalb des Radars der Agilität. Deshalb kann man aus meiner Sicht auch nicht mit der Agilität begründen, dass man nicht dokumentiert oder entwirft. Agilität wendet sich nicht dagegen. Es ist ihr schlicht egal. Sie sagt: Mach, was nötig ist, um Inkremente heute und in Zukunft zügig herstellen zu können. Denn nur so kann ihr Anspruch des Lernens erfüllt werden.

Zunächst hatte ich gedacht, dass ein wichtiger Baustein der Agilität Iterationen seien. Inzwischen sind für mich Iterationen allerdings nur noch ein Mittel. Und der wirkliche Baustein der Agilität ist das Lernen. [2] Ebenso sind z.B. Scrum Retrospektiven auch nur ein Mittel, um den Baustein Lernen in ein Projekt zu setzen.

Das bedeutet im Umkehrschluss: Agilität ist dort unnötig, wo nicht gelernt werden muss. Wenn glasklar ist, was zu tun ist, wenn es nur marginale Unwägbarkeiten gibt… dann muss man nicht agil sein.

Agilität ist also kein Ansatz für die Produktion, sondern für jede Form von Entwicklungstätigkeit, sei das “bei den Kreativen” oder bei Ingenieuren.

Unmittelbar

Die dritte Neuerung der Agilität ist dann die Betonung der unmittelbaren Kommunikation. Die, die ein Ergebnis sehen wollen und die, die es herstellen sollen, sitzen im selben Boot. Also ist es wichig im Sinne der Lernschleife und zügiger Inkremente, dass diese Beteiligten möglichst barrierefrei Kontakt haben.

Wie das konkret geschieht, ist der Agilität wieder egal. Aber typische Maßnahmen im Sinne der Unmittelbarheit sind cross-functional Teams und co-location. Auch das Verhältnis ProductOwner zu Entwicklern in Scrum ist dafür Ausdruck.

Informationen sollen fließen, Entscheidungen sollen zügig getroffen werden. Bürokratie jeder Art (Hierarchien, Verträge, Dokumente, Konventionen, …) gehört für die Agilität deshalb auf den Prüfstand. Was nicht unmittelbar dem Ziel “Nützliches Produkt” dient, soll weggeschnitten werden.

Meine Hypothese

Agilität zu definieren ist kein Selbstzweck. Eine Definition macht nur Sinn, wenn daraus etwas abgeleitet wird. Eine Hypothese kommt erst zustande, wenn der Definition auch eine Ergebniserwartung zugeordnet wird.

Aus meiner Sicht lautet die Vorhersage der Agilität:

Wer agil Software entwickelt, der hat größere Chancen, bei gegebenen Budgets (Geld, Zeit, Ressourcen) hohen Nutzen für den Kunden herzustellen.

Oder etwas konkreter: Mit Agilität werden weniger Projekte abgebrochen und die Überziehungen werden geringer und das Supportaufkommen fällt auch nicht so hoch aus.

Natürlich ist diese Vorhersage im Komparativ formuliert. Agilität ist ja als Gegenentwurf zu etwas Bestehendem entstanden. Demgegenüber will sie bessere Ergebnisse liefern. Aber sie ist zumindest so “bescheiden”, sich nicht als das Ende der Fahnenstange zu sehen. Zumindest sollte sie das sein, denke ich. [3]

Zusammenfassung

Das war´s. Mehr gehört für mich derzeit nicht zur Definition von Agilität. Bestimmt ist es weniger, als viele von Ihnen erwartet hätten. Mir reicht es aber. Denn mit diesen Kriterien an der Hand kann ich jedes Projekt, jedes Unternehmen beurteilen. Und Sie können das auch. Dafür muss ich Sie nicht “weihen” ;-)

Gehen Sie einfach diese Checkliste durch:

1. Geht es um ein Entwicklungsvorhaben? Stichwort: Kreativität
2. Wird das Ergebnis inkrementell hergestellt? Stichwort: Durchstiche
3. Wird bewusst lernend vorgegangen? Stichwort: Reflexion
4. Sind die Vorhabenbeteiligten in unmittelbarem Kontakt? Stichwort: Kommunikationsfluss

Wenn jede Frage mit eine Ja beantwortet werden kann, dann liegt grundsätzlich Agilität vor.

So einfach ist das :-) Dazu müssen Sie - aus meiner Sicht - nicht Martin Fowler anrufen und fragen, ob er Agilität erkennt.

Sie können jetzt selbst beurteilen, ob Agilität etwas bringt. Wenn ein Vorhaben inkrementell, lernend und unmittelbar durchgeführt wird, aber sich kein Erfolgsmesswert verbessert… dann nützt ihm Agilität nichts. Dann kann man auch wieder wie früher arbeiten, falls das irgendwelche Vorteile haben sollte. [4]

Und Sie können überlegen, ob gewisse Methoden agil sind oder inwiefern sie der Agilität dienen. Fragen Sie, wie sie das Lernen oder die Unmittelbarheit oder die Lieferung von Inkrementen unterstützen.

Wenn Sie mögen, übernehmen Sie meine Definition von Agilität. Und wenn nicht, dann lassen Sie uns drüber reden, was fehlt. Ich behaupte nicht mal, dass sie gut sei jenseits dessen, dass ich sie für mich praktisch finde. [5] Ich sage nur, dass es überhaupt eine Definition ist und damit das Minimum, was wir von einem Ansatz zur Softwareentwicklung erwarten können.

Fußnoten

[1] Wie umfangreich ein solcher Plan ist, sei dahingestellt. Er mag für Triviales quasi nicht existent sein, so dass die Codierung gleich starten kann. Für anderes mag dann aber durchaus etwas Nachdenken/Entwurf angezeigt. Die Agilität sagt nicht, wieviel Planung nötig ist. Das ist nicht ihr Thema. Sie beschränkt sich auf die Anerkennung von Phasen in der Herstellung von Inkrementen. Wieviele und welche Phasen das sind… ist eine Sache des Herstellungsprozesses. Der sieht für Software anders aus als für ein Auto.

[2] Zu meiner Liste von Agilitätskriterien gehörte zunächst auch noch “Haldenreduziert”. Damit wollte ich dem Aversion gegen “B*UF” (Big {Design, Documentation, …} Up Front) Ausdruck geben. Inzwischen sehe ich es aber so, dass auch das nur eine Folge der Lernwilligkeit ist. Große Halden an Anforderungen, Entwürfen usw. erzeugen einfach Trägheit, die das Lernen behindern. Sie reduzieren die Lernschleifenfrequenz.

[3] Vielleicht ist das unnötig zu erwähnen. Denn wenn Lernen ein Bestandteil der Agilität ist und sie sich so minimal definieren sollte, wie ich das hier zunächst mal nur für mich persönlich tue, dann gibt es erstens daran keinen Zweifel und zweitens steht nicht zu erwarten, dass Agilität dann abgelöst würde. Sie wäre vielmehr der Kern von Weiterentwicklungen.

[4] Selbstverständlich gibt es noch eine andere Möglichkeit: Es könnte sein, dass das mit dem inkrementellen, lernenden und unmittelbaren Arbeiten noch nicht optimal ist. Man kann ja besser oder schlechter inkrementell vorgehen usw. Kritik an der Implementation von Agilität darf also sein. Da gibt es Interpretationsspielraum. Und damit gibt es Raum für die Entwicklung der Agilität. Es können sich ja über die Zeit Best Practices herauskristalisieren, die dann in die Definition von Agilität einfließen.

[5] Allerdings impliziere ich, dass meine Definition in Linie steht mit dem agilen Manifest und beliebten Methoden der Agilisten. Das ist für mich ein Hinweis auf eine gewisse Grundqualität.

Pseudowissenschaft Agilität

Was Agilität ist, weiß selbst Martin Fowler nicht zu definieren. Das sagt er in seinem Blogartikel:

[…] lack of rigorousness is part of the defining nature of agile methods, part of its core philosophy. […] Any attempt to define a rigorous process that can be tested for conformance runs contrary to [the agile] philosophy.

Es sei also vergeblich, einen rigorosen Prozess agilen Vorgehens definieren zu wollen. Das entspräche nicht der Philosophie der Agilität, dem agilen Denken.

Ich bin erschüttert.

Was für eine Bankrotterklärung der Agilität! Ausgesprochen von einem Unterzeichner des agilen Manifests.

Damit stellt sich die Agilitätsbewegung das Zeugnis einer Pseudowissenschaft aus: Sie entzieht sich der Falsifizierbarkeit und macht sich vom Urteil von “Geweihten” abhängig. Denn:

• Wo keine Definition, da kein Vergleich der Realität mit einer Definition und also keine (Miss)Erfolgsmessung. Behauptet jemand, agil zu arbeiten, vermisst jedoch den erhofften Erfolg, dann kann nicht überprüft werden, ob er denn überhaupt und wirklich agil arbeitet. Das erschwert die Implementation agilen Vorgehens. Und das leistet andererseits der Leugnung von Misserfolgen bei agilem Vorgehen Vorschub.
• Auch wenn es an einer Definition der Agilität mangelt, ja – wie Fowler sagt - mangeln muss, können Martin Fowler und “der erfahrene Praktizierer” dennoch erkennen, ob agil vorgegangen wird. Ohne Definition von Agilität, bedeutet das allerdings eine Kette von “Weihungen” ausgehend von Martin Fowler (oder vielleicht einem anderen Unterzeichner des agilen Manifests). Denn wie sonst könnte jemand zum “erfahrenen Praktizierer” werden? Ohne Definition kann ja niemand selbst feststellen, ob er/sie agil arbeitet.

Definitionslosigkeit und “I know it when I see it” [Zitat Fowler] sind nun leider die besten Voraussetzungen für Fundamentalismus, Dogma, Abgeschlossenheit, Kritikimmunität.

Nicht, dass wir davon in den vergangenen Jahren nicht schon Anzeichen gesehen hätten. Die Diskussionen mit Agilitätsvertretern konnten immer schon, hm, “intensiv” werden… Aber dass nun der Martin Fowler dafür die Rechtfertigung liefert… Nein, das kann ich kaum fassen.

Was sollen denn jetzt Laien von der Softwareentwicklung denken? Was sollen angehende Informatikstudenten von der Agilität denken? Ich kann das schenkelklopfende Lachen in Universitäten wie Chefetagen schon hören. “Was haben sich die Softwarefuzzis da denn ausgedacht? Meinen, mit dieser agilen Mode etwas besser zu machen – und wissen dann nicht mal zu sagen, was es ist? [ROFL]”

Die Alternative: Wissenschaftlichkeit

Wenn Martin Fowler es nur schwer fiele, Agilität bzw. agiles Vorgehen zu definieren, dann wäre ich ganz bei ihm. Vom agilen Manifest bis zu einer Definition und dann auch noch der Messung des Erfolges von Implementationen dieser Definition… das ist ein weiter Weg.

Doch auch wenn es sich schwierig ausnimmt, sollte man es nicht unversucht lassen, glaube ich. So ist das halt mit der Wissenschaftlichkeit.

Nur mit einem wissenschaftlichen Ansatz kann die Agilität (oder auch Lean usw.) hoffen, jenseits von Glaubensbekenntnissen und Hype und anekdotischen Erfolgen ernst genommen zu werden. All die, auf die sich auch Agilisten gern berufen – von Turing über Parnass bis Kay – sind Wissenschaftler (gewesen). Es stünde der Agilität daher gut zu Gesicht, sich vertrauensvoll in deren Tradition zu stellen. Das heißt, die Agilitätsbewegung müsste ihre Methode oder Philosophie als Hypothese anerkennen.

Denn mehr ist es nicht, was das agile Manifest und alles, was zur Agilität geschrieben wurde, darstellt: eine bloße Behauptung.

Eine wie auch immer (nicht) definierte Methode und Philosophie steht im Raum; ein mehr oder weniger schwammiges Erfolgsversprechen ist daran geknüpft. Und das gilt es nun auf Wahrheit zu überprüfen. Ganz ergebnisoffen. So ist das mit der Wissenschaftlichkeit.

Was immer Agilisten auch behaupten mögen, ist ja ok. Da gibt es keine Grenzen. Das mag grob oder fein sein, konzeptionell oder technologisch, abstrakt oder konkret… Egal. Nur steckt in der Behauptung eben noch keine allgemein akzeptierbare Wahrheit. Die muss erst in einem Diskurs und durch Experimente entwickelt werden. Dazu gehört natürlich eine Messlatte. Das ist eine klare Definition inkl. Ergebniserwartung. Die müssen vorliegen, bevor ein Experiment gemacht wird.

Und dann… dann schaut man, ob die Definition im Experiment implementiert wurde und das vorhergesagte Ergebnis eingetreten ist. Vielleicht hat es geklappt, vielleicht nicht. Dann ist Ursachenforschung zu betreiben. Dabei kann herauskommen, dass die Hypothese angepasst werden muss. Und vielleicht kommt dadurch heraus, dass die Agilität nicht so einfach heilsbringend ist, wie sie gern möchte. Es kann also passieren, dass auch Agilisten etwas lernen müssen.

Aber ist das nicht normal? Ist das nicht im Grunde im Sinne der Agilität? Ach so, das kann man nicht so genau wissen. Denn es gibt ja keine allgemeine Definition.

Fazit

Ich halte ja eine ganze Menge von der Agilität. (Jedenfalls von der, für die ich meine eigene kleine Definition habe. Ob und inwiefern die allerdings mit dem “Gefühl” von Martin Fowler übereinstimmt, weiß ich natürlich nicht. Ich bin von ihm nicht “geweiht”.) Aber ich sehe eine große Gefahr für die Agilität heraufziehen, wenn Martin Fowlers Position allgemein akzeptiert wird. Der Dogmatisierung ist dann nichts mehr entgegen zu setzen. Und das würde sie diskreditieren.

“Die Agilität” täte aus meiner Sicht also gut daran, alle Anzeichen von Immunisierung und Unwissenschaftlichkeit zu zerstreuen. Das mag weh tun, wenn man sich denn endlich mal hinsetzen muss für eine Definition… aber es hilft halt nichts. Auch im Definitionsschmerz kann eine wertvolle Erkenntnis stecken.

PS: Hm… Nun kann es natürlich sein, dass Martin Fowler & Co nicht daran interessiert sind, die Agilität wissenschaftlich zu machen oder einfacher: überprüfbar zu gestalten. Wenn das so ist, na, dann müssen sie das nicht tun. Nur dürfen sie sich dann aber auch nicht darüber beklagen, dass die Ergebnisse gemischt ausfallen und Akzeptanz auf der Strecke bleibt. Wer nicht genau sagen kann, was er meint, der kann eben auch nicht verstanden werden.

Dasselbe gilt übrigens für die Objektorientierung, würde ich sagen. Oder auch SOA. Mit ihnen stehen auch Hypothesen im Raum. Versprechen wurden mehr oder weniger genau, in jedem Fall blumig gegeben. Die Überprüfung allerdings, die fällt schwer.

PPS: Und was ist mit der Clean Code Developer Initiative? Verspricht die nicht auch etwas? Stellt sie nicht auch eine Hypothese dar? Klar. Aber erstens scheuen wir uns bei CCD nicht vor eine Definition. Schon gar nicht glauben wir, dass es CCD inhärent sei, einer Definition zu widerstehen. Zweitens scheint uns die Hypothese von CCD schon recht klar:

• Das Wiki definiert, was man tun muss, um ein CCD Experiment zu starten: Folge den Prinzipien, setze die Praktiken ein. Je mehr, desto besser. Ob das passiert, lässt sich auch von “Ungeweihten” nachvollziehbar feststellen :-)
• Das Wiki formuliert (implizit) als Hypothese: Die Korrektheit, Evolvierbarkeit und Produktionseffizienz steigen, wenn man den Prinzipien und Praktiken folgt. Auch das lässt sich von “Ungeweihten” nachvollziehbar feststellen :-)

Sicherlich könnte die Hypothese noch klarer werden. Wer dazu beitragen will, ist herzlich eingeladen. Grundsätzlich empfinden wir uns aber schon auf dem wissenschaftlichen Weg. Und wenn wir CCD damit “angreifbar” (falsifizierbar) machen, dann ist das völlig ok. Wir stellen das Ziel “bessere Software” über den Weg.

Was andere schon richtig machen – Prinzipien

Das ist Wolfgang Marlie. Er ist Inhaber der Reiterpension Marlie an der Ostsee - und Reitlehrer aus Passion [1]. Von ihm können wir als Softwareentwickler etwas lernen.

Als Reitlehrer ist seine Aufgabe, Reitschüler ans Pferd und aufs Pferd zu bringen. Es geht natürlich um den Spaß mit einem großen Tier. Das macht er, das macht sein Team sehr gut. Die Reiterpension ist auch in diesem Sommer wieder fast ausgebucht.

Der Ansatz, den Sie dafür wahrscheinlich erwarten, ist ein technischer: Ein Pferd ist in einem Reitstil ausgebildet – Englisch, Western o.ä. –, d.h. es kennt eine Reihe von Kommandos, und der Reitlehrer bringt dem Reitschüler diese Kommandos bei. Eins nach dem anderen. In einer didaktisch klugen Weise.

So etwas gibt es bei Wolfgang Marlie auch. Wenn man dringend möchte. Doch seine Philosophie ist eigentlich eine andere. Wolfgang Marlie ist ein Mann des Grundsätzlichen. Ihm geht es nicht einfach darum, Techniken zu vermitteln, sondern auch und vor allem das Warum dahinter. Es geht ihm um den prinzipiellen Umgang mit Pferden.

Das drückt sich in den Gesprächen zwischen ihm und seinen Reitschülern aus. Darin geht es nicht nur darum, wie zum Beispiel ein Signal besser gegeben werden könnte – sondern immer wieder steht die Frage im Raum, warum denn das Pferd überhaupt auf das Signal reagieren sollte?

Wolfang Marlie lehrt zu einem Gutteil also auf der Meta-Ebene. Für ihn gibt es kein gutes Reiten ohne eine gute Beziehung zwischen Mensch und Pferd. Für ihn gibt es keine verlässliche Verständigung zwischen Mensch und Pferd, wenn sie nicht immer wieder abgeklopft, aufgebaut und gefestigt wird. Ihm reicht es nicht, wenn der Mensch scheinbar Techniken beherrscht – eine Sprache bzw. den Hilfsmitteleinsatz. Ohne Prinzipienverständnis und die rechte Haltung ist ihm das hohl. Es mögen sich für den Moment ansehnliche Leistungen dadurch herstellen lassen, doch ob darunter ein nachhaltiges Verhältnis existiert und auch das Tier Freude hat, ist nicht ablesbar.

Sein Unterricht ist daher eine Lehre in kleinen Schritten. Man sollte viel Zeit mitbringen, wenn man sich auf Wolfgang Marlies verständnisvollen wie verständnisorientierten Unterricht einlässt. Der Wechsel zwischen konkretem Tun, der Anwendung von Techniken, und der Reflexion, der Meta-Ebene, dem Lernen lernen und auch dem Lehren lernen… das kostet Zeit und Ausdauer.

Doch der Lohn der Mühe ist ein ganz anderes Verhältnis zwischen Mensch und Pferd. Tiefer, befriedigender, verlässlicher, ruhiger – und damit auch sicherer.

Wo ist der Bezug zur Softwareentwicklung?

Ich denke, wir sollten an die Softwareentwicklung auch so herangehen. Natürlich ist die ganz anders – oder doch nicht? Dort ein Tier, hier eine Maschine. Das ist ein unübersehbarer Unterschied. Aber: dort ist Kreativität und Blick fürs Detail gefragt, hier ist ebenfalls Kreativität und Blick fürs Detail gefragt. Problemlösungen müssen hüben wie drüben gefunden werden. Nachhaltigkeit ist dort wie hier das Ziel. “Störrisch” stellen sich Tier wie Plattform an.

Und genau deshalb sind die Prinzipien so wichtig. Kurzsichtig lässt sich mit Gewalt viel erzwingen. Gerte und Sporen können ein Pferd in die Spur bringen. Und Zeitdruck mit Fokus auf die Funktionalität kann eine Software in die Spur bringen zum baldigen Release. Das geht. Irgendwie. Doch eher früher als später kommt die Retourkutsche: Das Pferd bockt – dann ist mehr Gewalt nötig. Das Vertrauen ist futsch. Die Software stellt sich bockig bei Veränderungen an, Bugreports häufen sich. Das Vertrauen des Kunden ist futsch.

Doch es geht auch anders. Eben mit einem Blick auf die Prinzipien. Warum soll ein Pferd auf ein Signal reagieren? Warum soll eine Software korrekt sein oder sich über Jahre geschmeidig verändern lassen? Weil Reiter bzw. Softwareentwickler es wollen? Oder weil das so in der Natur der Dinge angelegt ist?

Weit gefehlt! Es braucht Verständnis für die dahinter liegenden Prinzipien. Es braucht Zeit und kleine Schritte. Es braucht die ständige Reflexion.

Das hat Wolfgang Marlie erkannt und setzt es schon in der Reitlehrpraxis ein. Das muss die Softwarebranche noch breiter erkennen. Die Clean Code Developer Initiative ist ein Versuch, dafür Verständnis zu wecken und Anleitung für den schrittweisen Einstieg zu geben.

[1] In der Reiterpension Marlie verbringe ich gerade eine Woche Urlaub mit meiner Tochter. Davor war ich mit Stefan Lieser dort während unseres alljährlichen Retreat. Und aufmerksam geworden bin ich auf Wolfgang Marlie durch eine Empfehlung einer anderen Reitlehrerin. Sie sehen, ich bin begeistert, sonst würde ich nicht immer wieder bei den Marlies einkehren. Für mich herrscht dort jedoch eine so angenehme und anregende Lernatmosphäre, dass ich mich gern in die Schülerposition begebe. Ich kann loslassen und selbst lernen. Dadurch tanke ich auf für die Situationen, in denen ich als Trainer gefragt bin. Anregungen für meine Praxis lauern eben an den unwahrscheinlichsten Orten ;-)

Flow-Design contrasted with Object-Oriented Design

In a recent post Carlo Pescio provided his “true” object-oriented solution to a problem. I´d like to take this as an opportunity to contrast it with the Flow-Design approach to software design.

To bring yourself up to speed regarding the problem scenario, please quickly head over to Carlos article. As a teaser just let me show you his diagram to describe the overall situation where a small program is supposed to help:

After briefly presenting the problem, Carlo jumps right into drawing class diagrams. Here´s his final solution:

Unfortunately I can´t glean from it, how his solution is supposed to function ;-) His presentation of the solution is just a static diagram, i.e. a depiction of some structure. However, software mainly is a dynamic beast. It´s supposed to do work, to process data.

This is, why I prefer to do software design differently. So let me explain how I´d tackle the problem.

Abstract problem depiction

I think it´s prudent to speculate about programming language artifacts as late as possible. Wielding classes is programming, is rolling in the dirt of the concrete. Designing, on the other hand is approaching a problem first on a higher level, leaving out details – in order to move forward more quickly and to not fall into the trap of premature optimization.

Yes, in the end all lofty design needs to be attached to nitty-gritty code. But why limit ourselves in such a way right from the start?

Also just a drawing, Carlo´s problem depiction is very concrete. I find it hard to jump to any conclusion from that, like which classes there should be. So I like to first draw the system to design (STD) in a more abstract manner. Here´s my system-environment diagram for the sump problem domain:

As you can see, I introduced a user role: the operator. Carlo did not talk about it, but I think it´s necessary to have at least one user in the picture. Otherwise it´s not clear why there is a STD at all. Someone has to benefit from it, need it for some purpose. Maybe there should be even more users, like the personnel of a plant who depend on the alarm to sound? But I leave them to the imagination of the reader, to not overcrowd the picture ;-)

The operator is not the only relevant “entity” in the environment of the system. There are sensors and actuators the system has to deal with. I call them resources. Whereas a user role depends on the STD, the STD depends on resources. That´s why the lollypop line ending points away from the STD.

Wrapping the environment

Once I identified the basic dependency relationships, I like to remind me that each should be encapsulated in some way. The innards of the STD should not depend directly on the environment, or to be more precise: on infrastructure APIs to communicate with the environment. This would make the system hard to test.

So I put small symbols in my drawing representing user roles and resources as mere aspects of the solution. Aspect to me means “a set of properties that can change independently of others”.

And even though you might not be able to imagine the API of the pump might ever change… there is at least one other kind of pump other than the real pump I want the system to be able to communicate with: a mock-up pump.

When testing the most important parts of the STD, I don´t want to be forced to always connect them to a real pump or any other user role/resource. So there needs to be a way to replace any environmental “entity” with a mock-up. This can be readily accomplished by encapsulating all environmental dependencies in some way.

The rectangles and triangles show me, what I need to do: define an interface for each user role/resource, which then can be implemented by a real API wrapper as well as a mock-up. (If you like to use an abstract class instead, you´re welcome to do so.)

Here are the interfaces for sensors a to e as well as for the pump and the alarm:

Yes, I think only two interfaces are required. All actuators behave the same: the pump needs to be started and stopped, the alarm needs to be started and stopped. And all sensors deliver their current value when asked. That´s the simplest wrapping I can come up with. And that´s an important point for me here: environmental entities should be wrapped as thinly as possible. This is to make it most easy to implement mock-ups and also to make testing usage of the environment APIs as easy as possible.

Carlo differentiates between digital and analog sensors – which nevertheless look the same on the interface level – and then further refines them into gas level sensors and level sensors. I would not have done so – at least not at this point, I guess –, but it´s ok with me. What´s important is that these refinements use composition over inheritance:

Each threshold sensor instance has its own ISensor instance assigned to it – probably by injection upon construction. It´s configured with an appropriate min/max value and the wrapper around the physical sensor:

var a_sensor = new ThresholdSensor(…, new ASensor());

Other than Carlo my classes would be more concrete the closer they are to the iron: I´d go for a ASensor, BSensor etc. classes implementing the simplest interface (ISensor). That way the least mount of code would be in there, i.e. testing would be as simple as can be.

Carlo on the other hand differentiates on a pretty high level of abstraction: a COSensor is a ThresholdGasSensor is a GasSensor [1]. I don´t get, why I should do that – at least not in light of the given requirements. They tell me, there are different sensors. That´s obvious even from Carlo´s first diagram. So what I can speculate about is, whether those different sensors are talked to using the same or different APIs. From that I would derive whether to implement the ISensor interface in a more general manner (e.g. GasSensor) or very specifically for each sensor type (e.g. ASensor etc.).

Beyond that, though, I don’t see there is a difference between sensors. Even the ThresholdSensor class is a convenience class ;-) It makes the common sensor interaction more specific, it introduces a sensor abstraction to gloss over differences. So I´d say, on this level of abstraction all the different sensors are the same. That´s the whole purpose of this class. One logic to rule all specific sensor API wrappers of a certain kind.

Architectural assumptions

Architecture to me is design with regard to non-functional requirements. After getting a view from 30,000 ft on the problem with the system-environment diagram, some thoughts on architecture might be in order. So what are non-functional requirements of Carlo´s sump scenario? And how do they influence structuring the system?

Well, as it seems, nothing much relevant to architecture is imparted by the requirements description. Performance, scalability, usability, security, robustness… no information on these and many other aspects. No details on the sensors or pump or alarm.

So I´m making two aspects up to become a bit more concrete. This is necessary to actually move forward. System structure is a solution to a concrete problem. That means, as long as the problem is not very concrete there is not really a right or wrong structure. Anything goes.

The assumptions I´m going to make are:

• The STD is supposed to run as a service on some computer attached to the sensors. Once the computer is switched on the STD will start doing its work. It will monitor the sump, start/stop the pump as necessary, and issue an alarm in an emergency situation.
• Polling the sensors periodically is enough to deal with changes in gas concentrations and water level. Whether that is every 100 msec or every 60 sec is not that important, I think – as long as processing the data does not take longer than the polling interval.
• Sensor and actuator APIs can actually be wrapped as to conform to the resource interfaces described above. I explicitly neglect any configuration or startup/shutdown ceremony.
• Actuators are wrapped in an idempotent way: switching on a pump that´s already running does not make a difference.

This is how I imagine the setup:

Modeling the solution

Now for the fun part. How should the whole system work? Carlo´s talking about this, but when I look at his blog article I don´t see it. The result of all his work is, well, just a structural diagram. All explanations about functionality are lost.

I deem it no virtue to be able to “reverse engineer” a class diagram to get an idea how things are working. If that´s all you have, a class diagram, well, then you have to do it. But my approach to software design and programming is, to avoid this kind of extra work. Develop software so it can be understood and changed easily. That requires to make functionality, i.e. how things play together, a first class citizen of the design.

This is, why I view software as a set of interactions with its environment. Yes, I´m modelling functionality using interactions or behaviors, not objects. At least objects as “bags of behaviors” are not where I start. My reason is simple: it´s notoriously hard to find such objects in the requirements. Except… yes, except for requirements dealing with real world things. In so far I´d say Carlo´s cheated a bit ;-) when he chose his scenario to demonstrate his object-oriented approach. The scenario makes is particularly easy to arrive at a class decomposition of the problem. For many, many developers, though, it´s not that easy because they deal with totally different stuff.

However, required behavior is always present. Software as a whole is always supposed to do something. So why not start from there? Start with one “thing” a software should upon request from a user role. Whatever has to be done thus is always triggered by some event in the environment. For the sample scenario that´s trivial: the operator starts the sump monitoring service by switching on the computer.

About this picture I can talk with the customer or a user. It´s dead simple. I can ask them, if that´s all to the interaction “Start program” – on this level of abstraction. The program is started with no further information. From then on it just runs…

If everyone agrees I can drill down. What does “Monitor the sump” mean?

It means, this should be done periodically done. That´s a non-functional requirement. So it should show up in my model somewhere.

What has to be done periodically? Reading the sensors aka polling – and then acting on the data read from the sensors. That means the pump has to be switched on/off as necessary. And in case of an emergency the alarm has to be switched on.

I guess I could talk with a user on this level of abstraction, too. He could tell me, if I understood the problem domain correctly. And if´d be interested we could drill down further:

Reading the sensors could be done in parallel. They are independent of each other. And once all the readings are in, they can be packed up in a SensorData structure for consumption by the “domain logic”.

Note the drums next to the process steps. They signify a dependency. The process step depends on a resource, it accesses the resource in some way.

Ah, by the way: did you notice how I “stepped into” process steps. The previous diagram refines the process step “Read sensors” of the diagram above it. And that diagram refines the process step “Monitor the sump” of one diagram before. So what I´m doing here is truly modeling on different levels of abstractions.

No, I´m not using the L-word here. I don´t care much about layers. I never draw a layer diagram to start a software design. It simply does not help me in any way. It´s either trivial to state which layers there are – or limits my freedom in designing a solution.

Now comes the interesting part. How does the monitoring software actually do anything with the sensor data?

There are two “things” in the environment to control: the pump and the alarm.

The pump has to be switched on/off depending on the water level. However, if the methane sensor signals a certain value, the pump needs to be switched off regardless of the water level[2]. Both situations are assessed separately. The combined result then is evaluated to finally decide whether the pump needs to be switched on/off [3].

Whereas the “Read *” process steps do not add anything to the basic interface methods of the sensors, “Switch pump” contains some logic on top of calling the pump interface. But that does not hurt. The functional unit for “Switch pumpt” is easy to test due to IoC. It just knows an actuator interface and thus can be made to work on a mock-up during testing.

And now for the final refinement:

Straightforward, isn´t it? Assessing the gas readings is pure “domain logic”. Does is matter it also gets water level sensor data? No, I don´t think so. That´s trivial excess information. To separate sensor data to deliver it in a more fine grained manner, would not add much at this point. It´s an optimization, if need be.

Abstracting classes from the model

The modeling diagrams show how the solution is going to work. I´d say they can be understood pretty much even by a user, not to speak of a developer. To me they make clear where and when certain decisions are made. And they do so on many levels of abstraction, so I can explain/learn about the system at my pace/according to my needs. No reverse-engineering, no code archaeology necessary.

And the best part is: what you see above is the code to be executed. Almost. And of course on just a high level of abstraction. But nevertheless it´s code.

But how can such bubbles be executed? Well, I´m gonna show that in a future post, I guess :-) For now I´d like to focus on just what Carlo has provided: the model.

To live up to that, though, I need to do one more step. I need to show you the classes my design approach leads to.

Please note: For me classes don´t stand a the beginning of the design process. Rather they are the closing bracket matching the opening bracket of the system-environment diagram. Some classes might be easily gleaned from the requirements. Well, if that´s the case, write them down. Great – but be careful. They´re still lacking justification, until you assigned them functionality. (With the exception of pure data classes.)

That´s why I leave classes out as long as possible. They are abstractions, they are grouping constructs. They bundle “stuff” that belongs closes together than other stuff. So why should I start think about classes before I know what my “stuff” is?

The “stuff” of software is functionality. Or in more technical terms it´s functions, procedures, that means methods. That´s why I start by compiling the methods I need to deliver certain functionality. I do that top-down. And I do it in a cross-cutting way.

So what I´ve presented you so far is an assembly of methods. Each ellipsis can be translated into a method, sometimes a function, sometimes a procedure.

But here´s the trick: only leafs of the tree the above diagrams are spanning need to become methods; the are the actual operations of the software system. Any darkly colored ellipsis stands for such a leaf. The intermediate nodes of the flow network need not be encoded in any 3GL programming language. Their sole purpose is integration.

Here´s an overview of the whole model with operations colored according to class:

As you can see, I cam up with six different classes as work horses for the software system. That is, four of them are in addition to the basic wrapper classes for resources.

Now let me direct your attention to what´s missing: dependencies.

See how the classes each stand pretty much on their own? In Carlo´s class diagram there are so many lines of different kinds going in all directions. Some signify abstractions, some composition. It´s – sorry to say, Carlo – a bowl of spaghetti.

I dare to say that on the other hand the classes I came up with are not less focused in their responsibilities – but less entangled and thus much easier to understand. And there is no controller class either – which was the whole purpose of Carlo´s exercise ;-) Each method in the classes will be small, i.e. easy to test, easy to understand.

The classes are so little connected, I hardly need a class diagram at all. Why should it tell me anyway except for, well, the structure of data? But since the problem scenario hasn´t to do much with data, there is no need for a class diagram. I´m perfectly fine with the above data flow diagram annotated maybe with class names to make it a bit easier to find the methods in the code base.

Inevitable extensions

Two extensions I´ll leave open for now. This article has already gotten quite long.

• Logging
• Pump failure detection

I´d say, as long as it´s easy to add these requirements later on, my design could be considered at least reasonable. We´ll see…

Critique

One argument I can foresee: “What you do, Ralf, is just functional decomposition like in the 1970s. And we know that´s not gonna work.”

Well, yes, that´s a kind of functional decomposition. And I don´t see what´s wrong with that. Since software is about actions, process, behavior, “functions” are what we should be looking for. That´s the very stuff, software is build out of.

That said, I´m not opposed to object-oriented concepts and languages features. Right to the contrary. That´s all nice and well – where it´s appropriate.

As you can see I make use of interfaces. And I like to encapsulate data. And of course what belongs together should go together into a class. Or a component. Or an assembly. Or a process.

But I´m not on the outlook for small virtual machines. Encapsulation of details (state, logic) is great. But it´s an optimization. Trying to start software design with classes thus to me more or less is premature optimization.

If you´re serious about the term “class” then don´t just understand it as a schema. Also view it as an abstraction of functionality, i.e. a name for a group of methods. And like any other class of stuff software classes then are the result of collecting stuff first. Then classifying it. That´s what Linné did. That´s what we as software designers should do.

Some classes might be obvious. But more classes are not, I´d say. They need to be abstracted from functionality. That´s what I´m doing. But because of this approach I´m not doing plain procedural programming.

There´s also another telling trait of my approach: data flow. Procedural programming never used data flows. Flow-charts or structograms relied on global data, not data flowing from step to step. But that´s what I favor. It keeps dependencies local. And it makes it more obvious what´s happening.

Summary

So much for my plea for Flow-Design :-)

This was fun. I finally was able to contrast my approach with a “true” OO approach. The result is looking different in many regards – but at the core there is some overlap. Of course. Carlo and I agree on the need to wrap resources behind interfaces.

However, we view the software world structured differently. He starts with a vision of small virtual machines (objects) whereas I view software as a bunch of processes (integration) made up of smaller and smaller steps (operations).

Now it´s your turn to compare and assess the two approaches. Looking forward to some discussion – if you like.

Footnotes

[1] I´m aware Carlo also ponders the possibility to have just three instances of ThresholdGasSensor. But he seems to favor more specific classes. That´s at least what he chose to depict and thus make his final solution more complicate.

[2] To me it seems Carlo´s design not really caters to this requirement. For him a gas sensor signals either a critical state or not. I have followed him in this so far. But if I think more closely about it, the critical level for an alarm and for switching off the pump might be different. The GasSensor interface might be too limited. But the requirements are not precise on this. So I´ll leave it at that.

Smarter Entwurf mit smartem Tool

Software mit Flow-Design zu entwerfen, finde ich smart. Die Ergebnisse sind leicht verständliche, leicht in Code zu übersetzen und evolvierbar. Papier und Bleistift reichen eigentlich aus. Naja, eine Digitalkamera darf es dann auch noch sein, um die Entwürfe ins Repository legen zu können.

Jetzt waren Stefan Lieser und ich allerdings eine Woche bei einem Kunden zu einer Entwurfssitzung und haben uns von einem Tool begeistern lassen. So ein SMART Board von www.smarttech.com ist echt cool.

Grundlegen technisch gesehen ist ein SMART Board ein virtuelles Whiteboard. Man kann auf dem, was ein Beamer projiziert rummalen. Das gibt es in verschiedenen Ausführungen am Markt.

Im Detail aber macht eben ein SMART Board den Unterschied zum Whiteboard. Man kann nämlich nicht nur auf einem virtuellen Blatt herummalen, sondern auf allem, was projiziert wird. Der Beamer an der Decke sorgt dabei dafür, dass man sich nicht im Licht steht:

Hier zum Beispiel in einem Visual Studio Projekt oder in einem PDF-Anforderungsdokument:

  

Was immer in der Weise annotiert wird, kann zu einem Dokument ähnlich einer PPT-Präsentation ganz leicht zusammengefasst werden. So ergibt sich ein lückenloses Protokoll des Arbeitsfortschritts über Medien hinweg: vom weißen virtuellen Arbeitsblatt über Textdokumente, Spreadsheets bis zur Entwicklungsumgebung oder schließlich der laufenden Anwendung.

Ja, genau, Arbeitsergebnisse mit dem SMART Board vorgeführt, können sofort vom Kunden annotiert werden. Das Abnahmeprotokoll muss dann nicht lange “übersetzt” und getippt werden, sondern besteht aus Schnappschüssen, die “am Objekt” zeigen, was wie anders sein sollte.

Am Ende der Entwurfssitzung haben wir dann die SMART Board “Foliensammlung” als PDF gespeichert und ebenfalls ins Repository getan:

So lag sie jedem Entwickler auch bei der verteilten und asynchronen Entwicklung vor. Und niemand musste Zusatzaufwand treiben für ein Protokoll.

Zum Schluss noch ein besonderes Schmankerl: Was man da so malt am SMART Board ist Vektorgrafik. D.h. die Bildelemente lassen sich gezielt selektieren und verändern. Damit sind auch bei handschriftlichen Notizen sehr komfortable Umgestaltungen möglich.

Für Stefan und mich ist das Fazit: Softwareentwurf ohne SMART Board ist eigentlich nicht mehr zeitgemäß. Ad hoc, flexibel, informell, schnell, medienübergreifend – so geht das mit dem SMART Board. Wir wollen jetzt auch eins…