Knigge für Softwarearchitekten

Anti-Muster: Der Perfektionist

Peter Hruschka und Gernot Starke

Willkommen in der dreizehnten Ausgabe unserer Kolumne rund um Verhaltensmuster von Software-Architekten.

Dreizehntes Muster: Der Perfektionist

Das Leben von Software-Architekten besteht aus einer schnellen (und oft schmerzhaften) Folge suboptimaler Entscheidungen, die oft im Dunkeln getroffen werden. (Philippe Kruchten)

Zur Erläuterung dieses Zitats: Philippe Kruchten arbeitet zurzeit als Professor für Software-Engineering an der Universität in Vancouver. Vorher hat er u. a. das 4+1-Modell für Architektursichten geschaffen, die Architektur des kanadischen Flugsicherungssystems entworfen und Rational Software mit aufgebaut.

Streben nach Perfektion

Sicher kennen Sie die 80:20-Regel, die offiziell Pareto-Prinzip heißt: Auf Entwicklungsaufwände angewandt besagt sie, dass 80 % der Resultate in 20 % der gesamten Zeit eines Projekts erreicht werden. Die restlichen 20 % der Resultate verursachen die weitaus meiste Arbeit. Zwar lässt sich dieses Prinzip für Software-Projekte nicht formal beweisen, aber viele Beispiele zeigen seine Gültigkeit. Wenn also in Ihrem Projekt mal wieder ein vermeintlich kleiner Baustein einen Großteil der Aufwände verschlingt, könnten Sie sich bei Herrn Pareto bedanken – wäre dieser nicht schon vor vielen Jahren verstorben.

Das Pareto-Prinzip ist jedenfalls der Grund, warum Perfektion so fürchterlich teuer und schwierig ist. Perfektionisten tendieren dazu, das Pareto-Prinzip zu leugnen und zu behaupten: „Das trifft bei uns nicht zu, wir haben alles im Griff!“

Im Kontext von Software-Architekturen begehen solche Perfektionisten aus unserer Erfahrung typischerweise folgende Fehler. Sie streben nach

  • perfekter Organisation von Teams und Abläufen,
  • perfekter Dokumentation,
  • perfekten Entscheidungen,
  • perfekten Strukturen, technischen Konzepten sowie perfektem Code.

Bevor wir uns diesen Fehlern zuwenden, möchten wir Ihnen ein Bonmot von Anne Lamot vorstellen (hier zitiert aus: Andy Hunt: Pragmatisch Denken und Lernen – Refactor Your Wetware. Hanser Verlag, 2009, S. 79):

„Perfektionismus ist die Stimme des Unterdrückers, der Feind jedes Menschen. Er engt Sie ein Leben lang ein und macht Sie verrückt […]. Ich glaube, dass Perfektionismus auf der besessenen Vorstellung beruht, dass man nicht sterben würde, wenn man nur sorgfältig genug voranschritte und jeden Trittstein genau träfe. Die Wahrheit ist, dass man ohnehin sterben wird und dass es einer Menge Leute, die noch nicht einmal auf ihre Füße achten, erheblich besser geht als Ersteren und sie bei ihrem Tun auch noch wesentlich mehr Spaß haben.“

Perfektionsfalle „Organisation“

Organisation umfasst Menschen – und die sind alles andere als perfekt. Manchmal sollen sogar einige schlecht gelaunt sein oder von Vorgaben abweichen. Das vom Perfektionisten so gründlich geplante Schema wird – das garantieren wir Ihnen – an Menschen scheitern (wenn nicht an Ihren eigenen Menschen, dann an den Menschen in Ihrer Umwelt). Das ist übrigens einer der Gründe, warum so viele Organisationen mittlerweile auf agile Entwicklungsprozesse umgestiegen sind: weil sie dabei nicht auf perfekte Organisation bauen müssen, sondern pragmatische Abweichungen und Fehler gut abfedern können.

Perfektionsfalle „Dokumentation“

Perfektionisten können sich beliebig lange mit Dokumentation aufhalten. Hier noch ein paar Rechtschreibfehler beseitigt, dort noch eine Leerzeile eingefügt. Noch ein weiteres Diagramm, um die drei vorherigen etwas abzurunden …

Für Software-Architekten sollten Nachhaltigkeit und Verständlichkeit wichtige Ziele sein, zu deren Erreichung oftmals Dokumentation weiterhilft. Aber: Gestalten Sie Dokumentation pragmatisch und an den konkreten Bedürfnissen Ihrer Stakeholder orientiert. Dokumentieren Sie sparsam und holen Sie regelmäßig Feedback Ihrer Leser ein – Herr Pareto wird sich freuen.

Perfektionsfalle „Entscheidungen“

Das größte Problem perfektionistischer Software-Architekten bilden Entscheidungen: Für perfekte Entscheidungen müssen sie vollständige Ausgangsinformationen besitzen und alle Konsequenzen vollständig ermitteln.

Leider funktioniert in der Praxis weder das eine noch das andere: Sie werden niemals so lange Zeit und so viel Geld von Ihrem Projekt bekommen, um wirklich alle Einflüsse und die Konsequenzen aller Entscheidungen bestimmen zu können. Oftmals ist eine suboptimale Entscheidung heute viel besser für das Gesamtergebnis als eine optimale Entscheidung in sechs Monaten.

Perfektionsfalle „Sourcecode“

Natürlich soll der Sourcecode Ihrer Systeme sauber, verständlich und korrekt sein, Bezeichner vernünftig gewählt, Styleguides eingehalten sowie eine gute Testabdeckung erreicht werden. Aber jegliches Refactoring sollte ein Ende haben, wenn die Systemziele (Geschäftsziele, Architekturziele) erreicht sind. Perfektionisten verbessern um des Verbesserns willen. Das kostet viel Zeit und zehrt an den Nerven aller anderen Projektbeteiligten.

Fazit: Sauberer Pragmatismus

Statt Perfektionismus möchten wir Ihnen sauberen Pragmatismus empfehlen: Arbeiten Sie systematisch und methodisch, aber lassen Sie bei Bedarf auch technisch suboptimale Lösungen zu. Besitzen Sie den Mut, auf Perfektion zu verzichten!

Perfektionisten nerven gewaltig. Sie verhindern, dass Mitarbeiter pünktlich nach Hause gehen können, und sorgen für schlechtes Gewissen – zwei Dinge, die wir persönlich nicht leiden können.

Zum Abschluss noch ein Zitat – diesmal von Kevin Survance: „Great architects focus on what drives business success – Only business results matter.“

Peter Hruschka und Gernot Starke haben vor einigen Jahren www.arc42.de ins Leben gerufen, das freie Portal für Software-Architekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Software-Architektur, Software-Entwurf und Entwicklungsprozesse. Mehr finden Sie unter www.systemsguild.com (Peter) und www.gernotstarke.de (Gernot). Seit Jahresanfang ist Gernot auch innoQ Fellow.
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.