Ohne selbst zu bauen und zu ändern, kann man Software nicht entwerfen

• An der tatsächlichen Gestaltung großer Systeme können nur Ingenieure mitwirken, die den betreffenden Code selbst bearbeiten, abstrakte Ratschläge sind meist bedeutungslos
• Allgemeine Designratschläge (generic design) werden oft gegeben, obwohl man die Codebasis nicht kennt und nur die Domäne versteht
• In der Praxis sind konkrete Einschränkungen und die Wahrung von Konsistenz viel wichtiger als Designprinzipien, und entscheidend ist das Verständnis des aktuellen Zustands des Codes
• Beim Entwurf neuer Systeme oder bei Entscheidungen über die technische Ausrichtung eines ganzen Unternehmens können allgemeine Designprinzipien teilweise nützlich sein
• Doch architektenzentrierte Designstrukturen, die vom praktischen Geschehen getrennt sind, scheitern leicht, und die Person, die ein Design vorschlägt, sollte die Verantwortung für das Ergebnis tragen

---

Grenzen allgemeiner Softwaregestaltung

• Für den Entwurf großer Systeme ist ein tiefes Verständnis der konkreten Details des Codes unverzichtbar
  • Abstrakte Ratschläge helfen bei der Lösung realer Probleme kaum
  • In der Praxis ist Konsistenz (consistency) wichtiger als „gutes Design“
• Da reale Codebasen komplex sind und unvorhersehbare Folgen erzeugen, sind die wählbaren Implementierungswege für sichere Änderungen begrenzt
• Große gemeinsam genutzte Codebasen befinden sich immer in einem Zwischenzustand, in dem mehrere Designs vermischt sind; wichtiger als ein ideales Ziel ist der aktuelle Grad der Verkopplung im Code
• Da bei den meisten Systemen ein vollständiges Rewrite unmöglich ist, muss man sich auf interne Konsistenz und die Sorgfalt der Ingenieure verlassen

Merkmale konkreter Softwaregestaltung

• Effektive Designdiskussionen entstehen in Gesprächen zwischen wenigen Ingenieuren, die das System täglich bearbeiten
  • Dabei geht es nicht um allgemeine Prinzipien, sondern um konkrete Kontexte wie die Detailstruktur des Systems oder Datenflüsse
• Diskutiert wird zum Beispiel nicht „Ist DRY gut?“, sondern eher feingranular technisch, etwa: „Kann diese Funktion in Subsystem A untergebracht werden?“ oder „Sind Informationen aus B im Kontext von C zugänglich?“
• Wichtige Beiträge bestehen darin, kleine Missverständnisse oder die Detailauswirkungen von Codeänderungen zu korrigieren

Wann allgemeine Designratschläge nützlich sind

• Beim erstmaligen Entwurf eines neuen Projekts sind allgemeine Prinzipien nützlich, weil es noch keine konkreten Einschränkungen gibt
• Wenn die Wahl zwischen mehreren Implementierungsoptionen schwerfällt, können allgemeine Prinzipien als Entscheidungskriterium (tie-breaker) dienen
• Sie helfen auch dabei, Konsistenz auf Unternehmensebene zu wahren; das ist eine der formellen Rollen von Softwarearchitekten
• Auch bei weitreichenden Technologieentscheidungen wie Cloud vs. On-Premises, AWS vs. Azure können allgemeine Prinzipien als Orientierung dienen, dennoch dürfen konkrete Einschränkungen nicht ignoriert werden

Architekten und das Problem des „lokalen Minimums“

• Viele Unternehmen geraten in abstrakte, architektenzentrierte Designstrukturen ohne Praxiserfahrung vor Ort
  • Dieser Ansatz wirkt auf den ersten Blick effizient, führt in Wirklichkeit aber zu Designs, die die Ingenieure vor Ort nicht umsetzen können
• Da Architekten nicht selbst implementieren, fehlt oft Verantwortung für das Ergebnis (skin in the game)
  • Wenn ein Design erfolgreich ist, können sie den Ruhm beanspruchen; scheitert es, kann die Ausführung dem Umsetzungsteam angelastet werden
• Solche Strukturen neigen dazu, formale Designaktivitäten stärker zu fördern als tatsächlichen Wert

Fazit und Vorschlag

