Qualitätstaktiken

Zurück zur Episode

Transkript

Anja: Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und heute habe ich mir Markus Harrer eingeladen und wir sprechen über Qualitätstaktiken. Hallo Markus.

Markus: Hallo Anja.

Anja: Ja, magst du dich einmal vorstellen und dann auch gleich sagen, was Qualitätstaktiken denn eigentlich sind?

Markus: Ja, hallo, ich bin der Markus, Markus Harrer. Ich bin Senior Consultant bei INNOQ.

Und ich arbeite vor allem in der Architekturberatung, mache auch sehr viele Modernisierungsgeschichten und ich mache auch ganz gerne immer so kleinere Projekte, also Architektur Reviews, Assessments, Leute einfach punktuell weiterhelfen, wenn sie Probleme haben, mit ihren Softwaresystemen weiterzukommen. Und das gefällt mir total gut bei INNOQ, denn da kommt man überall herum, hat ganz viele Herausforderungen und sieht auch einfach was.

Auch was ich, ja, brauche dann in meiner Architekturarbeit, sind natürlich immer ein bisschen so Lösungen. Also wie kann man was angehen. Es gibt immer Kunden, die stecken ein bisschen fest in ihrer Softwareentwicklung. Die machen vielleicht gerade jetzt ja so eine neue Stufe der Evolution noch durch, wo sie vielleicht neue Kunden onboarden. Die haben ganz viele verschiedene neue Ideen, was man mit der Software machen kann, was sie alles so brauchen.

Und da braucht man in der Entwicklung auch immer so ein bisschen so Ideen, wie man so ein Softwaresystem in die Zukunft nach vorne schieben kann, würde ich mal sagen. Meistens sind ein paar Dinge, die anzugehen sind, dann auch so Themen bei der Qualität.

Also klassische Dinge, das Ding, was man jetzt gerade hat, das muss besser wartbar sein. Man möchte jetzt neue Leute onboarden, vielleicht sogar. Und da ist man eben bei dem Thema drin, dass man eben was für aktiv tun muss. Man braucht sozusagen irgendwelche Ansätze, neue Ideen, die man in die Software reinbringt, um so neue Qualitätsziele oder Wünsche eben auch im Endeffekt erfüllen zu können.

Und dann kommen so Qualitätstaktiken, habe ich die jetzt mal genannt, ins Spiel. Das sind so kleine Elemente, die man einsetzen kann, damit man eben gewisse Qualitätsziele erreichen kann. So ein ganz einfaches Beispiel wäre Logging, um mehr Überblick zu bekommen, wie das System sich so verhält. Das ist ein ganz kurzes Beispiel. Das würde ich machen, um ein System stabiler hinzubekommen, ein bisschen mehr wartbarer zu bekommen, ein bisschen mehr zu kontrollieren, weil ich eben dann weiß, was so passiert.

Qualitätstaktiken, ja, der Begriff, der ist eigentlich so eine Neuschöpfung auch von mir. Es gibt da schon ganz viel Material da draußen. Man nennt die auch teilweise Architectural Tactics. Das kommt mehr so aus dem Software Engineering Institute Bereich. Da gibt es auch Bücher, Software Architecture in Practice, wo auch die gleiche Idee schon da ist, also man hat verschiedene Qualitätsmerkmale, darunter gruppieren sich verschiedene Architecture Tactics oder Architekturtaktiken, Design-Tactics und da kann man sich eben wissen, sowas herauspicken, was man gerade braucht. Und ich dachte mir, das ist eine coole Idee eigentlich und das wäre nicht schlecht, wenn man da so eine Art Kompendium hätte, ein bisschen größeres, eine größere Sammlung an Qualitätstaktiken, wo man sich dann in einer gewissen Situation was herauspicken kann und das ist das, woran ich gerade arbeite und wo ich Leuten ein bisschen helfen möchte, mal zu sehen, was alles so möglich ist, um Qualität eigentlich ins Softwaresystem hineinzubringen.

Anja: Das heißt, du schreibst gerade Qualitätstaktiken auf.

Markus: Genau, ich habe jetzt mal den Schritt gewagt, da auch ein Buch darüber zu schreiben. Ich habe die aber vorher auch schon jahrelang so ein bisschen mitgeschrieben. Ich mache auch Softwarearchitekturtrainings und in einem Teil der Trainings, da gehe ich auch immer so diese verschiedenen Lösungsmöglichkeiten durch, was ich denn machen kann, um gewisse Qualitätsziele zu erreichen. Das sind so ganz normale Dinge, die man eben so macht. Und da sammle ich immer auch von den Teilnehmern, was denen so einfällt. Wenn wir beispielsweise ein Real-Time Predictive Maintenance System bauen, bei uns in der Fallstudie, da gibt es ganz viele Dinge, auf die man achten muss. Erstens bei der Anforderungsseite. Das muss natürlich klar sein, was überhaupt gebraucht wird, was Real-Time heißt. Das sind so Themen, die man dafür natürlich vorher klären muss.

Dann habe ich sozusagen so ein Ziel vor Augen, was ich an Qualität brauche. Und dann picke ich mir etwas heraus, was vielleicht schon da ist, aus Büchern, wie dem vorher genannten schon, oder aus dem Internet in Form von Patterns. Das ist ja auch eine Art Qualitätstaktik, was man so drin hat, wie beispielsweise Caching oder so was in der Art. Das ist ja auch ein Ansatz, um Qualitätsziele in gewisser Art und Weise der Performance zu erreichen. Und dann wird das eben, ja, bewertet, ob man das auch gut nutzen kann und eingesetzt. Und da frage ich auch immer den Teilnehmern, hey, was fällt euch noch so ein? Was gibt es noch neben Caching beispielsweise, um die Performance, die Geschwindigkeit des Softwaresystems eben zu optimieren? Und da kommt immer wieder was zusammen, immer welchen neuen Qualitätstaktiken, Dinge ich einbauen kann. Und da dachte ich mir irgendwann mal, ja, halte ich das mal fest auf Karten erst mal im ersten Moment, auf Karteikarten. Dann habe ich die mal mitgebracht, so als Inspirationsquelle für Schulungen.

Und es kam eben so gut an, dass ich dachte, hey, warum nur in der Schulung diese Qualitätstaktiken verbreiten? Wieso machen wir nicht mal so ein größeres Ding draus? Und ja, da stehe ich jetzt wie gesagt davor.

Anja: Ja. Wunderbar. Du hattest gesagt, dass eigentlich Architekturtaktiken dasselbe sind. Warum hast du dich dafür entschieden, das jetzt Qualitätstaktiken zu nennen?

Markus: Also gibt’s ganz viel Material da draußen, ganz viel im Bereich der Forschung, ja, das schon. Und ich wollte es ein bisschen freier haben. Ich möchte nicht eine Grundsatzdiskussion haben, ey, das ist ja gar keine Architekturtaktik, die du jetzt da gerade vorstellst. Also ich hab so Dinge auch drin wie, ey, wie wär’s denn, wenn wir die Benutzer schulen, damit die wissen, wie das System funktioniert.

Das ist ja keine Architekturtaktik an sich. Das ist einfach so eine Idee, die ich machen kann, als Architekt, die ich vorschlagen kann, zusammen mit meinem Product Owner, als eine Möglichkeit, dann irgendwie doch eine Qualität zu erreichen im System. Aber notwendigerweise ist das nichts, wo jetzt in der Technik was dafür gemacht werden muss. Deswegen wollte ich da einfach ein bisschen was anderes haben, ein bisschen breiter, um da diesen Lösungsraum nochmal weiter zu fassen.

