Softwarearchitektur: Wir kämpfen gegen Trägheit und passive Akzeptanz

Heidi Waterhouse hat zusammen mit einem Team weiterer technischer Redakteure das Buch "Docs for Developers: An Engineer's Field Guide to Technical Writing" geschrieben. Darin verarbeitete sie ihre Erfahrungen als technische Redakteurin bei Startups aber auch Dell und Microsoft. Nach fünf Jahren als Gründungsmitglied von LaunchDarkly wandte sie sich der Interessenvertretung von Entwicklern zu. Ihr aktuelles Buchprojekt befasst sich mit progressiver Bereitstellung und der Zukunft der Beobachtbarkeit.

heise Developer: Sie sprechen in einem Vortrag auf dem iSAQB Software Architecture Gathering von den "Seven Righteous Fights". Gegen wen oder was kämpfen Sie und warum?

Heidi Waterhouse: Wir neigen zu der Annahme, dass jemand anderes eine echte Entscheidung getroffen hat, um etwas auf die eine oder andere Weise umzusetzen. Solche voreiligen Einschätzungen müssen wir überdenken. Wir müssen uns fragen, wie wir unsere begrenzten Ressourcen einsetzen und ob wir mit unserem Produkt in diese Richtung gehen wollen. Wir kämpfen gegen Trägheit und passive Akzeptanz, um bessere Erfahrungen für Nutzer und Ersteller zu schaffen.

Könnten Sie ein Beispiel aus Ihrer Erfahrung nennen, bei dem die frühzeitige Behebung eines dieser Probleme einen erheblichen positiven Einfluss auf das Projektergebnis hatte?

Heidi Waterhouse: Als technische Redakteurin habe ich die Texte (Strings) für die Benutzeroberfläche erstellt und bearbeitet. Ich habe mich dafür eingesetzt, dass wir den EN-String-Identifikator verwenden, statt Englisch fest in das Produkt zu kodieren. Als wir beschlossen, eine zweite Sprache zu lokalisieren, hatten wir bereits eine Möglichkeit, sprachenspezifische Strings zu lesen, statt das Englische herauszunehmen und durch einen neuen String zu ersetzen. Es war relativ einfach, diese Änderung von Anfang an vorzunehmen. Es wäre schwieriger und teurer gewesen, wenn wir es zum Zeitpunkt der Lokalisierung hätten umsetzen müssen.

Können Sie erläutern, wie die frühzeitige Auseinandersetzung mit den sieben Kämpfen dazu beiträgt, die technischen Schulden und die damit verbundenen langfristigen Herausforderungen zu verringern?

Heidi Waterhouse: Es ist fast unmöglich, alle sieben Kämpfe so früh anzugehen, wie wir wollen. Aber je früher wir anfangen, darüber nachzudenken und vorauszuplanen, desto besser ist es. Genauso wie Zinsen (technischer) Schulden anhäufen können, kann auch der positive Wert von IT-Assets steigen.

So mag es beispielsweise wirtschaftlich nicht sinnvoll sein, Zugänglichkeitsanpassungen schon früh in einem Produkt zu schaffen, bevor die Nutzer danach fragen. Wenn Sie jedoch den Nutzern die Möglichkeit geben, sich mit Ihrem Produkt zu beschäftigen, können Sie Märkte erschließen, die Sie ursprünglich nicht im Auge hatten oder die Ihre Konkurrenten nicht auf die gleiche Weise erreichen können. Selbst kleine Änderungen an Ihrem anfänglichen Produktdesign und Ihrer Denkweise können sich langfristig positiv auswirken, da Sie die Änderungen nicht nachrüsten müssen.

Mehr Infos

Vom 27. bis 30. November findet mit dem iSAQB Software Architecture Gathering 2023 die führende Online-Konferenz zum Thema Softwarearchitektur statt. Veranstalter der Konferenz sind iSAQB und iX, das Magazin für professionelle IT.

Das Programm bietet 30 englischsprachige Vorträge unter anderem zu

• Test Intelligence for Architects
• Architecting for Observability
• New Architecture Accidents
• How does Netflix build software to streamline organizational operations
• Legacy Software: Really a Problem?

