Schauderhaft

Rainer Eschen beschreibt in einem aktuellen Blog Artikel die Probleme in der Kommunikation zwischen Architekten und Entwicklern:

The architect tries to limit project risks. So, she uses future-proofed designs containing abstractions. This can help to reduce maintenance efforts. But, when presenting such designs to developers, you may be surprised by bad attitude: “This is too complex to implement”.

Ganz richtig stellt er fest, dass Kritik von Entwicklern an einem Architekturentwurf auf Fehler in der Architektur hindeuten können, und dass es zu den Aufgaben des Architekten gehört auf die Entwickler zuzugehen, für die Architektur zu werben und sie z.B. mit Hilfe von Beispielen zu erläutern. Ebenfalls richtig: Entwickler lernen abstrakte Entwürfe zu verstehen und in Code zu gießen:

Architects may have to separate the design into different and simpler views. To present concrete examples, that describe all the abstractions, can help here. There are two aspects in it: the current requirements and their concrete realization – to find examples for this is easy – and examples that show how the future can be, to give an idea of reusability. For this you’ve to read between the lines of your customers and may use requirements experiences from the past to get realistic examples.

Aber bei all dem fehlt ein wesentlicher Punkt, eine wesentliche Aufgabe des Architekten: Eine Architektur zu entwerfen, die den Fähigkeiten der Entwickler entspricht. Was hilft eine wunderbares Design? Das elegant all die technischen Probleme löst, die das Projekt zu bewältigen hat, erweiterbar und zukunftssicher ist? Wenn die Entwickler nicht in der Lage sind es zu implementieren? Jeder Architekt, der immer wieder auf Unverständnis bei den Entwicklern stößt sollte sich dringenst fragen, ob das Design nicht vereinfacht werden kann. Ob nicht ein einfacheres Design bis auf weiteres ausreichend ist. Gegebenenfalls um es später durch Refactorings zu verbessern, wenn die Entwickler ihre Erfahrungen gesammelt haben und selbst erkennen können, wie ein abstrakteres Design ihnen helfen könnte.

Und jeder der im Jahre 2008 ein Team mit Entwicklern und Architekten hat, sollte sich dringend fragen, ob er nicht wichtige Entwicklungen in der Branche verpasst hat. Wieso implementiert der Architekt seinen Entwurf nicht zusammen mit einem Entwickler.  Wer könnte es schneller und zuverlässiger implementieren, als derjenige, der es im wesentlichen erdacht hat? Wie ließe sich das Verständnis für die Architektur besser schulen, als bei ihrer Umsetzung beteiligt zu sein?

In meiner Erfahrung eine der ‘Lehren’ aus agilen Prozessen, die wirklich Früchte tragen, wenn sie gelebt werden: Einerseits Pairprogramming als Mittel den Code zu verbessern und Teammitglieder zu coachen und andererseits das Verständnis, dass es nicht um ‘meine Aufgabe / deine Aufgabe’ im Projekt geht, sondern darum Probleme zu lösen. Wenn Architekten und Designer getrennt sind von der Gruppe der Entwickler führt dies fast immer zu mehr oder weniger starker Abgrenzung. Nur zu schnell wird eine kleine Schwäche im Design, egal ob real oder eingebildet, als Zeichen der Unfähigkeit des Architekten erkannt, wenn man die Frau nur vom Telefon kennt. Ganz anders, wenn man gemeinsam vor dem Rechner gesessen hat und gegenseitig gesehen hat, was der andere kann.

Also erzeugt keine Gruppen in eurem Projektteam wenn ihr nicht müsst. Es gibt keinen Grund Architekten und Entwickler personell oder womöglich sogar räumlich zu trennen. Die Kollegen, die schneller, bessere Designs liefern werden sich auch ohne formalle Trennung um eben dies kümmern können, aber werden dabei nicht durch vermeidbare Kommunikationsprobleme behindert. Davon gibt es genügend, die nicht oder nicht so einfach zu vermeiden sind.

2 Responses to “Architekten und Entwickler”