Also die Idee, und da bin ich ein bisschen so eigennützig drauf, ist ja, dass ich dann als Architekt oder Architektin vielleicht auch weniger selber machen muss, weil ich nicht nur Dinge mache, die zu implementieren sind im Softwaresystem, sondern die ich vielleicht auch delegieren kann zu anderen. Und dann können die sich drum kümmern und eben auf ihre Art und Weise gewisse Qualitätsziele erreichen. Das ist sozusagen die Idee. Und da würde ich fast sagen, dass wir da die Architekturtaktiken als so eine Art Untergruppe der Qualitätstaktiken dann betrachten können.

Anja: Okay, also zusammengefasst kann man sagen, du hast Lösungen oder Maßnahmen gesammelt, um Qualitätsziele erreichen zu können. Markus: Genau, und das ist einfach eine irre viel große Menge an sich. Und deswegen ist es auch ein bisschen strukturiert worden von mir. Irgendwas braucht man auch ein bisschen sozusagen, um sich dazu zu behelfen. Und deswegen ist es auch noch ein bisschen eingegliedert in die Qualitätsstandards, die man so draußen hat, beispielsweise den 25010 von der Version 2011.

Das ist noch meine Leistung zusätzlich zu einfach dieser Brain-Storming-Geschichte, dass man da noch ein bisschen Struktur dazugibt. Das ergänzt auch ganz schön das Thema, wenn man ganz spezifische Qualitätsziele hat in einem gewissen Bereich. Wir hatten auch mal die Folge 146 hier im INNOQ-Podcast zur Architekturqualität. Da wird ganz viel darauf eben Zeit investiert, um herauszufinden, was möchte ich denn genau Richtung Qualität haben. Und ich liefe jetzt wie gesagt dann sozusagen den Gegenpart dazu, Lösungen, die man dann eben nutzen kann, um dieses angemessene Grad und Qualität eben zu erreichen.

Anja: Gut, wenn es jemand hören möchte, wir werden auf jeden Fall diese Folge noch verlinken und zwar hat Sven Johann mit Gernot Starke darüber gesprochen über Architekturqualität. Nun hast du das aufgeschrieben und kann man das schon irgendwo lesen, irgendwo bekommen?

Markus: Genau, das ist jetzt einerseits ein Buch, das ist momentan im Entstehen. Das ist auf Leanpub verfügbar. Einfach mal unter Qualitätstaktiken mal googeln oder wir verlinken das Ganze auch. Und was ist das? Das ist eher so eine ausformulierte Sammlung und mehr Details dazu, aber eben nicht so viel, dass man jetzt komplett durch erklärt, was beispielsweise Caching ist oder so was. Es sind nur so kleine Hinweise. Da gibt’s was wie Caching. Das kann man machen. Das ist diesen jenes. Es sind vielleicht auch noch ein paar Hashtags mit dabei. Man hat immer die Idee, worauf zahlt dann diese Qualitätstaktik ein, auf welches Qualitätsziel. Und dann kann man eben die Schritte weiter selber gehen, schöne Google-Begriffe wählen oder den richtigen Prompt in Chat-GPT, formulieren, wenn man da noch mal tiefer reingehen möchte in eines der Themen.

Anja: Okay, das ist also eher so ein Nachschlagewerk.

Markus: Genau, das schon. Man kann jetzt auf Leanpub auch kostenlos, beispielsweise das Inhaltsverzeichnis sich mal anschauen. Da sind auch die ganzen Qualitätstaktiken vom Titel her aufgeführt. Das kann auch schon sehr gut reichen, um nicht nur immer eine Lösung im Kopf zu haben, die man dann immer herausschießt, wenn jemand fragt, ey, lass uns da mal ein bisschen was machen im Softwaresystem, dass es qualitativ nach vorne geht.

Anja: Ich habe auch das Inhaltsverzeichnis gerade vor mir und das sind ganz schön viele Taktiken pro Qualitätsziel. Wie viele sind das so im Schnitt?

Markus: Ja, das sind so pro Qualitätskategorie, würde ich mal sagen. Da sind so acht verschiedene Kategorien aus der ISO. Da sind um die 50 immer. Teilweise sind es aber auch doppelt, wie jetzt beispielsweise Code Reviews. Das kann ich jetzt reinstopfen, um zu gucken, dass die Funktionalität passt im Softwaresystem. Das kann ich aber auch nutzen, um zu gucken, dass die Wartbarkeit passt, dass die Leute das verstehen, was im Code geschrieben ist. Deswegen, ja, vielleicht sind es 380, weil man eben doch ein paar Doppelungen hat. So in der Art. Aber es wird noch mehr werden. Deswegen muss ich noch mal sagen, auch Leanpub, supergute Plattform für mich. Also das wird wahrscheinlich ein Buch werden, das nie fertig wird, genauso wie Architektur. Und da kommt auf jeden Fall noch was dazu. Das mittlere Ziel ist ja erstmal hier 500 zu haben, die nicht gedoppelt sind.

Und dann würde ich irgendwann Deckel drauf machen und das vielleicht doch mal als Print-Ausgabe veröffentlichen. Also da ist schon ordentlich was dabei und wird auch immer wieder was dazukommen, denn die Welt steht auch nicht still.

Anja: Nun, du hattest ja schon gesagt, wann man diese Qualitätstaktiken anwenden kann, wenn beispielsweise neue Qualitätsziele hinzukommen, neue Anforderungen hinzukommen, dass man sozusagen sich dann in diesen Qualitätstaktiken nach Lösungen umschaut. Gibt es sonst noch andere Anwendungen, irgendwelche anderen Use Cases, wo es schlau ist, so eine Sammlung parat zu haben?

Markus: Das kann man auch ganz gut nutzen, wenn man das Pferd von hinten aufzäumt, so zu sagen, für Architektur-Reviews. Also ihr könnt als Entwicklungsteam auch mal diese Qualitätstaktiken nehmen und dann mal gucken, was ihr schon im System drin habt. Beispielsweise, hey, ihr habt ganz viel gemacht Richtung, ja, sagen wir mal, Gamification oder sowas. Das ist auch eine Qualitätstaktik, die drin steckt.

Aber ihr habt Richtung Benutzbarkeit eigentlich kein Need. Das ist vielleicht so eine Expertenanwendung, wo Leute alle Dinge, die sie bearbeiten müssen, auf einem Screen sehen möchten. So eine typische Formularanwendung. Die möchten einfach nicht genervt werden durch irgendwelche Points oder Highscores. Und dann kann in einem Architektur-Review eben auch, ja, ein Resultat sein, dass ihr Dinge eingebaut habt, wie jetzt Gamification-Mechanismen, also sozusagen die durch spielerische Elemente motivieren, möglichst gut die Anwendung eben oder die Arbeitsaufträge eben zu erschlagen. Das kann sein, dass es völlig viel am Platz ist. Also da kann man ein bisschen so eine Art Selbstreflektion machen in Architektur-Reviews und das eigene System mal challengen. Also die Frage, okay, ich habe Lösungen, aber welche Probleme werden eigentlich gelöst? Habe ich diese Probleme? Und kann ich, wenn das eben herauskommt, dass es irgendwie nicht zusammenpasst, vielleicht auch etwas herrausnehmen aus dem System, um eben dann ein System zu hinterlassen, das halt wirklich eine angemessene Qualität liefert? Das wäre so, ja, im Endeffekt auch so ein Anwendungsfall dafür.