Heidi Waterhouse hält auf der Konferenz den Vortrag "Seven Righteous Fights" über die Kämpfe, die in Projekten anstehen und die möglichst früh ausgetragen werden sollten.

Je größer Ihre Codebasis und je reifer Ihr Produkt ist, desto mehr bekannte und unbekannte Abhängigkeiten gibt es. Es ist sehr einfach, eine Änderung in ein paar hundert Codezeilen durchzuführen, aber schwierig, eine Änderung in ein paar hunderttausend Codezeilen vorzunehmen, selbst wenn die Änderung die gleiche zu sein scheint. An einer größeren Codebasis sind mehr Personen beteiligt, es gibt mehr Abhängigkeiten und mehr Interaktionen, sodass es schwieriger ist, vorherzusagen und zu testen, ob die Änderung gut verläuft.

Einer der Grundsätze des Agilen Manifests lautet: "Einfachheit – die Kunst, die Menge der nicht erledigten Arbeit zu maximieren – ist wesentlich." Warum ist es wichtig, so früh Arbeit in die sieben Punkte der "Seven Righteous Fights" zu stecken? Besteht nicht die Gefahr, dass diese Arbeit umsonst gemacht wird, weil wir beispielsweise doch nicht international werden, obwohl wir das anfangs dachten, oder die API intern bleibt, obwohl wir überzeugt waren, dass auch andere sie brauchen würden?

Heidi Waterhouse: Es besteht durchaus die Gefahr, dass Sie unnötige Arbeit leisten. Es zeugte von schlechter Planung, eine ganze Funktion zu entwickeln, die nicht nützlich ist. Die agile Arbeitsweise ist zum Teil eine Reaktion auf die Zeiten, in denen wir ein vollständiges Produkt geplant haben und nach der Fertigstellung feststellen mussten, dass es nicht das war, was wir wollten oder brauchten. Die schnellere Feedbackschleife hilft Produktverantwortlichen und Entwicklern dabei, sich darüber im Klaren zu sein, welche Funktionen für die Benutzer einen Mehrwert darstellen.

Die agile Entwicklung ist zwar eine Revolution, aber eine unvollständige. Manchmal müssen wir Arbeiten durchführen, die nicht die direkten Funktionen betreffen oder die nicht sofort sichtbar sind. Systemarbeit und Zukunftssicherheit lassen sich nur schwer in einen rein agilen Entwicklungsstil einbauen. Ich denke, der Trick besteht darin, diese konkurrierenden Werte auszubalancieren. Sie haben die API erwähnt, die nie nach außen geht. Aber die internen Entwickler benutzen sie trotzdem, und eine bessere Schnittstelle für sie verbessert auch das Produkt. Vielleicht ist die größere Frage nicht "Wie vermeiden wir es, etwas zu bauen, das wir nicht brauchen?", sondern: "Wie können wir die Fehler bei der Verteilung der Anstrengungen so gering wie möglich halten?".

Viele Unternehmen tun sich schwer mit dem Spagat zwischen der Dringlichkeit, Software zu liefern, und der Notwendigkeit, Qualität und Nachhaltigkeit zu gewährleisten. Wie empfehlen Sie Teams, diese sieben Kämpfe innerhalb enger Projektzeitpläne zu priorisieren?

Heidi Waterhouse: Es wurde schon so viel über Geschwindigkeit und Qualität geschrieben, dass dieses Thema gefühlt eine eigene Abhandlung verdient. Die Kurzversion ist, dass wir es untersucht haben und dass schnelle und gute Ergebnisse kein Widerspruch sind. Die "State of DevOps"-Reports von DORA (DevOps Research and Assessment, Anm. d. Red.) und Accelerate zeigen, dass kleinere, leichtere und schnellere Versionen zu weniger Ausfallzeiten und zufriedeneren Teams führen. Die Art und Weise, wie wir die sieben Praktiken in diese Struktur einfügen, ermöglicht iterative Verbesserungen ohne zu großen Aufwand. Selbst kleine, aber regelmäßige Verbesserungen können einen großen Unterschied ausmachen.

Das Interview führten Dehla Sokenou und Lukas Zühl.

(rme)