• Nützliche Designdiskussionen finden als konkrete Gespräche auf Code-Ebene statt, und der Designer muss mit der Codebasis vertraut sein
• Allgemeine Architekturprinzipien sollten auf den Entwurf neuer Systeme, die Unterstützung detailbezogener Entscheidungen in bestehenden Systemen und die Festlegung der technischen Richtung auf Unternehmensebene beschränkt bleiben
• Wer ein Projektdesign vorschlägt, sollte Verantwortung für dessen Erfolg und Misserfolg tragen, und Ingenieure, die tatsächlich am Code arbeiten, sollten die Hauptakteure des Designs sein
• So können Menschen, die das reale System verstehen und deployen können, als die eigentlichen Designer anerkannt werden

[cshj55]

Darum sagen die Gurus dieser Tage wohl, dass Berufseinsteiger Agenten viel besser nutzen. Es hat ihnen lange gutes Geld eingebracht, deshalb verlernen sie es nicht.

[khris]

In der tatsächlichen Arbeit sind konkrete Einschränkungen und die Wahrung von Konsistenz viel wichtiger als Designprinzipien, und entscheidend ist, den aktuellen Zustand des Codes zu verstehen.

Das ist genau meine übliche Überzeugung, da wird mir ganz warm ums Herz.

[coremaker]

Lässt sich das angesprochene Problem nicht ausreichend lösen, wenn man den Prozess zur Vervollständigung der Architektur verbessert?

[GN⁺]

Hacker-News-Kommentare

• Es wird eine Situation beschrieben, in der es in Team-Meetings nicht um Dinge wie „Ist DRY besser oder WET?" geht, sondern um Diskussionen über komplexe Abhängigkeiten wie: „Können wir diese Funktion in Subsystem A unterbringen? Nein, dort gibt es die Information B nicht, und um sie offenzulegen, müssten wir D neu schreiben …"
  Als vertrautes Bild werden scherzhaft mehrere fiktive Systemnamen aufgezählt, und am Ende wurde ein YouTube-Link angehängt

  • „Wingman" ist schon lustig. Aber es gibt immer noch viel zu viele Softwareprodukte, die ISO8601 nicht unterstützen. Selbst Git ist nicht vollständig kompatibel
  • Das wirkt wie eine zu realistische Satire. Idealerweise sollte ein Team nur für einen einzigen Service verantwortlich sein. Aber heute lebt man eher in einer Zeit, in der ein Entwickler gleich vier Microservices betreut, was ziemlich ermüdend ist
  • Solche Situationen entstehen oft, wenn Programmierer auch das Design von Business-Systemen übernehmen. Eigentlich sollten Systemanalysten das Design anführen

• Ich entwickle seit 30 Jahren, habe aber kaum je erlebt, dass tatsächlich konsequent Aufwand in Design und Architektur investiert wird
  Die meisten „Architekten" entwerfen nicht selbst, sondern Senior-Entwickler machen den Entwurf und holen sich nur Feedback
  Bei einer durchschnittlichen Betriebszugehörigkeit von zwei Jahren entwirft man oft Systeme, von denen man nur einen Teil versteht, und der Architekt gibt am Ende häufig nur noch seine Freigabe

  • John Ousterhout behandelt dieses Problem in Vorlesungen in Stanford und hat es im Buch 『A Philosophy of Software Design』 vertieft. Es gibt auch ein Vortragsvideo
  • Ich war einmal in einem Projekt mit einem „Architekten", aber in Wirklichkeit war das jemand, der nur Meetings macht. Wirkliche Design-Beratung gab es nicht
  • Zwei Jahre reichen aus, um ein Subsystem komplett umzubauen oder zu ruinieren. So schnell verändert sich Software heute
  • In 2–3 Jahren kann man eine Codebasis mit 50–100 Personen ziemlich tief verstehen. Wenn man danach die Chance bekommt, Verbesserungen an der Architektur anzustoßen, kann ein Unternehmen technisch wachsen. Die Rolle eines Architekten sollte darin bestehen, solche Ideen zu koordinieren und Konsistenz zu sichern