Anja: Ich kann mir das auch gut als Team-Workshop vorstellen, wo ein Entwicklungsteam auch selbstständig für die eigenen Architekturlösungen verantwortlich ist und das ist ja oftmals so, dass man zwar Qualitätsziele hat, aber nicht von vornherein alle Lösungen gleich implementiert, weil es gibt halt eine Priorität und die arbeitet man halt ab und dann fallen halt manchmal Dinge runter oder man hat erstmal nur wichtige Maßnahmen getroffen und andere würden vielleicht noch fehlen. Ich kann mir vorstellen, dass man sich regelmäßig in so einer Art Architekturrunde austauscht und sich mein Qualitätsziel nimmt und überprüft, okay, haben wir das korrekt oder umfassend implementiert und ja, welche Taktiken könnte es da geben und passen die für uns?

Markus: Genau, das wäre auch ein Anwendungsfall. Und du sprichst auch was an, denn diese Qualitätstaktiken, die sind halt auch sehr klein und überschaubar. Also das kann ich schnell durchblicken durch diese kurze Beschreibung. Ja, da weiß man, worum es geht. Man hat also ganz ehrlich ganz viel schon gesehen. Also das ist jetzt nicht irgendwie komplett was Neues, was ich hier niederschreibe. Aber das ist halt meistens nicht ad hoc präsent in den Köpfen aller Mitentwickelnden.

Wenn man eine Lösung braucht, dann fällt dann vielleicht bloß eines ein. In der Vergangenheit ist es wahrscheinlich immer Microservices. Ja, alles ist mit Microservices zu machen. Und da ist das Thema, vielleicht ist dann so eine, ist auch eine Qualitätstaktik, ja. Aber vielleicht ist die auch zu groß und hat dann auch zum Effekt, dass, wenn jetzt eine neue Anforderung kommt, dass man jetzt diesen riesengroßen Hammer hat, mit dem man irgendwie was erschlagen möchte. Und da möchte ich auch eine Alternative bieten mit diesen Qualitätstaktiken, weil ich halt nur einen ganz entscheidenden Teil brauche, der vielleicht durch diesen Architektursstil Microservices mitkommt. Vielleicht brauche ich wirklich bloß sowas wie, die Entwickler sollen nicht auf den Füßen stehen die ganze Zeit. Also brauche ich vielleicht sowas wie Modularisierung, was auch eine Qualitätstaktik ist, also nur so einen kleinen Teil. Und den kann ich mir dann herauspicken. Da kann ich dann auch wieder gucken, hey, ist es jetzt etwas, was ich überschauen kann? Ist es auch wieder nicht mit Kanonen auf Spatzen geschossen sozusagen? Bringe ich das mit meinen Fähigkeiten von meinem Team auch in die Umsetzung im nächsten Sprint, wenn da was ansteht, oder übernehme ich mich da? Denn bei den Qualitätstaktiken, es gibt halt nichts umsonst. Also alles, was ich mir sozusagen einfange, hat auch irgendwelche Nachteile. Und dann kann ich das eben abwägen, kann ich in Architekturentscheidungen besprechen, kann ich sogar ein paar Alternativen mir heraussuchen durch die aufgelisteten Qualitätstaktiken und dann das für mich passende in der Situation eben herausfinden. Genau, das ist ganz richtig.

Anja: Ja, ich sehe da auch tatsächlich eine Gefahr da drin, dass man dann ins Overengineering kommt, wenn man sagt, so wir haben ein Problem und wir haben hier eine Liste von Lösungen, wir suchen uns jetzt einfach eine Lösung aus und dann ist es halt meistens so etwas wie Modularisierung oder Microservices. Und da sehe ich schon eine Gefahr drin, wenn man so von der Lösungsseite rangeht. Diese Arbeit, die davor gemacht wird, überhaupt zu entscheiden, wie wichtig ist uns das Thema, wie hoch ist die Priorität, wie gut ist gut genug, dass man das sozusagen hinten wegfallen lässt und gleich zu den Lösungen kommt. Also siehst du die Gefahr da auch?

Markus: Ja, das sehe ich auf jeden Fall. Und ich finde das auch einen sehr wichtigen Teil. Eigentlich ist das eine Anforderungsklärungsgeschichte, eben Qualitätsziele erst mal herausfinden. Und das muss auf jeden Fall vorher gemacht werden. Ich habe jetzt da bewusst den Scope des Buches nicht hingelegt. Da gibt es auch fantastische andere Workshops hier, beispielsweise von unseren Kollegen, dem Michael Plöd, Quality Storming. So ein Pendant ähnlich wie Event Storming, aber im Gegensatz zur Fachlichkeit nimmt man sich da eben die Qualitäten vor, um eben da auch so ein gemeinsames Verständnis zu erarbeiten, was ist denn jetzt in unserer Situation genau wichtig, umgesetzt zu bekommen.

Und ja, das Overengineering auch auf jeden Fall ein Thema. Also ich würde auch immer sagen, man muss ja nicht immer diesen Schieberegler von 0 auf 10, auf die maximalen 10 bei jeder Qualität erstmal noch drücken, indem man irgendwie sagt, ein bisschen schneller sollte das System schon funktionieren.

Sondern man kann eben dann auch mal gucken, ey, was sind denn so Dinge, die ja schon gut genug sind, wie du auch sagst, dass man eben da nicht immer diese große Lösung, die keine Ahnung, diese großen Firmen da draußen auch direkt einsetzen würden, nimmt, sondern wie vorher schon mal angedeutet, etwas nimmt, was einen selbst nicht überfordert. Und ja, da ist auf jeden Fall immer wichtig zu wissen, am Anfang, bevor man eben diese Qualitätstaktiken herauspickt, was möchte ich überhaupt erreichen und was ist dann gut genug für mich, um da das richtige Set eben zu finden.

Anja: Ja, und wenn du sagst, was ist gut genug für mich, eigentlich sollte ich das ja aufgeschrieben haben, weil wenn ich Qualitätsziele habe, dann erarbeite ich ja auch auf Grundlage dessen auch Qualitätsszenarien, die mir genau sagen, was denn gut genug ist, wenn sie halt gut gemacht sind.

Markus: Genau, das ist sozusagen das Notwendige. Man spricht auch von Quality-Driven Software Architecture. Das war auch ein Thema von dem Architekturqualitäts-Podcast. Also ich lasse mich sozusagen wirklich treiben von den Qualitätszielen, die ich so habe und pick mir eben das raus, was ich brauche. Und ohne dem wird es halt irgendwie Glück also das ist ja auch das also wir glaube ich wir machen halt immer Dinge in der Softwareentwicklung wissen nicht warum und denken immer, ja da gibt es keine Alternative dazu diesen diesen einen Ding das wir jetzt vielleicht ein vorgehende Projekt noch eingesetzt haben und in der Situation super gut funktioniert hat. Nee, es kann ja sein, dass gerade jetzt in unserer Situation, dass ihr so ein Anti-Thema wird, so ein Anti-Architekturansatz. Und da möchte ich eben auch Alternativen zeigen zu der eine Lösung, mit der man immer früher Erfolge feiern konnte, weil es eben so unglaublich viele andere gibt da draußen, die man auch nutzen kann, die eben in gewissen Situationen besser passen.

Anja: Wir hatten eigentlich kein Vorgespräch, wir sind einfach hier reingegangen, aber ein Stichwort steht so im Raum und ich weiß gar nichts damit anzufangen. Qualitätsillusionen. Was sind denn Qualitätsillusionen?

Markus: Also, neben den ganzen Qualitätsmerkmalen von ISO-Norm kann man auf vier Richtungen der Qualität, ich sag mal so, illusionieren. Man kann so tun, als ob man etwas erreicht hat an Qualitäten in der Software. Da merkt man schon bei meinen Formulierungen, dass das vielleicht nicht ganz so mit offenen Karten gespielt ist. Deswegen ja auch Illusion.

