Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Und bevor ich loslege, zeige ich noch mal, also sozusagen ein paar Worte in eigener Sache.
Und zwar gibt es ein Spreadshirt-Shop für Software-Architektur im Stream, das hier mal gezeigt, mit T-Shirts und Rucksäcken und Hoodies und allem möglichen, was man da irgendwie, was so das Herz begeht für Software-Architektur im Stream.
Ich packe das auch noch mal kurz in den Chat und packe das dann auch noch mal in die Links und verlinke das irgendwie auch noch mal auf der Webseite.
Wer also da irgendwie Lust drauf hat, sich mit dem Logo von Lisa zu zieren, sehr gerne.
Das wäre da eure Chance.
Genau, inhaltlich geht es heute um das Thema mit der Software-Qualität und ich, also das ist ein kompliziertes Thema.
Darüber kann man irgendwie lange reden.
Tatsächlich habe ich im Stream auch schon lange darüber geredet an verschiedenen Stellen.
Ich werde hier so ein paar Meinungen zum Besten geben und möglicherweise die Diskussion auch an einigen Stellen verkürzen.
Und eine Motivation für die ganze Geschichte ist halt, also ich bin halt Berater.
Das heißt, ich sehe halt häufig suboptimale Software.
Das Kreuz des Beraters ist eben, dass er Dinge sieht, die halt Beratung bedürfen, sodass eben genauso was wie suboptimale Software so ein Tätigkeitsschwerpunkt von mir ist.
Und die Frage ist halt, was müsste sich eigentlich bei uns ändern, damit ich arbeitslos wäre oder damit ich etwas Neues suchen muss.
Und was ich jetzt mit der Qualität genau genommen meine, und wie soll ich sagen, da bin ich ganz froh, dass halt so ein bisschen schon Feedback oder Fragen gekommen sind, die so ein bisschen in eine andere Richtung gehen.
Ich meine damit halt insbesondere Systeme, die halt keine vernünftige Struktur haben, wo die Geschäftslogik überall verstreut ist, nicht vernünftig strukturiert ist.
Also damit geht es insbesondere um Wartbarkeit.
Und Softwarequalität hat natürlich auch noch andere Aspekte, Performance, Zuverlässigkeit, Sicherheit, viel, viel andere Dinge.
Und die will ich so ein bisschen aussparen.
Qualitätsgetriebene Softwareentwicklung bedeutet eben, dass ich halt diese verschiedenen Qualitäten zum Übereinstimmen bringe.
Aber ich will mich hier insbesondere um Wartbarkeit und Struktur der Software kümmern, weil das eben auch die Kosten der Weiterentwicklung im Wesentlichen beeinflusst und damit auch die Kosten für die Anpassung an neuen Featuren darstellt.
Und genau, der Martin Egli bei LinkedIn hatte halt auch geschrieben, was ist denn eine schlechte Softwarearchitektur oder wie gut muss die Softwarearchitektur sein, wann ist die Softwarearchitektur gut genug.
Barry O’Reilly spricht von Criticality, ist das das Ziel?
Und ich kann noch mal wiederholen, das ist genau eigentlich die richtige Frage.
Wir wollen halt Software bauen, die halt insbesondere in Bezug auf die nicht funktionierenden Anforderungen halt vernünftig funktioniert.
Aber es ist eben auf der anderen Seite so, dass die meisten Sachen, die ich halt da draußen in der freien Wildbahn sehe, insbesondere in Bezug auf die Strukturierung, halt deutlich zu schlecht sind.
Und darum will ich mich insbesondere kümmern.
Und den Hamburg hat geschrieben, liegt es vielleicht ein Gefähr in der Qualitätssicherung.
Da meine ich nicht, guck mal, ich habe G-Unit-Test für das Qualitätsbewusstsein, bin ich mir nicht sicher.
Also und das passt vielleicht auch zu dem, was ich mir eigentlich als nächstes vorgenommen hatte zu sagen.
Das nervt halt viele beim Weiterentwickeln, das nervt halt vor allem TechnikerInnen und es ist tatsächlich auch einigen peinlich.
Das war für mich auch eine Motivation, diese Episode zu machen.
Ich komme halt häufig genug in Consulting-Einsätze und mir wird halt mal wieder eine suboptimale Architektur gezeigt.
Kein Wunder, weil sonst brauche ich halt irgendwie keine Beratung.
Und es scheint halt den Menschen peinlich zu sein, nahezu.
Was ja irgendwie bedeutet, dass halt das Qualitätsbewusstsein da ist.
Also die stellen sich halt im Prinzip hin und sagen, okay, wir wissen, dass es halt verguckt.
Sorry, wissen wir.
Guck mal, so sieht es halt bei uns aus.
Und genau, die in Hamburg hat ja auch geschrieben, eine interessante Frage, wer kann denn berichten lernen, wie es richtig gemacht wird?
Die, die schon mal richtig Mist gebaut haben und Lehrgeld bezahlt haben, große Fehler gemacht haben, ohne dem jetzt vorgreifen zu wollen.
Ich würde behaupten, ein Fehler, und das ist für mich auch motivatorisch, ist, dass man glaubt, man kann überhaupt eine sehr gute Qualität über das gesamte System erreichen.
Und die in Hamburg fragt weiter, oder die, die noch nie große Fehler gemacht haben und somit scheinbar wissen, wie man es macht.
Ich bin nicht sicher, ob es die sozusagen gibt.
Also es gibt so diese Ausnahmesysteme.
Mir würde halt immer Tech einfallen, das, wie nennt man das auf Deutsch, das Layout-System, Type-Setting-System, was der Donald Knus gebaut hat.
Das muss halt wirklich extrem sauber sein.
Es gibt sicherlich auch ein paar Beispiele, die halt irgendwie extrem sauber sind.
Aber meistens ist die Qualität suboptimal.
Und vielleicht ist das halt auch etwas Positives, weil wenn einem die Dinge, die man vor ein paar Jahren gemacht hat, nicht peinlich sind, ist man irgendwie auch stehen geblieben.
Von daher ist das vielleicht sogar was Positives.
Und ich hatte schon gesagt, dass es gegebenenfalls verkürzt.
Der Peter Sommerlath hat auf Mastodon geschrieben bezüglich diesem, wieso ist die Softwarequalität immer so schlecht.
Da frage ich mich nach fast 30 Jahren Posa 1 auch immer mal wieder.
Patterns of Software Architecture, das ist halt ein Buch.
Und er hatte dann weitergeschrieben, Plan eine Feier nächstes Jahr auf der Europlop.
Und das passt, glaube ich, zu dem, was auch die in Hamburg gerade sagte.
Das würde ja nur helfen, also nicht ein Buch wie das Posa-Buch, was tatsächlich wichtig ist, hilft halt nur dann, wenn wir es nicht besser wissen.
Ich bin mir aber jetzt sehr unsicher, ob das wirklich der Kern des Problems ist.
Meine Behauptung wäre, dass in vielen Fällen die Menschen, die da dran sitzen an dem System, wissen, wie es besser geht.
Aber vielleicht ist eben auch das ein Teil der Lösung.
Also ich laufe ja irgendwie rum und mache mir ganz viel zum Thema Modernisierung.
Das sind irgendwie krasse Grundlagen und hoffe halt, dass ich dadurch tatsächlich dazu beitragen kann, dass es eben besser wird.
Von daher ja, vielleicht ist das eben auch ein Teil der Lösung.
Und ja, also ich wollte hier eben offen darüber sprechen, weil wie gesagt, das ist dazu ein Tabuthema.
Und eine andere Auslöser für die Episode ist, ich hatte die Ehre, die Kino bei den XP Days in Stuttgart zu halten.
Und da ging es halt irgendwie darum, warum Agilität so ein Problem ist und warum das sich nicht durchgesetzt hat.
Ich habe irgendwie auf einer Folie gesagt, das Streben nach technischer Exzellenz, was im Manifest drin steht, ist meiner Meinung nach ein Problem.
Und das ist in gewisser Weise tatsächlich etwas, wo ich, also ich habe daraufhin Feedback bekommen.
Da war halt auch jemand am Stand, mindestens eine oder sogar zwei Personen, die hat irgendwie gesagt, die sich glaube ich insbesondere an dem Thema so ein bisschen aufgehangen haben.
Und ich bin dann irgendwie zu mir, also habe das sozusagen für mich auch nochmal Revue passieren lassen und habe halt festgestellt, dass da tatsächlich etwas, glaube ich, bei dieser Folie nicht so schön war, um es mal vorsichtig zu sagen.
Denn eigentlich versuche ich immer die typischen Probleme zu diskutieren, die da draußen bei den Kundinnen, die ich halt sehe, auch tatsächlich die Probleme sind.
Um dann zu sagen, die typischen Probleme, die ich so sehe, die würde ich halt folgendermaßen lösen.
Und das typische Problem da draußen ist halt nicht technische Exzellenz, übertriebene technische Exzellenz.
Sondern eher suboptimale Qualität und mangelnde technische Exzellenz.
Und deswegen ist es ein bisschen komisch, dann zu sagen, hey, das Streben nach technischer Exzellenz ist ein Problem.
Tatsächlich ist es etwas komplizierter.
Und in gewisser Weise stehe ich halt auch noch hinter dieser Aussage, dass das Streben nach technischer Exzellenz ein Problem ist.
Aber gleichzeitig ist eben der Mangel an technischer Exzellenz eben auch ein Problem.
Vielleicht noch, ich hatte ja damals die Folge gemacht mit dem Hillel Wayne darüber, ob wir eigentlich Engineers sind.
Also ob wir Ingenieure sind, so wie andere Ingenieursdisziplinen auch.
Und subjektiv habe ich halt immer das Gefühl, dass Ingenieursprodukte, die man halt da draußen sieht, so eine hohe Qualität haben.
Ich kaufe mir ein tolles Rennrad, das sieht irgendwie super aus, funktioniert super und hat irgendwie eine hohe wahrgenommene Qualität.
Und wie soll ich sagen, es ist halt auch ästhetisch sauber ansprechend.
Die meisten Softwarearchitekturen, die ich sehe, sind gerade nicht so, sondern sind irgendwie so, dass sie viel Optimierungspotenzial haben.
Gleichzeitig muss man aber eben auch dazu sagen, die Software und die Architektur lösen viele Geschäftsprobleme.
Und mein Rechner, der vor mir steht, ist halt im Wesentlichen zuverlässig.
Wenn der ein Problem hat, dann eher ein Hardwareproblem.
Das heißt, so schlimm kann es eigentlich nicht sein.
So, und der Danny Steinbrecher, auch tatsächlich noch von Mastodon, hat auch nochmal so ein Ding geschrieben, weil wir die falschen Technologien nutzen.
Deswegen sei es halt schlecht, bin ich sehr unsicher.
Ich würde halt behaupten, man kann in jeder Technologie guten oder schlechten Code schreiben und Dinge bauen, die gut oder schlecht behaltbar sind.
Oder zu wenig Meetings, das fand ich spannend.
Kommunikation hatten wir ja auch mal bei dieser Folge vom Java Forum Stuttgart als Problem identifiziert.
Vielleicht ist das eben auch tatsächlich das Problem.
Im Zweifel ist die Regulatorik oder die fehrende Zeit schuld.
So, und das ist genau dieser letzte Punkt, den der Danny da anspricht, nämlich die fehrende Zeit.
Die fehrende Zeit ist tatsächlich das, was ich glaube, wie gesagt, ich verkürze das halt ein bisschen, möglicherweise dafür verantwortlich ist, dass wir halt das Problem haben, was wir haben.
Also Zeitdruck habe ich mir aufgeschrieben.
Ich habe mir auch noch aufgeschrieben, falsche technische Entscheidungen, die aber manchmal so auf Management-Ebene gefällt werden.
Also, dass ich sage, ich benutze halt Microservices, weil heute macht man das ja so.
Und das ist etwas, was auf dieser Granularität nach Management kompatibel ist.
Oder vielleicht auch solche Sachen, dass man halt sagt, ich habe eine Aufteilung von Aufgaben auf irgendwelche Teams, auch eine Management-Entscheidung.
Aber das ist eben auch eine Architektur-Entscheidung, weil diese Teams dann jeweils an einem Teil des Systems arbeiten werden.
Also insgesamt ist es so ein bisschen nicht.
Also in erster Instanz würde ich jetzt, dass den schwarzen Peter, ich glaube viele Leute, die jetzt aus der Technik-Ecke kommen, erstmal sozusagen dem Management halt zuweisen.
Und würde halt sagen, naja, das Management erzeugt halt Zeitdruck.
Das Management trifft irgendwelche grobgranularen technischen Entscheidungen.
Wir machen Microservices, die halt irgendwie schwierig sind.
Und er sagt halt, wir haben ein Team, das sich um den Kunden kümmert und dann habe ich eine Kundenkomponente.
Und wir wissen halt, die Verwaltung von solchen Daten ist vielleicht ein Problem.
Das ist eben eine Architektur-Entscheidung, die halt indirekt gefällt wird, weil eben eine Management-Entscheidung zugunsten des Aufgabenbereiches eines Teams getroffen wird.
Und das bedeutet und in einigen Stellen führt das auch tatsächlich zu Dingen, die, wie soll ich sagen, intuitiv irgendwie klar sind und sinnvoll und logisch, aber dann halt verheerende Konsequenzen haben.
Also wenn ich mich hinstelle und sage, ich kann halt dafür sorgen, dass das Team irgendwelche Dinge schneller produziert, ist das ja erstmal eine sinnvolle Entscheidung.
Also ich kann eben schneller irgendwelche Werte generieren, ich kann Business-Logik implementieren und ich wüsste nicht, warum man das nicht tun sollte.
Aber genau durch dieser Zeitdruck, der dann entsteht, ist halt potenziell ein Problem.
Und ich glaube tatsächlich, dass das eben ein Grundproblem ist.
Da gab es noch ein interessantes Feedback eben genau am Stand von den XP Days.
Da berichtete halt die Person, mir ist ehrlich gesagt der Name entfallen, dass sie die Erfahrung gemacht hat, dass es so künstliche Deadlines sind.
Also das war die Deadlines, wenn man sie hinterfragt.
Also das heißt, es gibt keine Deadline, also wir müssen zum 1.1. oder zum 1.5. live gehen.
Aber das sind künstliche Sachen, man kann nicht herausfinden, warum denn nun diese Deadline ex act gilt.
Und diese Person hat dann selber mal einen Management-Job übernommen und hat dann tatsächlich angefangen und hat Deadlines hinterfragt und dann ist das so ein bisschen in sich zusammengebrochen.
Sprich, dann wurde halt irgendwie offenbar, dass diese Deadlines irgendwie künstlich sind.
Und ich will gar nicht sagen, ob das halt nun stimmt oder nicht.
Ich halte das aber für glaubwürdig, also ob das ein allgemeines Konzept ist.
Die Aussage, glaube ich, ist auf jeden Fall glaubwürdig.
Und vielleicht ist es daneben so, dass Deadlines eher so ein Leistungsbeweis sind.
Also unter meiner Leitung mit dem Team, das ich habe, können wir halt wahnsinnig schnell irgendwelche Dinge auf die Reihe bekommen.
Und dann entsteht halt eigentlich ein Zeitdruck, der nicht wirklich notwendig ist durch eine Deadline.
Im Sinne von, wir müssen halt nun wirklich zu diesem Zeitpunkt online sein, weil sonst haben wir halt irgendwelche Schäden, die entstehen durch Gesetze, die wir brechen.
Oder weil nun tatsächlich irgendjemand im Markt die Marktpositionen übernimmt oder was auch immer.
Also das bedeutet, dieser Zeitdruck ist vielleicht oft irreal.
Und ich glaube, das andere Problem, was uns da so ein bisschen zu einem Problem führt, ist die Sichtbarkeit technischer Probleme.
Also wenn ein Rennrad irgendwie komisch ist, dann kriege ich das mit, weil ich das halt einfach sehen kann.
Ich kann es halt visuell wahrnehmen.
Und ich kann ja auch irgendwie sehen, wie es sich sozusagen verhält.
Bei Code, mindestens bei Codequalität, kann ich das nicht direkt sehen, wenn ich eben von draußen drauf gucke.
Also beim Rennrad sind halt die Bauanzüge verlegt und ich habe halt irgendwie das Rad und die Speichen und all diese ganzen Geschichten.
Und ich kann irgendwie sehen, ob das halt irgendwie vernünftig funktioniert und halt irgendwie vernünftig aussieht.
Die Sachen halt irgendwie gut verlegt sind oder eben auch nicht.
Und beim Code ist es eben so, dass ich in den Editor reingucken muss und ich sehe es von draußen eben nicht.
Und auch diese anderen Sachen sind nicht so richtig offensichtlich.
Also dass ich halt nur, weil ich Teams Aufgaben gebe, die Architektur beeinflusse.
Uns ist das klar, das ist Conway’s Law, ob das Management Class ist nicht so sicher.
Das sind irgendwie Leute, die einen anderen Hintergrund haben.
Und auch so eine technische Entscheidung, also warum ist der Microservices eine problematische technische Entscheidung?
Also vielleicht ist sie das ja auch irgendwie gar nicht.
Sondern das führt irgendwie dazu, dass halt diese Dinge, die halt dann tatsächlich dort heraus gemacht werden oder die halt dazu führen, dass wir diese massiven Probleme haben.
Dass die halt nicht auf den ersten Blick sofort zu diesen Problemen führen.
Und diese Probleme sind halt erst mal nicht sichtbar.
Also ich kann ein Microservices System bauen, auch wenn Microservices nicht die sinnvolle Lösung sind.
Es ist nur viel aufwendiger und es sorgt dafür, dass halt im Rechenzentrum mehr Server beteiligt sind.
Und dass irgendwie vielleicht Antwortzeiten langsamer sind.
Davon sehe ich aber höchstens die langsamen Antwortzeiten.
So und dazu passt dieses Thema rund um Technical Debt.
Ich habe tatsächlich ja mehrere Folgen zu diesem Thema gemacht, die kann ich auch sicher verlinken.
Und da gibt es halt eine ganze Menge an Diskussionen, die man darum führen kann.
Ich glaube mittlerweile, dass der Hauptgrund von Technical Debt ist, dass eben Druck entsteht auf das Team und dann gute Praktiken zusammenbrechen.
Und das ist deswegen wichtig, weil diese Metapher, wenn man sie sozusagen profan versteht, sagt etwas anderes.
Technical Debt sagt, ich nehme eine Schuld aktiv auf, um sie später abzubezahlen.
Was ich jetzt behaupten würde, ist, was in Wirklichkeit passiert ist, dass ich halt anfange und sage, wie kriege ich die Deadline denn jetzt doch noch hin?
Dann nehme ich irgendwelche wilden Abkürzungen und dann bin ich halt am Ende bei einem System, dass das, was irgendwie gefordert ist, tatsächlich tut.
So irgendwie hingehackt.
Aber ich habe die Qualität des Systems kompromittiert.
Und das ist nicht so, dass ich mir jetzt aktiv gesagt habe, hier, hier, hier und hier gehe ich eine Schuld ein und ich werde sie irgendwann abbezahlen.
Sondern ich habe einfach dadurch, dass ich konsequent, schnell, abkürzend gearbeitet habe, diese Technical Debt Sachen erzeugt.
Und nicht man kann darüber größer diskutieren.
Ich muss es hier verkürzen, weil ich habe halt nicht so wahnsinnig viel Zeit.
Ich habe irgendwie stundenlang tatsächlich über Technical Debt gesprochen.
Und dann ist eben tatsächlich der Zeitdruck das zentrale Problem für diese schlechte Qualität.
Oder eben analog diese Entscheidung, nicht Teamaufteilung oder die Benutzung von irgendwelchen Technologien.
Die hat dann dazu führt, dass es einfach nicht passt und dass man dann zu einem Ergebnis kommt.
Das ist eine Tease.
Aber das ist gerade das Gegenteil von dem, was ich in der Keynote gesagt habe.
Das würde jetzt bedeuten, das Problem, was wir in erster Linie in der Industrie haben, ist durch hohen Zeitdruck, der nicht wirklich motivierbar ist.
Und durch andere Entscheidungen, die auf Form-of-Management-Ebene getroffen werden, kommen wir in eine Situation, dass das, was hinten rauskommt, suboptimal ist.
Und das ist leider nicht offensichtlich sichtbar.
Es ist nicht so, wie wenn das Rennrad jetzt irgendwie produziert wird und wir sehen, das kann offensichtlich nicht funktionieren.
Sondern es ist irgendwie Kot und ist dadurch nicht sichtbar.
Und deswegen haben wir da ein Kernproblem.
Und diese Dinge sind nicht so offensichtlich.
Und da ist wieder diese Geschichte mit dem, was ich am Anfang sagte.
Hilft es uns jetzt, wenn wir eine Stunde über Technische Depth reden und das sozusagen detailliert verstehen?
Bin ich mir nicht sicher.
Weil beim nächsten Mal, wenn der Zeitdruck auftritt oder irgendwelche Dinge entschieden werden, werde ich wahrscheinlich wieder in dasselbe Verhalten und dasselbe Problem reinlaufen.
So und jetzt kommt der Punkt, der so ein bisschen aus dieser Kino zurückkam.
Also es bedeutet jetzt, dass im Prinzip die Aussage kommt, Management entscheidet irgendetwas.
Wir stehen halt irgendwie da und sagen, cool, dass es diese Entscheidung gibt.
Die führt halt irgendwie in Chaos.
Wir wissen vielleicht auch, dass sie ins Chaos führt.
Jetzt ist halt die Frage, was ist eigentlich die Reaktion?
So die Reaktion, auf die ich mich jetzt in der Kino bezogen habe, ist.
Wir machen einfach die maximale Qualität.
Punkt.
So das heißt also, wenn man diese Idee in diesem Fall kommt es aus dem angegeben Manifest oder nicht.
Aus Extrem Programming hat das zum Beispiel auch.
Wir wollen halt irgendwie die Qualität ganz hoch drehen.
Software Craftsmanship hat diese Idee auch.
Ich sage halt, ich möchte stolz auf das sein, was ich baue.
Craftsmanship orientiert sich irgendwie an Handwerk und an den Ideen, die im Handwerk sind.
Ich möchte also handwerklich gute Sachen bauen.
Und das bedeutet, ich will halt hohe Qualität liefern und das überall.
So und meine Behauptung ist, das ist auch übertrieben.
Und das ist dasselbe, nur mit anderen Vorzeichen.
Also das heißt, wir haben im Prinzip zwei Extreme.
Wir haben einmal das Extrem, was halt sagt, mir ist das völlig egal, was da an Qualität herauskommt.
Ich verstehe diese Technik auch nicht.
Wir machen jetzt ein Microservices System unter hohem Druck.
Und so ist die Teamaufteilung.
Was bedeutet, dass Techniker in sich dann letztendlich gefunden in einem System gefangen sind, in dem sie gar nicht ein qualitativ hochwertiges System im Sinne von Wagbarkeit bauen können.
Und die Reaktion ist halt zu sagen, nee, nee, nee, nee, das machen wir nicht, sondern wir drehen halt die Qualität auf Maximum.
So und das heißt, auf der einen Seite haben wir die Extremposition, die sagt, das mit der Qualität ist halt völlig egal.
Wir machen halt gar nichts.
Auf der anderen Seite haben wir die umgekehrte Maximalposition, die irgendwie sagt, Qualität ist das Wichtigste ever.
Und wir müssen halt da auf jeden Fall die beste Qualität ever liefern.
So und für mich ist da der wichtige Punkt, die Sache, die mir da sozusagen als erstes oder die, glaube ich, tatsächlich extrem zentral ist, ist diese Idee von der Core Domain.
Das, was hat Eric Evans eingeführt hat in Domain Design.
Und was er halt sagt, ist, wir können eben nicht überall die maximale Qualität erreichen.
So und diese beiden Maximalpositionen, also die eine Position sagt, Qualität ist egal.
Wow, das bedeutet halt, dass wir halt am Ende in einem System tatsächlich landen, was irgendwie schwer weiterentwickelbar ist.
Teile eines Systems die maximale Qualität haben können.
So, und da kommt jetzt eben Eric Evans und sagt, es ist bedauerlicherweise so, also bedauerlicherweise hat er, glaube ich, nicht gesagt, aber es ist so, dass wir irgendwie nicht überall die maximale Qualität erreichen können.
Deswegen brauchen wir eine Core-Domain.
Vivo hat nochmal gesagt, ist ein wichtiger Punkt, nicht hier auch zu definieren, was mal mit Qualität gemeint ist.
Ich hätte es am Anfang, glaube ich, versucht zu sagen, ich meine damit Qualität im Sinne von Wartbarkeit, Code-Qualität, diese Sachen nicht vernachlässigen, gerade die anderen Qualitäten im Sinne von Software-Qualität, also die ganzen Elites, nicht Scalability, Security und was halt sonst noch, wie Performance, solche Sachen, sondern ich möchte mich hier irgendwie auf Code-Qualität und diese und Wartbarkeit halt insbesondere fokussieren.
Wenn ich also sage, so wie Eric das sagt und ich habe überhaupt keinen Zweifel daran, dass das wahr ist, weil ich würde behaupten, es ist offensichtlich so, ich kann nicht überall die maximale Qualität erreichen, dann brauche ich ein Trade-off.
Und das bedeutet, ich muss einen Kompromiss eingehen.
Und das bedeutet halt, dass genau diese Menschen, die jetzt irgendwie sagen, wir müssen aber überall die maximale Qualität erreichen, die wollen halt diesen Trade-off nicht treffen.
Und das schlägt, glaube ich, dann um.
Also wenn ich halt in einer Realität lebe, in der ich eben nicht überall die maximale Qualität erreichen kann, das aber versuche, dann werde ich scheitern.
Und am Ende ist die Qualität irgendwie random über das System verteilt.
Das heißt, ich habe halt Teile, wo ich das halt mit meinen hohen Anstrengungen geschafft habe, das Ziel zu erreichen und andere Teile, wo ich das eben nicht habe.
Und das war eigentlich für mich der Grund, warum ich halt genau dieses Thema in der Keynote diskutiert hatte, weil ich eben glaube, dieser Ansatz zu sagen, hey, wir wollen halt die höchste Qualität überall und wir wollen technische Exzellenz.
Das ist am Thema vorbei.
Wir müssen diese Kompromisse eingehen und wir müssen das aktiv steuern.
So und vermutlich ist aber dieses Problem nicht.
Ich versuche halt irgendwie überall sinnlos, die höchste Qualität zu erreichen.
Kleiner ist das Problem.
Ich habe Zeitdruck und mir bricht das System insgesamt zusammen.
Und das wird von daher ist es, glaube ich, wie gesagt, eben so, dass wir insbesondere in dieser Zeit und diese Geschichte hat, glaube ich, wichtiges Thema sind.
Kurzer Ausflug, weil mir das sozusagen auch noch wichtig ist.
Wir haben dazu eine Episode gemacht.
Ich habe diese Episode gemacht zur Retrospektive von Extreme Programming und das Projekt, was ja Extreme Programming damals sozusagen aus der Taufe gehoben hat, war dieses C3 Projekt bei Chrysler.
Es gibt ja dieses sehr schöne Buch über was eben Extreme Programming so ein bisschen in Frage stellt.
Und da ist halt eine der Aussagen, dass eben dieses C3 Projekt am Ende gescheitert ist.
Also erst mal da geht es halt um eine Payroll.
Da geht es also um die Lohnabrechnung von Chrysler war das damals.
Das war Chrysler kurz vor dem Zusammenschluss mit Daimler Ende der 90er.
Und dieses Projekt ist halt letztendlich eingestellt worden und hat eben auch nie einen signifikanten Teil der Lohnabrechnung gemacht.
Und ein Grund dafür kann durchaus sein, dass eben dieser hohe Qualitätsanspruch zusammen mit dem dauernden Refactoring dazu geführt hat, dass das Projekt eben nicht mehr besonders produktiv ist.
Das müsste man nochmal nachrecherchieren.
Ich habe das jetzt sozusagen mal gespart.
Aber sowas könnte eben eine Illustration dafür sein, dass dieser hohe Qualitätsanspruch wirklich zu Problemen führt.
So und das bedeutet, wir können eben nicht überall die Qualität auf 100 Prozent stellen, so wie Extreme Programming das versucht, selbst wenn wir es wollten.
Und ich glaube, wir wollen es auch nicht, weil es an einigen Stellen einfach unwirtschaftlich ist.
Das heißt, wir müssen an den wesentlichen Stellen so viel Qualität bauen, wie wirtschaftlich ist.
Das ist die einzige echte Möglichkeit.
So und jetzt fängt es an und wir müssen eigentlich beide Seiten zusammen bekommen.
Das heißt also, wir müssen jetzt auf der einen Seite brauchen wir Management, was zum einen sagt, wir reduzieren den Druck und zum anderen halt auch sagt, wo brauchen wir denn eigentlich genau diese Nachhaltigkeit?
Also eigentlich ist Qualität im Sinne von Wartbarkeit und Kodqualität ein Thema von Nachhaltigkeit.
Ich kann also mit hoher Kodqualität und guter Wartbarkeit nachhaltig mit konstanter Geschwindigkeit Software entwickeln.
Und das ist dann sinnvoll und hilfreich, wenn ich das muss.
Also wenn ich jetzt ein Stück Software baue für ein Business Case, ich weiß nicht, wir haben jetzt Weihnachten kurz vor uns, wo ich irgendwie sage, zur Adventszeit 1.12. will ich live damit sein.
Am 24.12. werfe ich es weg.
Dann ist es halt sehr egal, welche Qualität dieses Ding hat, weil ich werde es nie weiter warten müssen.
Es ist nur dann ein Problem, wenn die Qualität bereits zuschlägt, während ich es draußen habe.
Also wenn ich jetzt irgendwie vom ab dem 1.12. bis zum 24.12. noch Änderungen daran machen muss und die sind bereits wahnsinnig schwer, dann ist es vielleicht gut, eine hohe Qualität zu liefern.
Aber nach dem 24.12. ist die Qualität völlig egal, weil dann mache ich halt irgendwie garantiert keine Änderungen mehr, sondern ich habe den Code weggeworfen.
Und das könnte eben sein, dass ich so einen Fall habe.
Ich glaube, in vielen Fällen ist auch das Problem, dass man eben Management nicht glaubt, dass das so ist in diesem Fall.
Aber das ist ja genau das Problem.
Also ich muss jetzt aus Management Sicht eine glaubwürdige Aussage bekommen, die halt sagt, dann müssen wir es haben.
Also nicht künstlicher Zeitdruck.
Das ist etwas, was wir nachhaltig entwickeln wollen.
Das ist etwas, was wir garantiert nicht nachhaltig entwickeln wollen.
Oder das wissen wir noch nicht so genau.
Und das ist halt die eine Seite, die sozusagen diese Anforderungen stellt und das halt konkretisiert.
Das sind ja letztendlich Geschäftsentscheidungen, die dahinter stecken.
Das heißt also, ich muss mich jetzt entscheiden.
Will ich halt Features haben?
Will ich Erwartbarkeit haben?
Und da muss ich da irgendwie sozusagen loslegen.
So die Entwicklung muss auf der anderen Seite die Qualitätsprobleme auch kommunizieren, sodass Management es versteht.
Und das ist auch einer der Punkte, die ich halt schwierig finde und auf die ich mich halt auch, wie soll ich sagen, beziehen wollte.
Beispiel also so erlebt.
Ich habe also ein Team.
Dieses Team geht aus bestimmten Gründen an einer technischen Infrastruktur Komponente vorbei, weil sie die nicht nutzen darf.
Da gibt es also eine Architekturregel, die sagt, diese Infrastruktur Komponente ist für diesen Fall nicht zu nutzen.
Okay, ich bin ein Software Architekt, das heißt, was ich jetzt mental von meinem Auge sehe, ist, da ist irgend so ein Ding, da ist ein Abhängigkeitspfeil.
Der darf jetzt nicht zu der technischen Komponente gehen.
Ich habe also ein Pfeil zu wenig, der irgendwie komisch ist.
Okay, so ist irgendwie unschön, aber nicht Abhängigkeit, die nicht da sein sollten oder so, das ist mein täglich Brot.
Also habe ich eigentlich Schulterzucken.
Später hat sich herausgestellt, dass das dazu geführt hat, dass dieses Team zusätzliche Aufwände hat und zwar eben auch Signifikante.
Damit wird das von, wir haben ja ein Problem, wo irgendwelche Boxen und Freileit nicht zusammenpassen, zu einem Problem, das halt etwas Auswirkungen hat potenziell auf eine Deadline und auf Auswahl Aufwand.
Das heißt also, wenn ich dieses Problem kommuniziere als Techniker und sage, wir haben gerade so und so viel Aufwand verbraucht und wir haben deswegen so und so viel Verzug, habe ich eine andere Kommunikation und eine andere Basis, als wenn ich mich hinstelle und sage, da ist übrigens diese Abhängigkeit.
Wir dürfen diese Infrastruktur Kompetente nicht benutzen.
Warum eigentlich?
Das ist doch eigentlich doof und inkonsistent.
Letzteres ist halt so ein abstraktes Qualitätsding, was irgendwie sagt, nicht irgendwie soll das so aussehen, wie die Architektur es vielleicht fordert.
Ersteres ist etwas, was ich sozusagen in Euros ausrechnen kann.
Also ich kann in Euros ausrechnen, wie lange ich die Entwickler beschäftigt habe und überflüssig beschäftigt habe und ich kann in Euros ausrechnen, was es mich kostet, dass diese Software zu spät live geht.
Das ist etwas, woran wir als Techniker arbeiten können, diese Kommunikation zu verbessern.
Und das ist meiner Ansicht nach auch.
Also das ist etwas, was mir in letzter Zeit irgendwie so auffällt.
Ich sehe bei Techniker in subjektiv in meinem Erlebensfeld in letzter Zeit zunehmend das Problem, dass solche Sachen halt ertragen werden.
Es wird nichts hinterfragt.
Es wird einfach stumpf ausgeführt und es wird kein Feedback gegeben.
Ja, liebe Leute, da müsst ihr euch ja auch nicht wundern, wenn es halt irgendwie komisch aussieht.
Also ich bin irgendwie Manager.
Ich habe keine Ahnung davon, was Software Architektur ist.
Irgendjemand kommt zu mir und sagt, welche Abhängigkeiten sind komisch.
Okay, cool.
Was soll ich tun?
Ist mir relativ egal und meiner Ansicht nach auch zu Recht egal.
Wenn jemand zu mir kommt und sagt, du hast da gerade den Deadline gerissen und hast da gerade Geld ausgegeben.
Das war einfach unnötig.
Das ist ein anderes Thema.
Diese Art von Kommunikation können wir ändern und ich glaube auch tatsächlich, dass es unsere Pflicht ist.
Wir können jetzt unmöglich von Menschen verlangen, die in so einer Position wie Management sind, dass die sich halt irgendwie hinstellen und sagen, ich kann darüber hinaus alles, was so mit Technik zu tun hat.
Das sind zwei unterschiedliche Felder.
Wir brauchen Kommunikation und wir brauchen sozusagen zielgruppenorientierte Kommunikation.
Was eben bedeutet Kommunikation in Bezug auf Aufwand, Deadline, Kosten, solche Geschichten.
Weil das ist die Welt, in der die sich halt sozusagen bewegen.
Genau.
Der Adam hat gerade im YouTube Chat gefragt, welche Methoden zur Förderung der kontinuierlichen Verbesserung sind empfehlenswert.
Also das, was ich hier irgendwie gerade anfange zu sagen, ist irgendwie Kommunikation.
Man kann das natürlich auch technisch angehen.
Wir haben zum Beispiel ganz viele Episoden.
Ich kann ja auch noch mal verdenken zum Thema Architekturmanagement.
Da gibt es verschiedene Werkzeuge, um dafür zu sorgen, dass eben eine Architektur eingehalten wird und hat eine bestimmte Code-Qualität, dadurch eben bestimmte Abhängigkeiten sozusagen eingehalten werden.
Die Werkzeuge kann man irgendwie benutzen.
Einige davon sind auch kostenlos.
Ich habe den Link gerade zu den Episoden in den Chat getan, aber ich packe das auch noch mal in die Zusammenfassung.
Und nicht so Werkzeuge, die halt Statische Geburtanalyse betreiben.
Sona ist da, glaube ich, das berühmte Beispiel, sind eben dann Werkzeuge, die ich halt zum Beispiel auch einführen könnte, um mir irgendwie auf dieser Ebene von Verbesserung und Code-Qualität zu optimieren.
Genau.
So.
In dem Zusammenhang, also diese Folge ist ja auch bei Reiseforen gekündigt worden, da gibt es halt irgendwie die Reiseforen und ein Kommentar dort war eine Antwort, weil es dem Kunden nicht schnell.
Also eine Antwort, eine Aussage dort war eine Antwort auf die Frage, warum denn nämlich Softwarequalität so schlecht es ist, weil es dem Kunden nicht schnell und billig genug sein kann, da bleibt die Qualität schon mal auf der Strecke.
Das nächste Opfer dieses Um- oder Missstands ist dann die Dokumentation.
Ich weiß nicht, wie es dieser Person geht, aber wenn ich heute Abend einkaufen gehe oder überhaupt einkaufen gehe, dann kaufe ich das billige Produkt unter der Voraussetzung, dass es eben dieselbe die Funktion erfüllt, die ich gerne haben möchte.
Anders gesagt, wenn es teurer ist, muss ich einen Vorteil haben.
Also ich habe kein Problem damit, für ein Bioprodukt mehr Geld auszugeben, weil es ist ein Bioprodukt, es hat also eine gewisse andere Qualität.
Aber wenn ich zwei Bioprodukte habe, die scheinbar dieselbe Qualität haben, kaufe ich das billigere.
Das ist die wirtschaftliche Welt, in der wir halt irgendwie leben.
Und das bedeutet, wenn man nicht begründen kann, warum man irgendetwas macht, also welchen Vorteil das hat, dann wird es nicht passieren.
Und einem Kunden vorzuwerfen, dass er gerne sein Zeug schnell und billig haben will, wie gesagt, ich würde gerne mal sehen, wie man dann beim Supermarkt einkaufen geht.
Also gehe ich jetzt hin und nehme das teuerste Produkt?
Nee, mache ich halt irgendwie nicht.
Ich mache es nur dann, wenn das teurere Produkt einen klaren Vorteil hat.
Das müssen wir also irgendwie kommunizieren.
Und es kann nicht sein, wie man hier daraus jetzt irgendwie sozusagen, wie soll ich sagen, wenn ich dieser Person sozusagen das Wort im Mund umdrehen dürfte, würde ich halt sagen, was bedeutet das denn?
Qualität bedeutet, Software wird langsamer und teurer.
Das ist offensichtlich absurd.
Das heißt also, ich muss eine andere Art von Kommunikation haben und ich muss andere Vorteile in den Raum stellen.
Und das muss auch gehen, denn die Art und Weise, wie Techniker darunter leiden, dass die Qualität schlecht ist, wird sich in Zahlen niederschlagen.
Es ist ja nicht so, dass man irgendwie da sitzt und sagt, wow, das ist langsam und frustrierend, aber es ist ja effizient aus einem wirtschaftlichen Aspekt heraus.
Sondern es geht ja Hand in Hand.
Das, wo wir irgendwie Techniker frustriert sind und viel Zeit brauchen, ist etwas, was auch wirtschaftlich ineffizient ist.
Sondern das bedeutet, dass man eigentlich sagen müsste, wenn es dem Kunden nicht schnell und billig genug sein kann, dann liefern wir gute Qualität, weil damit kriegen wir billige Software.
Und ich kann dir zeigen, mit welchen Maßnahmen wir diese Software billiger bekommen.
Und das bedeutet aber, dass da eben tatsächlich ein Kommunikationsproblem ist und es irgendwie nicht klar ist, wie man das klar kommunizieren kann.
Die in Hamburg hat jetzt hier…
Also sorry, ich wollte nur nochmal schauen, dass ich den Gedanken abgeschlossen habe.
Die in Hamburg hat geschrieben, aber wie kriegt man die Leute dazu, drohende Kosten früher anzugeben, wenn man das nicht genau schätzen kann?
Also ich bin sozusagen nicht sicher, ob ich die Frage so ganz richtig verstehe.
Ich sage mal was dazu und es gibt ja immer die Möglichkeit, Nachfragen zu stellen.
Das Erste, was ich gesagt habe, ist, ich glaube halt nicht, dass das Grundproblem von Qualität ist, dass man sagt, ich habe hier eine Entscheidung und ich nehme jetzt die Abkürzung und ich weiß, dass diese Abkürzung hat folgenden Vor- und folgenden Nachteil hat, sondern meine Behauptung ist, dass in den meisten Fällen das einfach durch Zeitdruck entsteht.
Das heißt also, wenn ich in der Situation bin, dass ich jetzt sage, ich habe hier zwei Möglichkeiten und ich schätze die halt objektiv ab und mache mir über die Konsequenzen aktiv Gedanken, dann sind wir meiner Ansicht nach schon nahe beim Ergebnis.
Das heißt, ich bin nicht, also ich würde behaupten, wenn ich schon früh die Kosten und die möglichen Effekte mir überlege und eine aktive Entscheidung treffe, ist das Problem vielleicht schon gelöst und das andere ist Schätzen beziehungsweise Schätzen als Basis von Entscheidungen ist ja tagtägliches Geschäft.
Das machen wir ja irgendwie dauernd.
Agiles Schätzen ist halt genau diese Basis und ich glaube, was dabei halt wichtig ist, ist, das soll ja nur eine Entscheidung ermöglichen.
Also es ist ja nicht so, dass ich daraus eine Deadline ableite und jetzt sage, also in genau zehn Monaten haben wir das und das geschafft oder in zwei Wochen oder so, sondern es geht darum zu sagen, ich habe diese beiden Alternativen.
Diese Alternative ist aufwendiger als die andere, hat aber dafür den Vorteil, dass wir halt langfristig dort leichter das System modifizieren können, während die andere eben genau das Gegenteil hat, ist halt kurzfristig leicht realisierbar, hat aber langfristig dann führt sie zu Schwierigkeiten und dann muss ich halt irgendwie abschätzen, welche von den beiden mit dem, was ich halt im Moment weiß, wahrscheinlich bessere Alternative ist und dafür brauche ich aber jetzt nicht zu sagen, das eine sind zehn oder das andere sind fünf Tage oder zehn oder fünf Wochen, Monate, was auch immer, sondern ich muss halt nur sagen, das ist halt wahrscheinlich die Sache, die halt weniger aufwendig ist in Summe, nicht also eben auch über die längere Laufzeit und das bedeutet, ich muss nur eine grobgranulare Abschätzung haben.
Gut, so was bedeutet das jetzt?
Das ist so ein bisschen mein Problem, also das, was ich mir jetzt eigentlich wünschen würde, wäre, dass wir eben genau diese Diskussion, von daher passt die Frage von die in Hamburg gerade sehr gut da rein, dass wir die halt jetzt treffen, diskutieren würden.
Also wir würden jetzt irgendwie dem Team sagen, hört mal zu, wir haben ja zwei Möglichkeiten, entweder wir machen es halt so oder wir machen es halt so, welches ist denn die bessere Möglichkeit und dazu muss jetzt irgendwie Management sagen, also wahrscheinlich werden wir dieses Stück Code nie wieder anfassen oder am 24.12. ist das Ding sowieso obsolet und wir werfen es weg, das muss irgendwie glaubwürdig sein oder nicht, vielleicht sagt das Management auch, naja, wenn wir es halt am 1.12. nicht geliefert haben, ist es sowieso sinnlos, weil dann ist halt der Business Case weg, das muss also auf jeden Fall da sein, also wir müssen halt Informationen über eine harte Deadline, über eine weiche Deadline, über den Trade-Off, über die Dinge, die halt in Zukunft da in Änderung kommen und so weiter, die müssten wir halt alle bekommen und gleichzeitig müsste dann halt die Technik dazu willentlich und in der Lage sein, das Zeug irgendwie abzuschätzen, wie die in Hamburg halt sagt und irgendwie auch sozusagen dem Management zu vertrauen, dass das, was die sagen, also wenn die sagen, da ist halt diese Deadline oder wenn die sagen nicht, das fassen wir nie wieder an oder wir werfen es weg, das eben auch tatsächlich zu glauben, so und das würde dann zu einer offenen Kommunikation führen und dann würden wir halt irgendeine Entscheidung treffen, so und das Problem bei der Sache ist, dass das, glaube ich, in den allermeisten Fällen oder lass mich anders sagen, ich würde behaupten, das wünsche ich mir, aber das kriege ich halt in der Realität in dem Projekt meistens nicht hin, was dazu führt, dass halt man andere Maßnahmen ergreifen kann, die irgendwie funktionieren, also zum Beispiel Maßnahmen, dass man sagt, von dem 14-Tage-Sprint oder 10-Tage-Sprint nehmen wir uns jetzt zwei Tage und die investieren wir halt in die Verbesserung des Systems, so und das ist etwas, was klar sagt, es ist eingehalten oder nicht, wir können es halt am Ende uns angucken und wir können halt sagen, von den zehn Tagen Sprint sind halt zwei Tage tatsächlich in Verbesserung gelaufen, geflossen, das können wir halt anschließend in den Checkmark setzen und können halt sagen, das ist tatsächlich passiert, ist also easy und diese Zeit können wir halt auch sozusagen leicht schützen, wir tun halt so, als hätte dieses Team eben nur eine Kapazität von acht Tagen, nicht von zehn und diese zwei Tage sind eben tatsächlich zur Verbesserung der Qualität da, wir können also dadurch dafür sorgen, dass eben dieser Zeitdruck sozusagen gemanagt wird und eben nicht zu stark wird und wir können irgendwie dadurch versuchen, dieses System zu sanieren.
Das Problem bei der Sache ist, dass man dadurch auch eben diese Entscheidung so ein bisschen entkoppelt von dem, was das Management benötigt, also was da halt im Worst-Case rauskommen kann, ist, dass man sagt, wir machen halt diesen Teil des Systems total super und leicht wartbar und dann kommt halt irgendwie jemand und sagt, hier ist ein Requirement und dann stellt man halt fest, dieses Requirement ist irgendwo anders und das, was man gerade so schön poliert hat an Code, das wird halt nie wieder angefasst und das würde aber oder umgekehrt oder nicht, wir bauen halt hochoptimierten Code, schönen Code für Dinge, die halt mit Perspektive überhaupt nicht weiter genutzt werden und so weiter und dafür, um sowas zu vermeiden, müsste man jetzt irgendwie diese Kommunikation haben, die ist aber schwierig und was wir halt außerdem dadurch ausschließen, ist eben, dass wir jetzt das Budget vielleicht erweitern können, vielleicht ist es ja gerade sinnvoll, noch mehr Zeit in Qualität zu investieren und weniger Zeit darin, neue Features zu schruppen.
Das würde aber bedeuten, dass wir halt irgendwie fundamental was anders machen müssen, also das Budget halt ändern müssen und das könnten wir nur, wenn irgendwie jemand sagt, okay im Moment ist vielleicht irgendwie tatsächlich die Qualität wichtig. wo jemand gesagt hat, bis Ende des Jahres halte ich das hier noch durch, aber dann gehe ich halt.
Und hat sich dann in die Arbeit begeben mit irgendjemandem zusammen und hat dann im Rahmen dessen an dem Tag noch gesagt, okay, ich halte das hier nicht mehr aus, ich gehe jetzt.
Und zwar eben wegen dieser Schmerzen, die tatsächlich dort in der Wartung drin sind.
Und das ist halt, wie soll ich sagen, etwas, was zutiefst beeindruckend ist.
Und zwar nicht in einer positiven Art und Weise.
Und nicht Projekte können in diesen völligen Stillstand kommen, wo sie de facto nicht mehr dazu in der Lage sind, überhaupt noch irgendwas zu ändern.
Und das kann irgendwie dann eben zu einem ganz krassen Problem führen.
Gleichzeitig muss man halt sagen, und das ist etwas, was ich eben genau auf dieser Keynote von den XP Days gesagt habe, die technische Exzellenz im Umkehrschluss führt nicht unbedingt zu einem Geschäftsvorteil.
Also man kann halt auch mit anderen Mechanismen neben sich ein Geschäftsvorteil erreichen.
Man kann Menschen ausbeuten, man kann das System betrügen.
Es gibt auch Consultancies, die halt neue Menschen frisch von der Uni jedes Jahr anstellen und nicht in die Dauerhafte investieren, sondern man erwartet, dass sie nach zwei oder drei Jahren, wenn sie keinen Bock mehr haben, weil sie unter hohem Druck Software entwickeln müssen, dann irgendwo anders hingehen.
Das funktioniert also auch in unserer Branche mit dieser Ausbeutung.
Wir sind da sicherlich privilegiert.
Das ist eine andere Ebene von Ausbeutung, als wenn irgendjemand im Akkord irgendwo am Fließband arbeitet.
Aber es gibt eben auch bei uns Ausbeutung.
Es gibt bei uns auch Unternehmen, die das System betrügen.
Die Fossilindustrie wird halt gepäppelt von der öffentlichen Hand und muss sich eben dem Wettbewerb nicht stellen.
Das bedeutet, die sind entkoppelt davon, dass sie jetzt technisch exzellente Software bauen müssen oder überhaupt irgendwas dort exzellent bauen müssen, sondern die haben eben andere Mechanismen gefunden, um im Wettbewerb zu bestehen.
Anders gesagt, nur Softwaremenschen glauben, dass sich alles um Software dreht und kümmert, was also bedeutet, dass Wettbewerb vielfältiger stattfindet und Softwarequalität eben nur ein Faktor ist, der dazu führt, dass Unternehmen kompetitiv sind.
Jetzt kommt noch ein weiterer Punkt, der, glaube ich, total wichtig ist.
Ein Punkt, den ich machen wollte, ist, ich glaube, diese Kommunikation hat ein Problem.
Das ist etwas, was wir wirklich verbessern können und wo ich auch einige Dinge wirklich schwierig finde.
Mir ist zum Beispiel überhaupt nicht klar, warum Menschen einfach ohne Feedback zu geben ertragen, dass die Systeme, die sie bauen, ganz schrecklich sind und sie jeden Tag Schmerzen erleiden.
Da würde ich mir wünschen und auch glauben, dass man da mal Feedback geben kann.
Das ist einer der Punkte.
Das ist dann eben nicht ein Managementproblem, sondern Management entscheidet nach bestem Wissen und Gewissen und bekommt eben nicht die richtigen Informationen oder nicht ausreichende Informationen so kommuniziert, wie es eigentlich notwendig wäre.
Der andere Punkt ist, und das finde ich eigentlich auch noch mal wichtig darauf hinzuweisen, es ist nicht so, dass nur wir als Techniker darunter leiden, dass die Qualität der Systeme suboptimal ist, sondern auch Management und Business leidet darunter.
Eigentlich macht dieser wahrgenommene Gegensatz gar keinen Sinn.
Daher finde ich eben auch Kommunikation wichtig.
Hintergrund ist einfach der, wenn ich mir angucke, was ich so tue, Sanierung alter Systeme, Architekturrenovierung, solche Geschichten, das ist ein Schwerpunkt meiner Arbeit.
Das ist etwas, also nicht Migration weg vom Monolithen.
Ich möchte das System wahrtbarer bekommen.
Das sind Projekte, die aus dem Management kommen.
Einmal deswegen, weil sie wahnsinnig teuer sind.
Ich sage, ich will das System perspektivisch wegwerfen und neu machen.
Das ist wahnsinnig teuer.
Das ist nichts, wo ein Techniker sich hinstellen kann und sagen kann, ich bin frustriert, ich würde es besser bauen.
Sondern es ist etwas, wo sich Euros daraus versprochen werden, was bedeutet, dass das alte System abgeschrieben bzw. tot ist und ich muss es komplett neu aufbauen, was bedeutet, ich habe eine massive Investition.
Ich glaube nicht, dass Menschen, die betriebswirtschaftlich denken, glücklich sind, wenn sie sagen, wir haben eine Software, die funktioniert im Prinzip auch, wir müssen sie leider wegwerfen, weil wir können sie leider nicht mehr weiter betreiben und nicht mehr weiter warten.
Das heißt, da ist auch ein Problem.
Das ist auch etwas, was manchmal so passiert, dass so ein Management wechselt, wo dann gesagt wird, wir haben hier die alte Softwarelandschaft und jetzt haben wir jemanden, der neu rangehen will, der vielleicht in irgendeiner Weise Zukunft, Progress, Fortschritt haben möchte.
Die Person kümmert sich darum, dieses System wegzuwerfen und neu zu machen.
Das bedeutet, dass auch aus dieser Perspektive Wartbarkeit wichtig ist.
Denn das sind teure Projekte, die oft ihre Ziele auch nicht erreichen und damit leiden sie unter der eigenen Entscheidung.
Dahinter steckt auch die Art und Weise, wie man Management betreibt oder wie man arbeiten will.
Wenn ich sage, ich bin Firmeninhaber, dann möchte ich ein nachhaltiges Geschäftsmodell haben, was sich nachhaltig lohnt.
Wenn ich so etwas habe, dass ich an Quartalszahlen gemessen werde, ist vielleicht meine Inzentivierung für eine nachhaltige Entwicklung deutlich geringer.
Es gibt börsennotierte Unternehmen, die Quartalszahlen publizieren und eine langfristige Strategie verfolgen.
Das muss man sich aber leisten können.
Wenn man Quartalszahlen abliefern muss, liegt der Drang nahe, kurzfristige Vorteile zu generieren.
Dann kann man nicht in diese Nachhaltigkeit investieren.
Wir reden eigentlich darüber, ob man Software nachhaltig, dauerhaft oder kurzfristig implementieren will.
Das ist eigentlich eine Businessfrage.
Das zeigt sich auch an anderen Stellen.
Mir würde ein großer Betreiber von Bahninfrastruktur in Europa einfallen, wo man sagen muss, die sind jetzt dabei und schauen, dass sie ihr komplettes Schienennetz neu machen müssen.
Das ist dann etwas, wo nicht Software, sondern etwas anderes schlicht komplett saniert werden muss.
Da sind aber auch überraschende Schwierigkeiten.
Warum mache ich dieses massive Investment?
Weil ich unter Druck stehe, weil ich neue Produkte launchen will.
Welche Produkte willst du launchen?
Da kommt manchmal keine Antwort.
Oder es ist einem nicht klar, wie dieses Ziel ist.
Ich will neue Produkte launchen.
Vielleicht kann man konkrete nennen, wie das zusammenpasst mit der Grundsanierung der Software.
Da ist auch eine Optimierung, die darauf hinausläuft, dass man sich überlegen muss, wenn wir ein neues Finanzprodukt launchen wollen, eine Cyberversicherung, dann sollten wir im Rahmen der Softwaresanierung die Frage beantworten, wie man diese Cyberversicherung launchen kann.
Da hilft es mir wahrscheinlich nichts, wenn ich mein Lebensversicherungszeug modernisiere.
Da könnte man jetzt sagen, du erzählst gerade offensichtliche Dinge.
Ja, aber ich befürchte, dass in vielen Situationen genau diese Frage, also was ist denn das, was am Markt eigentlich passieren soll, wie passt das zur Renovierung, oft nicht zusammenpasst.
Ich glaube, das hat auch wieder diese Geschichte mit, wir wollen ja ein technisch gutes System entwickeln.
Das soll irgendwie abstrakt gut sein, aber es ist daneben nicht abgestimmt auf das, was tatsächlich im Markt passiert.
Der Christian Trutz schreibt, ich erlebe diesen Schmerz auf Entwickler- und Managementseite.
Oft ist aber das Problem, dass Technikerinnen und Management aneinander vorbeireden.
Danke, das ist das, was ich eigentlich versuche zu sagen.
Und insbesondere ist halt mein Feedback, da müssen wir daran arbeiten, unsere Kommunikation zu verbessern, weil wir können nicht erwarten, dass die Kommunikation des Managements besser wird.
Eigentlich sollte es diesen Graben nicht geben, aber wenn es den gibt, können wir an unserer Seite arbeiten, aber weniger an der anderen Seite.
Und das bedeutet eben, dass meine Empfehlung wäre, sich in diese Welt zu versuchen hineinzuversetzen oder sich tatsächlich mal jemanden zu nehmen und zu schauen, was diese Person denn so als Themen sieht und wie die überhaupt typischerweise redet und agiert.
Wir haben da auch eine Episode gemacht zum Thema Firmenpolitik mit dem Michael Ahrens zusammen, das ist ein definierter Nicht-Techniker und da kann man auch nochmal was darüber sehen, wie man dort kommunizieren kann.
Ein Gedanke, den ich noch reinwerfen wollte, ich habe halt oft dieses Totschlag-Beispiel.
Nehmen wir mal an, ich bin ein Start-up, ich habe also jetzt eine Million Euro.
Ich kann mit der Million Euro sagen wir mal ein Jahr überleben und jetzt fange ich an und baue eine Software für meinen Business Case.
Und jetzt bin ich nach einem Jahr fertig.
Ein Szenario, ich habe eine dreckige, schreckliche Software, die aber das Business Problem löst und ich habe dadurch Kunden.
Das ist super, weil dann kann ich mehr Geld besorgen oder ich habe vielleicht sogar Umsatz und Gewinn und kann aus diesem Geld meine weitere Entwicklung finanzieren, die dann möglicherweise bedeutet, dass ich diese Software wegwerfen muss und neu implementieren muss.
Das ist btw. das, wenn man sich das in mir anschaut, was viele von den großen Unternehmen tatsächlich gemacht haben.
Die erste Iteration der Amazon Software z.B. ist genau so eine.
Die Alternative wäre, oder das andere Szenario wäre, dass ich eine Software habe, die ist wartbar, saubere Code-Qualität, langfristig weiterentwickelbar, aber leider habe ich keine Leute, die die Software benutzen und ich habe dadurch nicht die Möglichkeit, Geld aufzutreiben.
Dann bin ich eigentlich tot.
D.h. die Software-Qualität im Sinne von Wartbarkeit nützt mir nichts.
Ich brauche eine andere Software-Qualität.
Ich brauche Software-Qualität im Sinne von Benutzerfreundlichkeit und diese Dinge, die damit zusammenhängen.
Da ist tatsächlich eine nachhaltige Entwicklung viel am Platze.
Das ist so ein bisschen ein auf die Spitze getriebenes Beispiel.
Das ist aber etwas, was tatsächlich ein typisches Pattern ist.
Viele von den erfolgreichen Start-ups, die ich so kenne, haben genau dieses Thema, dass sie sagen, wir haben einen schrecklichen alten Monolithen, von dem müssen wir irgendwie weg.
Der ist schrecklich und unwartbar.
Das ist wahrscheinlich genau das Überblöpsel hiervon.
Das sind die Unternehmen, die es überlebt haben und die jetzt sagen, dieser schreckliche Monolith muss weg.
Die anderen Unternehmen, die es nicht überlebt haben, haben wahrscheinlich schreckliche Monolithen, die heute niemanden mehr interessieren, weil sie einfach tote Software sind, weil es diese Unternehmen nicht mehr gibt.
Ich bin nicht sicher, was das für etablierte Unternehmen bedeutet.
Wenn ich eine Versicherung bin, habe ich da dasselbe, dass ich jetzt sage, ich will etwas aufbauen und das muss ich erst einmal tun, weiß ich nicht.
Da kommt wieder diese Frage nach dem Zeitdruck.
Ist der Zeitdruck real oder ist der irreal?
Kann man dann überhaupt nachhaltig arbeiten?
Wenn jetzt die Aussage ist, auch bei etablierten Unternehmen gibt es genau dieses Thema.
Ich habe an einem System gearbeitet, was die Grundannahme hatte, dass Bestellungen über Nacht ein Lager zugeteilt werden können.
Das ist heute offensichtlich nicht mehr so.
Wenn ich heute irgendwo online etwas bestelle, dann will ich vielleicht, dass es morgen da ist.
Das heißt, wenn morgen erst das Lager anfängt, das zu kommissionieren, ist das doof.
Das sollten sie jetzt schon kurzfristig machen, idealerweise sofort.
Dann ist die Frage, wann baue ich das System so um?
Das heißt, ich baue es um von Batchverarbeitung hin zu irgendwas anderem.
Mehr Batches, die laufen, nicht nur eine pro Nacht, sondern die laufen im Stundentakt.
Vielleicht auch so etwas, dass ich eventbasiert arbeite, dass ich sage, da kommt jetzt eine Bestellung rein und dann läuft perspektivisch jemand im Lager los und holt sich das.
Keine Ahnung.
Da ist die Frage, kann ich das vorher antizipieren?
Kann ich vorher antizipieren, dass diese Entscheidung zugunsten eines Batches eine Entscheidung ist, die ich perspektivisch irgendwann revidieren will?
Ich würde behaupten, wahrscheinlich nicht.
Das ist auch etwas, was nicht so unwahrscheinlich ist oder ein Ausreißer ist.
Mit Überweisung haben wir dasselbe Thema.
Die sind früher über Nacht gekommen und sind am nächsten Tag gewesen.
Jetzt kommen sie mittlerweile untertäglich.
Das heißt, die Überweisungssysteme müssen sich auch entsprechend modifizieren.
Dieses gesamte Thema, auch Monolithen und Module, sind auch im Management mittlerweile ein Thema.
Auch da ist diese Wartbarkeit mittlerweile ein Thema.
Vielleicht noch ein Hinweis.
Ich verspreche mir einiges von dieser Idee, die wir diskutiert haben bei der Tidy First Episode mit dem Ken Beck.
Er hat ein gutes Modell gefunden, um dieses Problem zu illustrieren.
Er sagt, es gibt zwei Möglichkeiten.
Ich kann jetzt Geld investieren für Dinge, die unmittelbar Geld bringen.
Oder ich kann Optionen kaufen.
Ich kann jetzt eine Option kaufen, die sagt, nächstes Jahr kriegst du Öl, Stahl oder etwas geliefert.
Das ist wertvoll, weil ich damit in eine Planung eintreten kann.
Ich kann für nächstes Jahr sagen, ich will Rennräder aus Stahlrohren bauen.
Ich kaufe mir eine Option, dass mir jemand Stahlrohre liefert.
Dadurch kann ich anfangen und sagen, wenn ich nächstes Jahr im Sommergeschäft meine Rennräder kaufen will, die werden so und so viel kosten.
Das habe ich abgesichert, weil ich jemanden habe, der mit einem bestimmten Preis Stahlrohre liefern kann.
Dann habe ich dort diese Option, die zu kaufen.
Das Schöne ist, wenn der Marktpreis zu dem Zeitpunkt niedriger ist, dann kriege ich sie sogar noch billiger.
Aber ich kann mein Risiko managen.
Das habe ich in der Softwareentwicklung genauso.
Ich kann der Entwicklerin sagen, setze ich hin und baue ein Feature, dann verdiene ich sofort Geld.
Oder ich investiere darin, dass ich in einem Jahr noch mehr Geld verdienen kann, weil ich dann ein Systemteil habe, das gut änderbar ist.
Ich glaube, das ist als Erklärmodell hilfreich.
Ich finde das besser als das Erklärmodell für Technikadapt.
Aber ich bin nicht sicher, ob es hilft, weil dieses Thema mit der Nachhaltigkeit fällt uns generell schwer.
Ein nachhaltiges Geschäftsmodell, wo ich nicht kurzfristig gierig bin, das ist ein generelles Problem.
Vielleicht muss ich das auch nicht sein.
Vielleicht muss ich auch nicht nachhaltig sein.
Vielleicht ist in der Wirtschaft so etwas kurzfristiges oft eine gute Idee.
Zeitdruck ist einer der wichtigen Auslöser für das, was wir hier beobachten.
Ich sollte diese Abwägung Zeitdruck gegen die Option das System zu verbessern treffen.
Ich glaube, dieses Modell von Ken Beck ist gut.
Ob es in der Praxis funktioniert, weiß ich nicht.
Was dazu führt, dass die Möglichkeit, Systeme dauerhaft qualitativ hochwertig zu halten, in der Praxis diese Budgets sind.
Da schränke ich das Qualitätsstreben der EntwicklerInnen ein.
Hier ist die Zeit, die ihr dafür habt, eure Qualität zu verbessern.
Das bedeutet, das maximale Qualitätsziel, das wir EntwicklerInnen an vielen Stellen haben, ist schwierig.
Reiner Zeitdruck aus Management ist schwierig.
Ich würde mir eigentlich eine Kommunikation darüber wünschen.
Das ist ein echt schwieriges Thema.
Das ist sehr schwer, das zu erreichen.
Da ist wieder dieses Thema mit der Kommunikation.
In den letzten Episoden haben wir viel über Kommunikation gemacht.
Wie man das konkret hinbekommt.
Das ist dann eigentlich das Werkzeug, was dort entscheidend ist.
Was wiederum bedeutet, auch im Vergleich zu dem, was am Anfang kam, das Problem ist, dass wir nicht wissen, ob wir bauen.
Ich glaube, das Problem ist, wir kommen nicht dazu.
Das kann man auch in Abrede stellen.
Man kann sagen, wir haben bestimmte Maßnahmen, bestimmte Architektur-Patterns.
Vielleicht sind die nicht allgemein bekannt.
Grundlagen von Modularisierung sind nicht allgemein bekannt, aber sollten es sein.
Ich glaube trotzdem, dass dieses andere Thema Kommunikation der entscheidende Punkt ist.
Ich schaue nochmal, ob ich irgendwelche Themen übersehen habe.
Irgendwelche Fragen, die noch da sind.
Das scheint nicht der Fall zu sein.
Dann haben wir eigentlich, ich weise nochmal kurz hin auf den Spatial Shop, den man hier sieht.
Wo man ganz viele tolle Dinge einkaufen kann.
Wir verdienen daran nichts.
Sprich wir kostendecken.
Beziehungsweise, wenn wir da tatsächlich was verdienen, können wir das einem guten Zweck zur Verfügung stellen.
Die nächste Episode ist dann am 7.
Das ist also tatsächlich Freitag in der Woche mit Diana Montaljon zusammen mit Lisa, die dann über System Thinking redet.
Die hatten wir auch schon mal im Stream.
War sehr spannend.
Vielleicht schaltet ihr euch da wieder ein.
Das wird dann in Englisch sein.
Vielen Dank.
Heute am Mittwoch aufgrund der Feiertage, Morgen und Übermorgen.
Nächste Woche sehen wir uns dann irgendwie nicht, weil Lisa da das übernimmt.
Aber vielleicht an einer anderen Stelle.
Vielen Dank.
Ne, stimmt gar nicht.
Das ist nämlich komplizierter.
Am 8. am Freitag ist Cosima Laube zum Thema Coaching mit Lisa da.
Der Termin am Donnerstag am 7. den macht Lisa auch mit Diana zusammen.
Schönes Wochenende.
Schöne Feiertage und bis dahin.
Danke für die Fragen.
Für den vielen Input.