• „Generic Software Design" ist nützlich, um die Richtung der Implementierung festzulegen. Es bietet eine gemeinsame Sprache und einen gemeinsamen Rahmen, die das Lösen von Problemen erleichtern
  Aber die tatsächliche Implementierung kann vom Plan abweichen. Wie in Naurs Programmier-Theorie liegt das echte Wissen eines Systems im Kopf der Entwickler

• Die Aussage „In großen Codebasen ist Konsistenz wichtiger als gutes Design" ist genau die Falle dieser verallgemeinerten Ratschläge
  Wenn man nur Konsistenz betont, bleiben schlechte Gewohnheiten einfach bestehen

  • Bei uns ist das Gegenteil das Problem: zu viel Freiheit. Jeder baut auf seine eigene Weise, sodass sich hier ein Stück Redux und dort eine andere Query-Library mischen. Am Ende wird die Wartung nur schwieriger
  • Das ist nicht bloß ein Problem der Codequalität, sondern ein Thema der Effizienz der gesamten Organisation. Mit Konsistenz entwickelt man schneller, Reviews und Onboarding werden leichter, und Bugs lassen sich auf einmal beheben
  • Bei diesem Satz habe ich kurz zusammengezuckt. Wenn man den Text aber zu Ende liest, liegt das Wesen von Konsistenz in Einheitlichkeit und Korrektheit
  • Konsistenz sollte erhalten bleiben, aber schrittweise Verbesserung ist wichtig. Es ist gut, bei jeder Codeänderung kleine Verbesserungen mitzunehmen und so „einfache Siege" zu sammeln
  • Die Aussage „Konsistenz ist wichtiger als gutes Design" widerspricht der Boy Scout Rule. Wenn man nur auf Konsistenz schaut, endet das schnell in einer umfassenden Refaktorierung, was riskant ist

• Auf der einen Seite gibt es den realitätsfernen „Architekten", auf der anderen den Real Programmer, der nur auf Detailoptimierung fixiert ist
  Beide Extreme sind problematisch, und wer Entscheidungen trifft, muss sowohl Details als auch Kontext verstehen
  In diesem Zusammenhang wird auch The Story of Mel erwähnt

• Ich stimme der Aussage zu: „Die Person, die das Design gemacht hat, sollte auch Verantwortung für Erfolg und Misserfolg des Projekts tragen"
  Das sollte auch für die Person gelten, die die Entwicklungsmethodik gewählt hat. Ein Scrum Master trägt nicht dasselbe Verantwortungsgefühl wie ein Lead Engineer

• Die besten Apps, an denen ich mitgearbeitet habe, hatten drei Merkmale

  1. Sie legten Wert auf einfache und effektive Systeme
  2. Die Entwickler verstanden als tatsächliche Nutzer selbst alle Anwendungsfälle
  3. Es gab die Autonomie, entdeckte Probleme sofort zu beheben
     Diese Freiheit steigerte sowohl die Zufriedenheit der Entwickler als auch die Produktqualität

• Meiner Erfahrung nach ist die Fixierung auf Konsistenz in großen Codebasen eher ein Fehler
  Jedes Modul hat andere Anforderungen, daher sollten sich auch Teststrategie und Benennung unterscheiden

• Im Idealfall sollten Entwickler auch tatsächliche Nutzer der Software sein, die sie bauen
  Dann spüren sie Fehler oder Unbequemlichkeiten direkt und haben einen stärkeren Anreiz, Verbesserungen vorzunehmen

  • Entwickler brauchen einen direkten Kanal zu den Problemen der Nutzer, ohne erst durch den Kundensupport gehen zu müssen. Tickets, Foren oder soziale Netzwerke liefern wertvolle Einsichten
  • Dass XP den Kunden ins Team eingebunden hat, war eine großartige Idee. Ihn durch einen Business-Vertreter zu ersetzen, war eine der Erbsünden von Scrum

• Ein separater Softwarearchitekt, der nicht an der Wartung beteiligt ist, ist unrealistisch
  Projekte verändern sich ständig, daher hilft eine Rolle wenig, die nur aus der Distanz Anweisungen gibt

  • Ich habe noch nie ein Unternehmen mit so einer Rolle erlebt. Komplexe Software ist wie eine laufende Schachpartie. Strategische Prinzipien sind nötig, aber Ratschläge ohne Kenntnis des tatsächlichen Brettstands sind bedeutungslos