Und die sind auch noch mit dabei als extra Punkt nochmal, um auch mal zu zeigen, was man in Notsituationen sozusagen auch liefern kann. Also man kann Qualitätsillusionen, kann man auch gleichsetzen mit Workarounds, teilweise mit Schummeleien, da geht es auch teilweise schon fast in, ja, in etwas, was rechtlich vielleicht bedenklich ist, was auf jeden Fall auch moralisch bedenklich ist. Aber das wird auch gemacht. Und das wollte ich eigentlich noch mit reinnehmen, um Leuten einerseits so Notlösungen zu geben und andererseits zu zeigen, hey, was ihr jetzt da macht, das kaschiert eigentlich nur ein Qualitätsdefizit, das ihr gerade habt. Das ist nicht wirklich was, dass das die Problemursache auch behebt, wo eben noch mal an der Qualität geschaut werden muss.

Und dann, ja, dazu aufzufordern, wir auch eben die Idee damit zu sagen, ja, dann macht das eben richtig. Also, dann müssen wir eins nehmen, beispielsweise sowas wie, ja, was aktuelles: Pseudo-KI-Interaktionen wäre so eine Qualitätsillusion. Dann ist es irgendwie reingekommen, weil jemand gesagt hat, hey, wir haben jetzt hier so ein Need da von der funktionalen Eignung hier zu zeigen, hey, wir können da auch die Dinge machen, die unsere Konkurrenten eben können. Die schreiben überall in allen Flyern, auf allen Homepages drauf, dass sie eben KI-enabled sind oder sowas in der Art. Und dann haben wir aber in einer Projektsituation, wo wir da eigentlich das gar nicht so richtig angehen können, bauen wir eben so Interaktionen rein, die eigentlich so vorprogrammierte Antworten haben, aber eben so erscheinen gegenüber den Usern, dass es eben so eine Art KI-Feeling hat. Also typischen Chatbots hier. Ja, hallo, wer bist du? Ja, hallo, da Markus und so. Und was möchtest du von mir? Ich möchte keine Ahnung, was zurückgeben. Ich habe irgendwie einen Garantiefall. Oh, jetzt muss ich aber jetzt hier unbedingt den Support anrufen. Warte mal, da brauchen wir bei diesem komplizierten Fall ja, ich kann dir mit meiner KI gar nicht weiterhelfen. Das könnte so ein Ding sein, das man einbaut in eine Anwendung, um etwas vorzutäuschen, was gar nicht da ist. Da merkt man schon ein bisschen ein zweischneidiges Schwert das war jetzt echt ein böses eine böse Qualitätsillusion und auch bös dargestellt.

Also es kann auch anders sein was nicht so schlimm das ist hier. Ich sag mal so so was wie Skeleton Screens also ich wenn ich mir was laden muss beispielsweise. Und die Suchergebnisse, die dauern halt ein bisschen länger zu berechnen, dann zeige ich halt mal schon so ein Grobgerüst an. So diese grau wabernden Balken, die dann kommen, wenn man beispielsweise auf YouTube ein Video sucht. Die suggerieren mir, ich habe eigentlich die Video schon gefunden. Jetzt müssen aber nur noch die Texte geladen werden und dann ist alles da. Das ist sozusagen das, was da mit reinkommt. Das hat natürlich ein Ziel, dass das Ding ein bisschen, dass die Software ein bisschen ästhetischer aussieht, dass man auch ein bisschen mehr Richtung der Laufzeiteffizienz gewinnt. Das ist ein bisschen so responsive auch, reagiert die Anwendung.

Anja: Zumindest so aussieht, ne?

Markus: Aber eigentlich, die trickst eigentlich an sich, weil eigentlich da noch nichts geladen ist. Das wird erst nachgeladen, aber der Benutzer bleibt da oder die Benutzerin bleibt da der Stange sozusagen. Die sehen sofort, der tut sich gleich was. Und damit kann ich halt gewisse Qualitäten halt illusionieren. Das sind auch so Tipps, wo ich sagen muss. Ja, also machen eben ganz viele. Ich habe gesagt mit zweischneidig. Ja, manchmal macht man das eben aus der Not heraus, da wird es so ein Workaround. Aber was mir da auch wichtig ist bei den Qualitätsillusionen ist, dass eben auch so große Firmen einfach nur mit Wasser kochen.

Also das Szenario, ich habe jetzt hier meine 0815 Bürosoftware, dann sagt jemand, das muss aber genauso schnell laden wie die Videos bei YouTube. Ja, die laden halt nicht so schnell. Das dauert ewig, bis die eigentlich wirklich da sind. Nur die Illusion wird erzeugt, dass Dinge eben schnell geladen werden. Und damit möchte ich zeigen, dass man sich dann nicht als Entwicklungsteam da total verausgaben muss, da irgendwas hinstellen muss an Hardware, damit ja dann bei der eigenen Anwendung große Datenmengen instant geladen werden. Nee, das machen die großen ja auch nicht, sondern wie gesagt, die erzeugen nur diese Illusion, dass sie das tun.

Und ich glaube, da kommen wir auch gut ins Gespräch dann rein mit Leuten auf der Anforderungsseite, eben auch wieder die richtigen Lösungen für ein angemessenes Qualitätslevel in der Software herzustellen. Die Illusionen, also manche sind noch ausgedacht, die gibt es so noch nicht. Also es ist ausgedacht.

Anja: Ja, jetzt hast du mich aber wirklich neugierig gemacht. Jetzt möchte ich noch eine Qualitätsillusion hören. Die sind wirklich spannend. Ja. Hm. Markus: Die Illusionen? Also manche sind auch ausgedacht. Die gibt es so noch nicht. Also was heißt ausgedacht.

Ich habe komische Hobbys. Ich sammle beispielsweise Systemausfälle. Ich sammle sowas wie wenn was in Anwendungen nicht ganz so sauber ist. Wenn ich sehe, da wird ein bisschen geschummelt und teilweise auch so Verdachte, wo etwas vielleicht unbewusst gemacht wird. Also ich habe eins hier. Das ist von mir selbst. Das nennt sich Navigationslabyrinth. Also die Benutzerführung absichtlich verkomplizieren.

Ich denke mir manchmal, dass es so eine Taktik ist, die eingebaut wird im Softwaresystemen, um andere Qualitätsdefizite ein bisschen zu kaschieren. Also in diesem Fall, ich habe vielleicht eine Bankanwendung und ich möchte eine Überweisung machen. Und danach möchte ich meinen Kontostand sehen. Jetzt mache ich die Überweisung. Da muss ich erst mal hinklicken, mich navigieren, mache die Überweisung.

Und jetzt möchte ich sehen, ob die Überweisung geklappt hat, um zu sehen, ob der Kontostand auch aktualisiert ist. So, und jetzt brauche ich erst mal zehn Klicks, bis ich dahin komme. Warum würde ich das machen? Als Notlösung könnte ich das wirklich machen als Bank, wenn ich es nicht schaffe, die Daten der Kontobewegungen sozusagen ziemlich schnell zu aktualisieren bei mir in den Backend-Systemen.

Also weil ich so vielleicht Konsistenzprobleme habe oder zumindest das so gelöst habe, dass ich halt auch ein bisschen so Richtung Eventual Consistency gehe. Aber ich möchte halt nicht irgendwie den inkonsistenten Zustand zeigen oder Kontostände zeigen, die nicht valide sind. Dann könnte ich halt so eine Art Navigationslabyrinth einbauen, damit Nutzer ein bisschen länger brauchen. In der Zeit habe ich alles aktualisiert, passt alles. Und bin gut raus.

