Die Weite des Merkmalhorizonts

Golo will die räumliche Nähe für Teammitglieder nicht weiter überschätzen, Ilker will sie nicht unterschätzen. Mit seinem “Gemeinsam für die gemeinsame Sache” drückt er sogar aus, dass bei räumlicher Distanz keine Gemeinsamkeit mehr ent-/bestehen könne.

Ja, was denn nun? Golos Fahne folgen in das bisher weniger erforschte Land verteilter Teams oder eher in der bisherigen Reisegruppe der Colocated Developers bleiben und Ilkers Regenschirm folgen?

Wie schon hier ausgeführt, plädiere ich für eine “werteorientierte” Diskussion. Niemand sollte sich also aus Sympathie oder Antipathie für den einen oder andere Proponenten in diese oder jene Richtung wünsche. Ohne Zorn und Eifer ist vielmehr zu entscheiden, wie für den Kunden und (!) – das ist mir wichtig – die einzelnen Projektbeteiligten eine möglichst große Befriedigung von Bedürfnissen erreicht werden kann.

Ist jetzt nicht aber schon alles zum Thema gesagt? Nein, mein Gefühl ist, dass die Diskussion nicht wirklich weiter kommt. Sie verharrt in der Emotionalität. Da helfen auch nicht die wiederholten Verweise auf die Autoritäten oder die eigenen Erfahrungen. Denn ohne Wertesystem, ohne Beurteilungssystem, bleiben Autoritäten und eigene Erfahrungen im anekdotischen. Denn wir sollten uns im Klaren sein, dass die Diskussion von keiner Seite wissenschaftlich geführt wird. Experimente, die das eine oder das andere belegen und dann auch noch erklären, warum das so ist, sehe ich nämlich nicht. Dazu braucht es nämlich mehr als persönliche Erfahrungen der Art “Dort haben wir verteilt gearbeitet und es war scheiße. Heute arbeite ich colocated und alles ist gut.”

Wie kommen wir also weiter? Ich würde sagen, wie sollten einfach auf jedes Plädoyer verzichten. Es geht nicht um ein endgültiges Urteil, ob Nähe oder Distanz einfürallemal besser sei. Die Welt ist leider nicht so einfach, dass wir an Colocation (oder “versprengte Teams”) einen Haken machen können. Neue Situationen erfordern immer wieder neue Beurteilungen. Und selbst eingefahrene Situationen können von einer Neubeurteilung profitieren.

Die Frage “Wenn es im Team hakt, könnte das an der Colocation liegen?” ist genauso berechtigt wie “Wenn es im Team hakt, könnte das daran liegen, dass es versprengt ist?”

Um das aber denken zu können, muss man einen weiten Horizont haben; man muss sich über die Natur von Qualität Gedanken machen. Hier eine Analogie:

Wenn Software allein auf einem Prozessor läuft, ist sie am schnellsten. Multithreading macht Software also ga-ran-tiert langsamer.

Ist Multithreading deshalb nicht per se schlechter als Singlethreading?

Wie kann es da jedoch sein, dass Windows und Mac OS und Linux und Unix Multithreading-Betriebssysteme sind?

Die Antwort ist ganz einfach: Weil es kein so einfaches, pauschales "schlechter" gibt. Gut und schlecht sind Ausdrücke für Qualität. Qualität ist die Ausprägung eines Merkmals im Hinblick auf eine Anforderung. Performance ist aber nur ein Merkmal von vielen für Software. Responsiveness, Usability, Scalability usw. sind andere Merkmale. 

Multithreading kann daher sehr wohl Sinn ergeben, wenn man nicht nur starr auf das Merkmal Performance blickt, sondern auch andere in den Blick nimmt. Das tun Betriebssysteme. Sie nehmen geringere als optimale Performance für ein Programm in Kauf, um dem User z.B. auch noch Responsiveness zu bieten.

Die Qualität eines nicht trivialen Produktes insgesamt ist somit immer die Summe der Qualitäten vieler Merkmale. Selbst beim Kauf eines Mixers haben Sie bestimmt einen weiteren Merkmalhorizont als den Preis. Sie werden auch noch Anforderungen an die Merkmale Lautstärke, Umdrehungszahl, Fassungsvermögen, Usability usw. haben.

Als mündiger Konsument werden Sie deshalb…

1. Ihren Merkmalhorizont bestimmen
2. Für jedes Merkmal Ihre Anforderung spezifizieren
3. Den ersten Mixer kaufen, der Ihren Anforderungen entspricht

Das ist ein effektives wie effizientes Vorgehen – und besonders befriedigend in Situationen mit unübersichtlichem Angebot.

Nicht den billigsten Mixer zu kaufen, kann sinnvoll sein. Software nicht mit Singlethreading zu betreiben, kann sinnvoll sein. Und ein Team nicht in einem Raum “zu betreiben”, kann sinnvoll sein.

Ob und wann es sinnvoll ist, ein Team zu verteilen, das hängt davon ab, wie Ihre Anforderungen sind. Nicht Golo, nicht Ilker, nicht Martin Fowler bestimmen das, sondern allein Sie.

Lassen Sie sich nicht von emotionalen Appellen beeindrucken. Anekdotische Berichte sind gut, wenn Sie sie für das nehmen, was sie sind: persönliche Erfahrungen in ganz bestimmten Kontexten. Nicht mehr, nicht weniger.

Ihre Situation ist aber anders. Sie mag der von Golo oder Ilker ähneln. Letztlich ist sie jedoch immer anders. Verantwortlich handeln Sie daher nur, wenn Sie die Merkmale kennen, die effektive und effiziente Softwareentwicklung ausmachen und zu jedem Ihre Anforderungen formulieren. Und dann müssen Sie ganz bewusst bestimmen, inwiefern Colocation oder Verteilung in welcher Form diesen Anforderungen genügen.

Mit welchem Arbeitsmodus maximieren Sie die Gesamtqualität der Softwareentwicklung?

Sehen Sie diese Diskussion daher als Horizonterweiterung an. Sie will einen Impuls geben. Seien Sie nicht einfach so mit Ihrer bisherigen default Entscheidungen für Colocation zufrieden, die womöglich keine war, weil Sie sich nie Gedanken über Alternativen gemacht haben. Hinterfragen Sie sie. Es besteht die Chance, dass ein anderer Arbeitsmodus Vorteile hat. Geben Sie der Möglichkeit, dass Motivation und Kompetenz durch Verteilung steigen könnten, eine Chance. Mehr hat Golo nicht gewollt. Mehr will ich auch nicht.

Hinterfragen Sie nicht nur immer das Neue kritisch. “Kann die neue Technologie XYZ beweisen, ob sie wirklich Vorteile hat?”

Hinterfragen Sie auch das Etablierte. “Was verschenken wir, wenn wir weiterhin auf Colocation und 9-15h Kernarbeitszeit von Mo-Fr bestehen?” Das ist eine legitime Frage. Das ist eine Frage, die sich jeder bewusste Manager stellen sollte.

Und wenn man dann vor einem weiten Horizont an Qualitätsmerkmalen die Situation und die Alternative beleuchtet hat und entscheidet, alles bleibt beim Alten… dann ist es auch ok.

Und jetzt hoffentlich Schluss mit der Diskussion. Machen Sie etwas draus. Allerdings: “Unschuldig” sind Sie nun nicht mehr. Die alternativlose Ruhe ist vorbei. Sie können nicht mehr behaupten, Sie hätten nichts davon gewusst, dass es auch anders erfolgreich (oder gar erfolgreicher) geht. Es gibt mehr als Singlethreading. Es gibt mehr als Colocation.