Aber ich muss sagen, es ist halt etwas, was vielleicht niemand jetzt hier im Ticket mal angefordert hat. Aber könnte ich ziehen. Also kann ich mir gut vorstellen, wenn ich jetzt da nicht die Möglichkeit habe, auch so konfliktierende Qualitäten auch teilweise zu lösen, dann muss ich halt so einen Weg gehen.

Und ich finde immer, wenn man das bewusst macht, wenn man das transparent macht, dann finde ich, ist es auch nicht schummeln. Das ist ja dann wie diese Magier, die alle Zauber, Zaubereien da so aufdeckt und die Hintergründe dazu erzielt. Also wenn ich das dann als Architekt oder Architektin mache und das auch einbaue im Absprache mit Product Ownern oder Produktmanagern und das dann eine valide Lösung ist, dann muss ich fast sagen, warum nicht? Passt.

Anja: Ja, aber du hast dich trotzdem dafür entschieden, sie Qualitätsillusionen zu nennen und ein wenig separat zu listen.

Markus: Ja, weil sie halt Workarounds doch noch sind, ja. Und man löst einfach nicht die Problemursachen. Also es sind einfach Pflaster, das muss man schon sagen. Und wenn man halt auch zu viel davon einsetzt, dann hat man halt diese schöne Systeme, die halt wirklich irgendwie zusammenbröselt irgendwann, denn diese Pflaster halten halt nicht den Wind der Veränderung sozusagen stand, um es philosophisch auszudrücken, sondern man muss dann irgendwann auch sagen, jetzt müssen wir da wirklich ran und das mal richtig lösen und dann gucken wir eben sozusagen bei den Qualitätsaktiken den ehrlichen Dingen rein, die man machen kann, um Qualitätsziele zu erreichen und pickt sich eben da die richtigen Dinge raus.

Anja: Aber ich kann mir vorstellen, dass das eigentlich eine pragmatische Sichtweise ist, erst einmal nur diese Workarounds oder diese Pflaster zu machen, bis man wirklich in die Investition geht, um die Performance beispielsweise wirklich zu erhöhen. Das kann ja auch ziemlich viel Geld sparen. Und wenn es gut genug ist, dann ist es halt gut genug, so eine Pflaster zu haben. Das sehe ich total valide an.

Markus: Genau das finde ich auch, dass die Alternative wäre, dass wir die Qualitätsillusionen auch sehen, um Qualitätsziele zu erreichen. Da finde ich uns noch nicht so weit in der Industrie. Ich kann ja auch sagen, ich habe keine Ziele. Also, ich kann ja auch Qualitätsziele definieren, wo drin steht, die Software soll schrottig sein. Ich könnte Qualitätsziele schreiben, wie die API soll, bitte, komplett undokumentiert sein, weil ich möchte, keine Ahnung, Schulungen verkaufen für die Entwickler, damit die die API kennenlernen müssen.

Also, es kann ja auch ganz viel dahinterstecken, was man dann ein bisschen so auch in der Softwareentwicklung nicht so wirklich sieht und andere Beweggründe haben und da könnte man die auch da reinpacken aber da müssen wir erstmal solche Qualitätsziele also die Mut aufbringen auch in der Produktentwicklung solche ich sage so Nicht-Qualitätsziele im Endeffekt auch auf dem Blatt Papier irgendwie niederzuschreiben, weil das kann auch gut sein, um Kosten zu sparen und eben, wie gesagt, Qualität angemessen zu dem Zeitpunkt, wo das System gerade so für gewisse Kunden eben passend hingestellt werd en muss, zu definieren, fände ich ganz nett. Aber habe ich jetzt mal eben weg. Also, wie du gesagt hast, ich habe jetzt auch, wie gesagt, mein Hobby, da komme ich auch immer ein bisschen auf Seiten vorbei, die tun so, als ob sie irgendwelche Dinge können. Ich habe jetzt mal eine Seite gehabt, da wollte ich ein Hotelzimmer buchen und da dachte ich mir, hey, wie schaut es denn aus? Frau und zwei Kinder, wie wäre es mal, wenn man probieren hier anstatt ein Zimmer, zwei Zimmer zu buchen und dann eben getrennt eben zu schlafen? Und da dachte ich mir, hey, da ist doch dieser Button hier, Zimmer hinzufügen. Dann klicke ich drauf und da kommt ein Pop-up, sorry, haben wir noch nicht implementiert.

Wenn du Bock hast, da was zu machen, wir lass uns gerne ein Feedback da. Und wenn da genügend zusammenkommt, dann implementieren wir das. Sprich, die haben sozusagen da ein bisschen so eine Validierung gemacht. Hey, ist es wirklich was, was wir brauchen? Richtung funktionaler Vollständigkeit muss man jetzt da mal rein bei dieser Qualität. Brauchen wir dieses Feature unbedingt? Muss das jetzt schon rein? Oder vertagen wir das noch ein bisschen? Also sehen wir halt nicht vollständig, was alle anderen auch so machen am Markt. Zwei Zimmer buchen, ja, können wahrscheinlich ganz viele Buchungssysteme da draußen, ganz viele Reiseanbieter, aber wir wissen nicht, ob unser Kundenstamm eben so ist und deswegen machen wir da ein Experiment und haben eben da bei der Qualität ein bisschen heruntergefahren und sind halt auf so ein Testing der wirklichen Nutzerbedürfnisse da rausgekommen.

Anja: Ja, das hört sich nach einer Produktentwicklungstaktik an. Da könnte man vielleicht noch ein Buch draus machen. Ja.

Markus: Genau, es ist schon so, dass man halt viele Dinge sieht, die auch in der Produktentwicklung mit dabei sind. Deswegen auch am Anfang hier eine Art Architekturtaktiken passt halt nicht. Ich habe Dinge drin wie Personas.

Also, lernt mal eure User kennen, lernt mal eure Kunden kennen, die das System dann irgendwie einkaufen, Benutzer verschiedener Arten, wer sind denn die, was wollen denn zu machen, damit man die nicht aus dem Blick verliert, finde ich ultra wichtig, um auch Richtung Benutzbarkeit und auch bei den Features es nicht zu übertreiben. Und ja, das ist halt klassisch Requirements Engineering, klassisch auch Usability Engineering, aber hilft halt auch uns in der Architektur-Welt, um dann auch keine overingenierten Systemen zu bauen, die dann im Endeffekt niemand braucht.

Anja: Ja. Ich habe jetzt, ich scrolle mal durch dein Buch durch, du hast es mir zur Verfügung gestellt und da gibt es schon eine Struktur, also das ist ein sehr kurzer Text pro Taktik und dann hast du noch so besondere Stichpunkte. Möchtest du mal die Struktur einer Qualitätstaktik erläutern?

Markus: Kann ich gerne machen und ich springe daher ich springe erst mal noch mal raus also das Buch generell ist immer so erstmal gegliedert nach diesen Oberkategorien der ISO 25010. Also funktionale Eignung, Benutzbarkeit, Zuverlässigkeit, … . Dann gibt es einen kurzen Abriss was überhaupt genau ist und dann kann man sich das Buch so vorstellen, dass es eben eine ganz lange Liste gibt und die hat auch eine Sortierung. Ich bin da sozusagen so verfahren, dass ich sage, was sind denn so No-Brainer eigentlich? Was fällt einem gerade so, was sollte einem direkt einfallen, wenn man denkt, ey, lass uns mal was, keine Ahnung, Richtung Kompatibilität machen? Oder wäre es halt nicht schlecht, beispielsweise mal sich, um standardisierte Schnittstellen so Gedanken zu machen, um eben mit anderen Systemen gut sprechen zu können. Da wäre es für mich so ein No-Brainer. Das ist sozusagen da die Sortierrichtung bis ganz runter zu Dingen, wo man eigentlich in ganz speziellen Sachen nur irgendwie draufkommt, dass das, was mit zu tun hat mit Themen wie Interoperabilität, beispielsweise Fehlermeldungen, wenn die Kompatibilität mit anderen Systemen nicht gewahrt wird, das ist etwas näher. Das brauche ich nur in ganz speziellen Fällen. Deswegen ist das eben in diesem Abschnitt weiter hinten, weil das nicht so ein universelles Ding ist, das man anwenden kann. Das erstmal zu der Struktur überhaupt von dieser Auflistung. Und dann habe ich auch das Problem ein bisschen, dass es ja allgemeine Taktiken gibt, wie beispielsweise Modularisierung. Das ist auch etwas für Wartbarkeit. Und dann gibt es aber spezielle Arten, wie ich diese Modularisierung umsetzen kann.

Beispielsweise gibt es da eine Taktik Richtung Bubble Context. Also Erweiterungen, vielleicht auch für neue Feature-Sets klar, von bestehenden Code-Teilen abgrenzen. Das ist eigentlich auch etwas, um das System modularer zu hinterlassen. Ist halt so eine Unterkategorie von der Modularisierung. Deswegen folgt ihr halt da unmittelbar im Umfeld von Auflistung her eben auch. Dass man eben auch immer so ein Set hat an Dingen, die eben irgendwie zusammengehören, das war eben da wichtig, damit man auch Zeit sparen kann beim Lesen, beim Durchscrollen, und auch nichts Wichtiges verpasst, was eben zu einem Themenkomplex gehört.

Genau, jetzt können wir reingehen. Also, es gibt immer natürlich einen Titel und es gibt dann auch immer eine Kurzbeschreibung. Ich habe das gerade auch schon mal Bubble Context vorgelesen, da könnt ihr auch gleich weitermachen. Ich habe hier entsprechende Titel Bubble Context, Erweiterung klar von bestehenden Codeteilen abgrenzen.

Und das reicht mir wahrscheinlich nicht, wenn ich mich tiefer jetzt mit diesem Thema auseinandersetzen möchte. Es reicht schon, um das zumindest in Google reinzupacken, um da mehr Informationen zu finden, ja. Aber wenn ich jetzt das nicht machen möchte, sondern erst mal herausfinden möchte, wäre das Thema war für uns im Entwicklungsteam, gibt’s eben da noch mal eine kurze Beschreibung.

Ich kann dir auch mal kurz was nur exemplarisch rauspicken für Bubble Context. Durch die Einführung eines Bubble Contexts wird der Einfluss von Änderungen auf andere Teile des Systems minimiert, indem die Abhängigkeiten zwischen den bestehenden und neuen Modulen klarer strukturiert werden und so weiter und so fort. Also auf jeden Fall etwas, wo ich denke, beim Buch, da habe ich jetzt was aufgeschnappt an Begrifflichkeiten, an ner Kurzbeschreibung, was mich so interessieren könnte. Dann habe ich hier noch einen Text, der dann noch einmal tiefer reingeht, um dann wirklich mal zu wissen, hey, da muss ich nochmal tiefer rein, denn das ist interessant für mich. Dann gibt es eine kleine Klassifizierung, wozu gehört denn das ganz überhaupt, was ich gerade gelesen habe. Also was wird denn dadurch gefördert, also welches Qualitätsziel, dass ich gerade erreichen möchte.

Deswegen fördert hier bei Bubble Context beispielsweise Analysierbarkeit. Ich tue mich dann später leichter auch in der Entwicklung eben dorthin zu fassen, wo das Feature angefasst werden muss, weil ich weiß, wo das liegt. Das ist da so die Idee. Neben dem “Fördern” gibt es auch, “Fördert auch”, also es haben wir auch mal vorher schon mal gehabt, es gibt ja nicht mehr eine Qualitätstaktik, die sich eineindeutig zu einem Qualitätsziel zuordnen lässt. Es gibt ja Dinge, die eben auch auf mehrere Qualitätsziele dann einzahlen, das wäre noch da. Und was noch ganz wichtig ist, dass eine Qualitätstaktik halt immer auch Nachteile bringt. Deswegen gibt es da noch mal eine Konsequenzen-Sektion. Und bei Bubble Context wäre das hier beispielsweise erhöhter initialer Aufwand für die Implementierung, da eine klare Strukturierung der Module und Integration mit den bestehenden Teilen erforderlich ist, so wie eventuell Aufwände für Datensynchronisation. Also ich habe einfach was zu tun, wenn ich mich entscheide das einzusetzen. Und dann kann ich gucken möchte ich jetzt das bezahlen diesen Preis oder so wie mir lieber was anderes aus was vielleicht ein bisschen in meinen Situationen weniger Konsequenzen hat, wo ich weniger Aufwände habe. Das ist sozusagen da die Idee.

Anja: Ja, du sagtest auch schon in deinem Kontext, also die Konsequenzen hast du jetzt auch nicht klassifiziert in hoher Aufwand, niedriger Aufwand, weil das kommt immer drauf an, für welche Architektur ich sozusagen hier diese Lösung implementieren möchte. Manchmal sind die Konsequenzen eben sehr gering in diesem Kontext, manchmal aber sehr hoch. Ja.

Markus: Genau, also das stimmt auf jeden Fall. Bubble Context in dem Fall, also wenn ich im Kontext Microservices unterwegs bin, da habe ich halt schon, zumindest ich habe Expertise, ich habe Leute, die haben sich schon mal, hoffentlich Gedanken gemacht, wie man etwas aufteilt. Die kennen das, die wissen, was Module sind. Die wissen, was Kopplung ist und sowas. Sie wissen, wie man es hinbekommt, zwischen verschiedenen Services Daten hin und her zu schicken, Daten austauscht, wie man eben guckt, dass da kein verteilter Modulith oder sowas eben entsteht. Genau, die haben jetzt da schon Expertise und deswegen weniger Aufwand, sowas zu implementieren, ganz richtig.

Deswegen ist es mit dem Aufwand, ja, nicht gut reinzubekommen. Was man machen könnte, sind vielleicht T-Shirt-Größen noch mal so als ganz grobe Richtung zu geben für Leute, die da nur eine Hausnummer haben möchten. Da bin ich noch im Überlegen, das zu machen. Aber generell stimme ich dir zu, das kommt immer darauf an, ist also diese Beratergeschichte. Diese Antwort bleibt uns da nicht erspart.

Was ich noch zur Struktur ergänzen wollte, ganz am Ende noch mal, gibt’s noch ein paar Hashtags. Die sind eigentlich auch dafür da, das Googlen ein bisschen einfacher zu machen oder Begriffe zu beinhalten, die man vielleicht schon kennt. Jetzt hier beispielsweise bei Bubble Context wäre ein Hashtag, okay, das erste ist billig, BubbleContext. Sollte nicht immer sein, aber manchmal ist es mir nichts besseres angefallen, wie es ist mit meinem Kompagnon, der mir dabei geholfen hat, das zu schreiben.

Aber wir hätten auch das Hashtag Domain Driven Design. Da weiß ich schon, Bubble Context, wenn es irgendwas kommt aus der Kaugummi-Herstellung bei den Google-Suchergebnissen, dass ich da vielleicht falsch bin, dass ich da vielleicht nochmal Domain Driven Design hinterher zu schießen sollte bei den Suchbegriffen und allgemeinen Software-Architektur, weil es halt so ein Kunstwerk ist, Richtung Software-Architektur oder Richtung Bubble-Kontext was hinzubekommen, ja, ist eher ein allgemeiner Begriff. Aber wir helfen vielleicht auch noch mal ein bisschen, diesen Begriff besser zu fassen und vielleicht auch wo anzudocken, um eben dann den Lesenden Hinweise zu bekommen, wie die da weiterkommen an der Stelle.

Anja: Du hattest gerade gesagt, du hast es nicht selbst verfasst, du hast noch jemanden dabei zur Hilfe gehabt.

Markus: Genau, da muss ich jetzt die Katze aus dem Sack lassen. Ich habe am Anfang gesagt, ich habe das schon immer gesammelt. Ich habe immer die ganzen Begriffe rein. Ich habe dann angefangen, Karteikarten zu fabrizieren, eben mit dem mit dem Titel und so einer Kurzbeschreibung. Und ich hatte damit 30 angefangen, mit 30 Qualitätstaktiken aus diversen Qualitätsmerkmal-Kategorien.

Und das ist einfach irre viel Arbeit. Und da hab ich mir gedacht, hey, ich meine, Qualitätstaktiken, wir alle kennen die doch, oder? Und das Internet kennt doch das Ganze bestimmt auch schon. Und was macht man heutzutage? Ja, dann kann man eben das ganz gut auch abgeben an einem Large-Language-Model, was ich natürlich auch gemacht hab und einfach da mal nachgefragt, hey, was sind denn so typische Dinge, die man machen kann für mehr Sicherheit beispielsweise?

Da bekommt man natürlich dann auch eine Liste heraus. Dann ist natürlich noch mal zu gucken, ist das ausgedacht, ist das valide. Da kommt bei meiner Seite eben die Recherchearbeit wieder zum Tragen. Ich muss gucken, stimmt das überhaupt, diese Abkürzung, die mir da um den Kopf geworfen wird, um eben auf Qualitätsziele in einer bestimmten Art einzuzahlen. Ja, dann kommt es eben teilweise doch gut und gute Qualität eben generiert heraus und das habe ich angenommen, um dann auch die Dinge ausformulieren zu lassen. Also ich stelle mich jetzt nicht hin und habe da so diese 400 Taktiken und formuliere die aus. Da werde ich aber einfach nicht fertig. Das halte ich auch nicht aus. Also ich bin einer, ich suche die Abwechslung. Mir ist es wichtig, da möglichst viele Dinge unterschiedlicher Art und Weise zu machen. Privat und auch beruflich und das wäre mir einfach zu öde. Deswegen habe ich die öden Sachen auch outgesourced, also meinen Spurrings-Partner in diesem Fall Claude genommen, um mir diese verschiedenen Taktiken erst mal ausformulieren zu lassen. Und dann bin ich eben hergegangen, hab das wieder validiert, war mir auch zu öde. Dann hab ich mir selber einen Lektor geschrieben, mit ChatGPT beispielsweise, der mir das Ganze nochmal lektoriert. Und ich bin eigentlich nur noch der, wie soll ich sagen, der Kurator im Endeffekt. Genau. Ich hatte es auch ganz am Anfang im Buchtitel oder eben entsprechend als Autor nochmal reingeschrieben, kuratiert und gepromptet von Markus Harrer.

War mir schon wichtig, dass die Leute das am Anfang sehen, dass das jetzt nicht wirklich nur aus meinem Kopf irgendwie entstanden ist, sondern ein Werk viele im Endeffekt, die irgendwie was schon mal im Internet publiziert hatten.

Anja: Ja, so kann man das auch sehen.

Markus: Ja, und das war mir da schon wichtig. Und ich meine, jetzt habe ich so viel drüber gearbeitet. Ich habe das jetzt raus aus dem Titel, aber natürlich einen Hinweis angebracht, wie das Buch entstanden ist. Ganz am Anfang des Buches kann auch jeder lesen, der das Buch beziehen möchte und wie die Texte da entstanden sind. Also da bin ich ganz offen und ehrlich. Und die Alternative wäre eben für mich gewesen, das nicht zu machen und deswegen wollte ich das unbedingt wie auch immer zu Papier bekommen mit den Helfern, die uns jetzt heutzutage eben auch zur Verfügung stehen.

Anja: Aber ich sehe da auch total die Gefahr drin, wenn man reinschreibt oder wenn man es tut, dass sozusagen ein Produkt entwickelt wird mit Hilfe von AI, dass dieses Produkt dann nicht verwendet wird. Da hatten wir uns, glaube ich, auch schon mal online darüber unterhalten, dass Produkte, wo AI drauf steht, seltener auch in Anspruch genommen werden, weil die Leute sich so ein bisschen davor fürchten oder dagegen wehren, es als weniger qualitativ ansehen.

Markus: Ja, das kann schon sein, aber ich muss sagen, es war schon manchmal wirklich Mist drin. Und ich wollte natürlich, weil es mir wahrscheinlich auch wieder zu öde war, nur in der deutschen Version zu machen, auch gleich direkt die englischsprachige angehen, nennt sich dann logischerweise Quality Tactics, gibt es auch auf Leanpub.

Und vor allem da, bei der Nutzung von ChatGPT als Übersetzungswerkzeug, hat man wirklich das Problem, dass einfach mal wieder Texte ausgelassen werden, die gehen irgendwie verloren. Die Kontext der Übersetzung ist total falsch und Mist und passt nicht in die Softwarearchitekturwelt hinein. Also da ist schon ordentlich was zu tun. Aber ja, also ich habe dann einfach auch viel Code geschrieben, der mir das Ganze auch abnimmt. Also ich würde auch fast schon sagen, wenn ich schätzen müsste, habe ich mehr Python Code geschrieben, wie Text.

Also das, weil ich immer dahinter her bin, dass die Qualität einfach passt. Also ich habe immer diese Struktur pro Qualitätstaktik, die muss immer gleich sein. Es muss auch vom Wording gleich sein. Also vielleicht bin ich da zu penibel, aber die Kurzbeschreibung sollte immer so sein, dass dem Deutschen auch ein Verb endet und keine Substantivierung hat von irgendwelchen Verben.

Klingt vielleicht komisch, aber da brauche ich einfach auch Large-Language-Models, die mir da weiterhelfen können, und Python. Dann schiebe ich das einfach rein und lasse es umformulieren. Und wie vorher schon gesagt, bin ich eben dann der Kontrolleur, im Endeffekt der Kurator, um zu gucken, ob alles passt. Das ist dann meine Rolle und auch das, was ich hier dazu steuer. Und ich habe da teilweise auch, wenn ich da so davor sitze und gucke und Diffs mache zwischen Altversion, Neuversion, das Gefühl, dass es für mich so ist wie so eine Rechtschreibkorrektur mittlerweile. Und da spricht auch keiner mehr darüber, hey, wurde jetzt dieses Buch mit der Rechtschreibkorrektur irgendwie durchforstet und hat gar nicht mehr so diese menschliche Elemente mit drin. Nee, das ist einfach ganz normaler Standard. Und ich finde, das Arbeiten jetzt zusammen mit meinen KI-Sparring-Partnern eben teilweise auch.

Anja: Ja, wunderbar. Gut. Möchtest du sonst noch was sagen, was wir noch nicht besprochen haben zu Qualitätstaktiken? Haben wir irgendwas vergessen?

Markus: Vielleicht kann ich noch eine kleine Roadmap zum Guten geben, wie es dann weitergeht mit dem Buch und dem sonstigen Projekt. Also ich bin jetzt erstmal am Finishen. Ich hoffe mal, dass ich so Ende des Jahres diese Print-Validierungersion auch bekomme, dass ich irgendwann sagen kann, ja, da sind jetzt alle wichtigen Qualitätstaktiken drin.

Und dann wird es natürlich dann, je nachdem, wie viele neue Qualitätstaktiken dazukommen, auf Leanpub immer weitergehen. Und wenn es mal wieder eine neue Ausgabe gibt, wird es auch wahrscheinlich über Amazon als gedrucktes Buch vertrieben werden, um dann einfach mal was in die Hand zu halten. Ich habe schon einen Probedruck, das ist auch schon da, das ist auch sehr nett, einfach so ein Buch zu haben, wo man ein bisschen blättern kann, ein bisschen schmökern kann, sich auch teilweise ein bisschen weiterbilden kann, um sich selbst so eine Art Werkzeugkiste zusammenzubasteln, die man dann auch auspacken kann, wenn man die braucht. Und das finde ich da auch ganz schön, wenn man eines dieser verschiedenen Formate hat, also Papier, E-Book oder sowas. Wenn man was in der Hand hat, in echt oder eben auf dem E-Book-Reader, das ist schon mal ganz gut. Und deswegen bin ich da nächsten Wochen noch dran, das zu finalisieren.

Und dann überlegen wir, wie wir weitermachen. Also, es gibt ja von Gernot Starke, vor allem im arc42 Umfeld, das quality42 Projekt. Das ist ja diese Anforderungsseite mit vielen Qualitätsszenarien, die noch mal in der Öffentlichkeit dann auch verfügbar sind, was man so tun könnte, was kann man formulieren sozusagen, wie ein Softwaresystem ticken sollte.

Und da wäre es natürlich nicht schlecht, dann teilweise auch mal so Qualitätstaktiken zu sehen. Und ich kann mir vorstellen, dass dann vielleicht mal so ein Buch noch mal ein bisschen dazu dienen kann, als Input, um ein paar Beispiele zu liefern dazu, damit man eben auch in der Öffentlichkeit da Qualitätstaktiken sammeln kann. Ich weiß noch nicht, wie weit es gehen kann, denn meine Mission ist eigentlich mit diesem Werk, das ich jetzt momentan schaffe, einfach so ein konsistentes Basisding erst mal zu schaffen, das Leute eigentlich erschlägt mit Lösungen. Und wie man das dann weiter treibt in der Community und sozusagen vom Qualitätslevel auf dem nicht hohen Niveau, auf dem gerade passenden Niveau hält, wie das Buch jetzt gerade ist, muss man noch sehen. Aber ich so in ein, zwei Jahren kann mir gut durchaus vorstellen, dass man das Ganze ein bisschen öffentlicher macht. Genau das wollte ich da noch sagen, also wie dann im Endeffekt das mit den Inhalten noch mal weitergehen kann.

Dann gibt es auch noch natürlich in den Schulungen für mich dann immer noch mal Anwendungsbereiche von dem Buch. Es gibt nämlich auch ein Karteikartenset als PDF-Format momentan. Das bringe ich da auch mal gerne mit und eben das andere Thema, das wir in der IT haben, zu simulieren, weil wir einfach erschlagen werden von den ganzen Lösungen, die da draußen sind. Und da einfach die Leute ein bisschen zu überfordern mit diesen ganzen Möglichkeiten und da Anhaltspunkte zu finden, hey, was kann ich jetzt aussortieren in den Qualitätstaktiken, die jetzt für mich gar nicht mehr infrage kommen können, als irgendwelchen rechtlichen Randbedingungen, da kann ich schon ganz viel kicken Richtung, keine Ahnung, Pair Programming, vielleicht darf ich nur Code anfassen, wenn jemand eine gewisse Person assigned hat und die muss mit ihren ganzen Vermögen haften, wenn sie dann eine Codezeile ändert.

Vielleicht bin ich in so einer Situation im Unternehmen natürlich jetzt ausgedacht, aber ein paar Dinge passen halt nicht, weil die Situation nicht passt, der Kontext nicht passt. Und da ist eben wichtig, diese Situationen auch erarbeiten zu lassen von den angehenden Softwarearchitekten und -architektinnen, mit dem Wissen, ey, was kann ich überhaupt noch, was bleibt jetzt noch übrig an den Qualitätstaktiken? Das ist auch noch so eine der Anwendungsfälle, die mir da noch einfallen, wo man eben auch das Buch nochmal nutzen kann.

Anja: Ja, klingt spannend. Jetzt haben wir so viel über die Qualitätstaktiken gesprochen und du hast zwar schon eine Qualitätstaktik vorgelesen, aber hast du da irgendwelche Lieblingstaktiken, die du gerne noch teilen möchtest oder kannst?

Markus: Ja, kann ich gerne machen. Ich pick mal welche heraus. Die sind nicht alle von mir, sondern die habe ich irgendwann aufgeschnappt und dachte mir, hey, die muss ich unbedingt festhalten. Beispielsweise bei dem Thema funktionale Eignung, wo es darum geht, auch fachlich das hinzustellen, was eben wirklich gebraucht wird. Da hätte ich das Domänenquiz anzubieten, also so gezielte Fragen zur Bewertung des Domänenwissen stellen in der Entwicklung, um einfach mal zu challengen, hey, kennen die Leute sich aus, sind die jetzt mitgekommen mit unserem Event-Storming-Workshops beispielsweise, die wir zusammen mit dem Fachbereich gemacht haben. Leben und atmen die Leute die Fachlichkeit, das können wir da gut vorstellen, dass man da ab und zu mal so eine Art Quizshow macht, kann auch ziemlich spaßig sein. Ich kann mir durchaus vorstellen, dass man sowas auch mal auf eine Team Event oder sowas durchführt.

Vielleicht hätte ich noch einen anderen Liebling hier. Das geht Richtung der Zuverlässigkeit. Ich habe das mal langweilige Technologien genannt. Also, dass man halt einfach Systeme nutzt oder Frameworks nutzt, allgemein Technologien, die halt bewährt sind, ausgereift sind, um dann weniger überrascht zu werden, wenn dann doch mal so ein Edge-Case auftreten würde in der Produktion. Warum nicht? Also kann bewusst eine Entscheidung sein, um eben dann auch mit stabilen Technologien potenzielle Fehler oder auch so Kompatibilitätsprobleme mit dem Betriebssystem oder Interoperationsprobleme mit anderen Systemen dann vorzubeugen. Das ist so ein Thema, das mir da noch eingefallen ist.

Und dann würde ich noch ein letztes nehmen. Oh ja, das nehme ich mal Richtung der Wartbarkeit, denn da hängt auch ein bisschen mein Herzblut dran. Living Documentation. Also so aktuelle und leicht zugängliche Dokumentation als einen integralen Bestandteil des Entwicklungsprozesses etablieren. Also nicht so öde irgendwie Leuten aufbürgen, hey, mach mal das Word-Dokument auf und ratter jetzt mal die Doku durch, wie das System so aussieht, wie die Architektur ist, sondern da eben intelligent herangehen, also Teile vielleicht aus dem Quellcode herausgenerieren lassen, damit man eben immer auf den aktuellen Stand ist, wie das System so dasteht, oder ja, halt sehr stark unter der Kategorie so Docs as Code auch nutzen, halt entwicklungsnahe Dokumentationswerkzeuge verwenden, um das Dokumentieren halt ein bisschen attraktiver zu machen, wo man ein bisschen mehr spielen kann, wo man ein bisschen die Kreativität ausleben kann, wo man eben Dokumentation und Code so Hand in Hand dann eben auch umsetzt. Das wird dann auch wichtig an der Stelle.

Anja: Ja, die Beispiele waren wirklich interessant. Gut, aber am besten liest du nicht zu viel vor, weil es muss noch jemand Interesse daran haben. Dann bedanke ich mich, dass du mit mir gesprochen hast zu dem Thema und bis zum nächsten Mal.

Markus: Ja, vielen Dank Anja. Und ja, dann bis dann mal wieder. Ciao.

Anja: Ciao!