Technische Schulden: Zwischen notwendigem Übel und unsichtbarem Risiko

Wolfgang: Hallo und herzlich willkommen bei Digital Future, dem Podcast zu Technologie

Wolfgang: und Unternehmenskultur.

Wolfgang: Mein Name ist Wolfgang Schoch und ich bin Agile Coach bei inovex.

Wolfgang: Ich habe aber auch schon ein paar andere Sachen gemacht und so die IT-Branche

Wolfgang: aus verschiedenen Blickwinkeln kennengelernt.

Wolfgang: Zum Beispiel als Softwareentwickler, als Experte für Suchtechnologie oder im Vertrieb.

Wolfgang: Ich freue mich, euch in jeder Folge des Podcasts eine Kollegin oder einen Kollegen

Wolfgang: vorzustellen und mich mit ihr oder ihm über das jeweilige Fachgebiet zu unterhalten.

Wolfgang: So bekommt ihr einen Einblick in unseren technologischen und unternehmenskulturellen Alltag.

Wolfgang: In der heutigen Folge spreche ich mit meinen Kollegen Christian Rohmann,

Wolfgang: Simon Bachstein und Christoph Erhard über das Thema technische Schulden.

Wolfgang: Wir klären den Begriff und gehen dann auf die Bedeutung in den unterschiedlichen

Wolfgang: Bereichen Softwareentwicklung, Betrieb und Data Engineering ein.

Wolfgang: Und dann unterhalten wir uns darüber, wie technische Schulden überhaupt erst

Wolfgang: entstehen und wie man damit umgehen kann.

Wolfgang: Und jetzt wünsche ich euch viel Spaß beim Zuhören. Ja, hallo und herzlich willkommen.

Wolfgang: Ich freue mich ja, dass es heute mal so eine große Runde ist.

Wolfgang: Denn in der Regel habe ich ja immer einen Gast oder vielleicht auch mal zwei Leute hier zu Gast.

Wolfgang: Aber heute nicht eine Person, nicht zwei Personen, gleich drei absolute Experten.

Wolfgang: Und ich freue mich auf unser Gespräch, ist ein spannendes Thema,

Wolfgang: wo ich selbst auch die ein oder andere Erfahrung gesammelt habe in den letzten

Wolfgang: 20 Jahren, kleiner Spoiler,

Wolfgang: aber bevor wir ins Thema einsteigen, würde ich mich freuen, wenn ihr drei euch

Wolfgang: mal alle kurz vorstellt.

Wolfgang: Wer seid ihr, was macht ihr so bei InnoVax und wie lange seid ihr schon an Bord

Wolfgang: und Christian, vielleicht können wir ja mit dir anfangen.

Christian: Ja, gerne. Hallo zusammen. Ja, mein Name ist Christian Rohmann.

Christian: Ich bin im Bereich ITO, also IT Engineering and Operations bei inovex.

Christian: Ich bin jetzt ungefähr neun Jahre hier an Bord.

Christian: Aber ich glaube, du hast eben Experten ausgesprochen. Ich glaube,

Christian: etwas, was zumindest ich mit an den Tisch bringe, ist ein bisschen nicht nur

Christian: Lebens, sondern vor allem auch Berufserfahrung.

Christian: Also schon einiges gesehen.

Christian: Ich bin ja in dem IT-Infrastructure-Bereich zu Hause, das heißt also,

Christian: wenn man das schon ein bisschen länger macht, natürlich Hardware.

Christian: Ich habe vor Inwex verschiedene Sachen gemacht, darunter auch für Internet-Service-Provider

Christian: gearbeitet, da hat man natürlich mit diskreter Hardware und Infrastruktur in

Christian: dem Sinne zu tun, aber natürlich in den letzten Jahren für mich ganz klar,

Christian: technologische Heimat ist Cloud-Infrastruktur, Cloud-Native-Infrastruktur, ganz klar mit dem,

Christian: großen Push und der Adaption von zum Beispiel auch Kubernetes und anderen Services,

Christian: die bei den diversen Hyperscalen unterwegs sind.

Christian: Das heißt, das ist so ein bisschen mein Bereich und ich vermute,

Christian: die Kollegen ergänzen das dann eher im Bereich Software.

Wolfgang: Da bin ich sehr gespannt. Vielen Dank. Christoph, wie sieht es denn mit dir aus?

Christoph: Ja, hi. Ich heiße Christoph. Ich bin seit anderthalb Jahren jetzt an Bord am Standort Erlangen.

Christoph: Ich bezeichne mich selbst gern als Pinguin-Knudler, weil ich leidenschaftlich

Christoph: gern mit offenen Technologien und offenem Code arbeite.

Christoph: Ich bin mit Linux und dem ganzen Ökosystem.

Christoph: Ich bin tätig im Bereich Anwendungsentwicklung und konkret in der Medizintechnikbranche

Christoph: und unterstütze dort Kunden dabei, die Software-Plattform für Medizingeräte zu entwickeln.

Christoph: Und ich habe einige Erfahrungen gemacht in einem Projekt, das ich jetzt schon seit langem begleite,

Christoph: mit einer Code-Basis, die mittlerweile alt genug ist, um den Führerschein zu

Christoph: haben, geschrieben in einer Programmiersprache, die den Begriff technische Schulden

Christoph: auch gerne mal aufwirft.

Christoph: Und insofern kenne ich mich da aus meiner täglichen Praxis ganz gut damit aus,

Christoph: wie man mit solchen gewachsenen Codebasen umgeht.

Wolfgang: Sehr spannend, vielen Dank. Und last but not least, wir hatten jetzt ITO,

Wolfgang: also IT Operations, dann hatten wir Anwendungsentwicklung.

Wolfgang: Simon, wie sieht es denn bei dir aus?

Simon: Ja, hi zusammen. Mein Name ist Simon Bachstein. Ich bin jetzt seit sechs Jahren

Simon: bei inovex als Data Engineer und baue seitdem für unsere Kunden Datenplattformen, Datenstrecken,

Simon: Datenanalyse und das vom POC bis zum Produktiv-Deployment.

Simon: Und ich komme ursprünglich aus der Mathematik, bringe also da so ein bisschen

Simon: das Faible für Exaktheit und Abstraktion mit.

Simon: Und da ist man dann in der Softwareentwicklung doch auch immer wieder mit Unexaktheiten konfrontiert.

Simon: Und da kommen wir auch wieder zum Thema Technical Debt, wo man auch nicht alles

Simon: vorhersehen kann und nicht alles bis zum Ende durchdenken kann manchmal.

Wolfgang: Jetzt wurde ja von euch beiden hier, Christoph und Simon, schon so ein kleines

Wolfgang: bisschen gespoilert, was denn das Thema sein könnte.

Wolfgang: Wobei man hat es wahrscheinlich auch schon gelesen bei der Beschreibung der Folge.

Wolfgang: Aber bevor wir in das Thema technische Schulden einsteigen, können wir vielleicht

Wolfgang: nochmal ganz kurz ein kleines Resümee darüber halten, wie wir zu diesem Thema

Wolfgang: eigentlich gekommen sind.

Wolfgang: Und das Ganze, das ging auf eine Initiative zurück vom Kollegen Sebastian Schmidt,

Wolfgang: der vor, ich glaube, zwei oder drei Jahren auch schon mal hier im Podcast zu Gast war.

Wolfgang: Ich habe mich mit ihm damals über das Thema digitale Qualität unterhalten,

Wolfgang: denn bei uns hier im Unternehmen, wir haben ja diese ganzen InnoCircles,

Wolfgang: also wie kann man das beschreiben, so genannt.

Wolfgang: Also Interessengruppen oder so Gruppen von Personen, die sich mit einzelnen

Wolfgang: Themen beschäftigen, um da Themen weiterzuentwickeln.

Wolfgang: Und ihr alle seid ja genau wie Sebastian auch im Inner Circle Digital Quality

Wolfgang: und das Thema technische Schulden ist da ein Thema, das dort angesiedelt ist.

Wolfgang: Und zu diesem Thema soll ja künftig auch noch einiges passieren in verschiedenen

Wolfgang: Formaten und wir machen heute ja so ein kleines bisschen den ersten Aufschlag,

Wolfgang: kann man glaube ich so sagen, oder?

Wolfgang: Dann lasst uns doch mal direkt in das Thema einsteigen.

Wolfgang: Technische Schulden. Ich glaube, alle Personen, die sich mit Softwareentwicklung

Wolfgang: oder vielleicht generell mit Technologie beschäftigen, könnten den Begriff schon mal gehört haben.

Wolfgang: Ich kann mir aber auch ganz gut vorstellen, dass da draußen viele unterschiedliche

Wolfgang: Definitionen von diesem Begriff existieren.

Wolfgang: Und deswegen fände ich es ganz charmant, wenn wir den mal vielleicht gemeinsam

Wolfgang: definieren können, denn ich habe jetzt ja vor mir drei Leute aus den drei großen

Wolfgang: Abteilungen, die es hier bei uns bei inovex gibt, also ITO.

Wolfgang: DMA und AD, also Softwareentwicklung, dann diese ganze Data Analytics,

Wolfgang: KI-Bubble und natürlich auch den Betrieb von Software.

Wolfgang: Und ich könnte mir auch vorstellen, dass es da vielleicht ganz unterschiedliche

Wolfgang: Nuancen von technischen Schulden gibt.

Wolfgang: Und vielleicht können wir ja einfach mal so in diese einzelnen Bereiche kurz reinschauen.

Wolfgang: Christian, was sind für dich denn technische Schulden im Bereich ITO?

Christian: Ja, ich sagte ja schon, ich komme ja aus dem Bereich der Infrastruktur,

Christian: wie du schon sagst. Software wird betrieben.

Christian: Um die zu betreiben, um die Infrastruktur zu erzeugen, nutzt man natürlich,

Christian: da kommen wir vielleicht ein bisschen noch in die Parallelen der Softwarewelt,

Christian: nutzt man ja immer mehr Werkzeuge, die softwaregetrieben sind,

Christian: ob das jetzt imperative Dinge sind,

Christian: Skripte, um irgendwelche Dinge zu deployen, auszurollen und zu konfigurieren

Christian: oder deklarative Werkzeuge, was man hat.

Christian: Also ich habe es eben ja schon gesagt, sowas wie Kubernetes-Manifeste,

Christian: wo ich Infrastruktur beschreibe, wie Software ein größeres Ganzes bilden soll,

Christian: aber auch die ganzen Konfigurations-Artefakte, die da reinkommen.

Christian: Also wie ich die Komponenten dann eben das machen lasse, was benötigt wird.

Christian: Und darüber hinaus, wenn ich viel davon habe, dann habe ich gewisse Konventionen,

Christian: also wie ich Dinge benenne oder wie Dinge sich referenzieren und so weiter,

Christian: um aus einem größeren Sammelsurium von Komponenten irgendwas Ganzes zu machen.

Christian: Und das ist was, wo man, auch wenn das nicht so eine reine Software-Welt ist im Bereich ITO,

Christian: kommt man aber doch an diesen Themen immer wieder vorbei, dass man eben mit

Christian: Werkzeuge entsprechend die Aufgabe machen lässt und dann dort so eine gewisse Struktur hat.

Christian: Oder auch die Werkzeuge selbst sind vielleicht nicht mehr so die richtigen,

Christian: wo man das Gefühl hat, dass das die sind, die heute das optimal umsetzen, was gefragt ist.

Christian: Also das ist für mich so ein bisschen, in diesen Bereichen, wo man stark immer

Christian: wieder mal das Gefühl hat, es ist nicht mehr so optimal oder jetzt kommen Anforderungen,

Christian: da würde man es gerne anders machen, mit einem anderen Tool oder halt auch anders einsetzen.

Wolfgang: Also auch so ein bisschen im Sinne von, als wir das gemacht haben,

Wolfgang: vielleicht vor fünf oder vor zehn Jahren, war das schon das richtige Tool,

Wolfgang: war das die richtige Technologie, weil es nichts anderes gab.

Wolfgang: Und heute, einige Jahre später, hat sich die Welt natürlich weitergedreht.

Wolfgang: Die Innovation ist im ganzen IT-Bereich natürlich rasant. Und heute gibt es eben Tools,

Wolfgang: die besser geeignet wären, weil, keine Ahnung, man Arbeitszeit sparen könnte,

Wolfgang: weil man Dinge vielleicht besser automatisieren könnte, weil man besser mit

Wolfgang: Ressourcen umgehen könnte, etc.

Christian: Ja, so würde ich es zusammenfassen, ja. Zumindest aus meiner Rate.

Wolfgang: Okay, spannend. Christoph, bei dir bin ich gespannt, weil ich habe ja auch so

Wolfgang: eine Vergangenheit im Bereich der Softwareentwicklung und du hast ja gerade

Wolfgang: von deinem Projekt schon erzählt.

Wolfgang: Da musste ich an meine Jahre, vielen, vielen Jahre denken, in denen ich Java entwickelt habe.

Wolfgang: Vielleicht hast du ja da auch in dem Bereich Erfahrung gesammelt.

Wolfgang: Was ist für dich eine technische Schuld?

Christoph: Für mich sind technische Schulden zunächst mal eine Metapher,

Christoph: angelehnt an den Begriff aus der Finanzwelt,

Christoph: den wir alle kennen, Schulden, im Sinne eines Unternehmens, das kurzfristig

Christoph: investieren will und dann eben Schulden aufnimmt,

Christoph: um sich etwas leisten zu können jetzt, wofür man sonst länger sparen müsste.

Christoph: Um also kurzfristig schneller mehr Umsatz und Gewinn machen zu können.

Christoph: Und diese Schulden stottert man dann eben über die Zeit wieder ab und kommt

Christoph: hoffentlich, wenn man das Ganze gut und planvoll gemacht hat,

Christoph: am Ende mit einem Plus raus.

Christoph: Und übertragen auf das Technische heißt es für mich in der Regel,

Christoph: ich arbeite an einem Entwicklungsprojekt, es gibt einen Release-Plan,

Christoph: folgende Features wollen wir bis zu folgendem Zeitpunkt umgesetzt und ausgerollt

Christoph: haben und jetzt wird die Zeit knapp.

Christoph: Und jetzt nehme ich Schulden auf, indem ich eine bewusste Entscheidung als Entwicklungsteam treffe.

Christoph: Wir machen jetzt mal ein paar Abkürzungen in der Software-Architektur,

Christoph: bei den Compiler-Warnungen und allgemein in der internen Qualität unserer Code-Basis.

Christoph: Ist, wir nehmen ein paar Abkürzungen, wir nehmen ein paar Kompromisse in Kauf,

Christoph: um diese Features rechtzeitig zum Release zu bringen.

Christoph: Und im Nachhinein müssen wir dann eben ein bisschen mehr Aufwand treiben,

Christoph: um das Ganze wieder geradezuziehen und aufzuräumen. Das ist dann das Abstottern der Schulden.

Christoph: Und am Ende geht dann hoffentlich diese Rechnung wieder auf.

Christoph: Und der Nutzen, den wir dadurch haben, übersteigt am Ende die Investitionen.

Wolfgang: Finde ich jetzt schon mal sehr, sehr spannend, nachdem ich jetzt von euch beiden

Wolfgang: zu eurer Sicht gehört habe.

Wolfgang: Denn was du jetzt gerade gesagt hast, Christoph, unterscheidet sich ja schon

Wolfgang: ein wenig von dem, was der Christian uns gerade erzählt hat.

Wolfgang: Weil bei Christian, aber korrigiert mich bitte, wenn ich es falsch irgendwie verstanden habe.

Wolfgang: Christian, bei dir habe ich es eher so verstanden wie, wir geben unser Bestes

Wolfgang: und die Zeit schreitet voran und dann merken wir, oh, jetzt geht es was Besseres.

Wolfgang: Okay, super nachvollziehbar.

Wolfgang: Gibt es wahrscheinlich keinen Weg, das effektiv zu vermeiden.

Wolfgang: Und bei dir, Christoph, ist es ja jetzt eher so diese bewusste Handlung,

Wolfgang: die ich persönlich aus meiner Vergangenheit als Entwickler auch kenne.

Wolfgang: Da war es dann immer die böse, böse Deadline, die manchmal auch sehr willkürlich

Wolfgang: erschien, zumindest in meiner Berufslaufbahn früher.

Wolfgang: Und um die einzuhalten, denn das Reisen der Deadline wäre einem Weltuntergang oftmals nahegekommen,

Wolfgang: musste man eben halt diese Schulden und ich möchte es nicht sagen Verbrechen

Wolfgang: der Codequalität eingehen, um hier möglichst irgendwie die Zeit irgendwo zu sparen.

Wolfgang: Finde ich schon mal sehr, sehr interessant, eure beiden Definitionen.

Wolfgang: Und ja, jetzt haben wir ja noch dich, Simon.

Wolfgang: Ich bin gespannt, was für dich technische Schulden im Bereich DMA sind.

Simon: Ja, ich würde mich meinem Vorredner da anschließen. Ich würde aber eine Ergänzung

Simon: machen und zwar glaube ich, dass technische Schulden nicht immer bewusst aufgenommen werden.

Simon: Ich denke, das ist oft auch einfach eine Konsequenz daraus, dass die Anforderungen

Simon: vielleicht noch in ihrer Gänze bekannt sind, dass sich Anforderungen für ein

Simon: Produkt im Laufe der Zeit auch entwickeln.

Simon: Und da ist es einfach ganz schwierig, architekturiell oder auch vom Way of Working

Simon: von Anfang an einen Modus oder eine Architektur zu finden,

Simon: die dann auch die Zukunft und alle zukünftigen Anforderungen abdeckt.

Simon: Das heißt, gerade im agilen Kontext geht man ja dann oft auch,

Simon: ich sage mal, den Weg des geringsten Widerstandes, weil man will ja diese schnellen

Simon: Iterationen haben, man will das Sprintziel erreichen kurzfristig,

Simon: man ist da angehalten, so ein bisschen Shortcuts zu machen und manchmal macht

Simon: man die nicht bewusst, sondern sagt sich, ja,

Simon: für meine aktuellen Anforderungen, für mein aktuelles Ziel tut's das und ja,

Simon: was dann kommt, das schauen wir mal.

Simon: Und so ist das tatsächlich auch in der Datenwelt oft.

Simon: Also mal ein ganz konkretes Beispiel.

Simon: Ich will, ich habe meine Daten, ich will daraus einen Report generieren für

Simon: Analysezwecke und jetzt habe ich da eine Abteilung, die sagt mir,

Simon: ja, ich werde gerne folgende Daten analysiert, hätte da folgenden Use Case und

Simon: zum Beispiel baue ich jetzt meine Datenmodellierung für diesen Use Case,

Simon: aber dann kommt vielleicht einen Monat später die nächste Abteilung und sagt,

Simon: oh, wir haben gehört, ihr baut da Reports, sowas hätten wir auch gerne und hätten

Simon: aber noch einen anderen Use Case und jetzt steht man da, hat schon ein Datenmodell,

Simon: hat das nach bestem Wissen und Gewissen gemacht und der neue Use-Case verlangt

Simon: aber jetzt eine Anpassung.

Simon: Und so entsteht dann auch ein Stück weit Technical Debt, in dem Anforderungen

Simon: sich entwickeln und dann Architekturen nochmal neu gedacht werden müssen.

Christoph: Ich stimme dir vollkommen hinzu, dass die Metapher mit den Schulden ein bisschen hinkt.

Christoph: Und das Schöne bei finanziellen Schulden, die man hat, ist ja,

Christoph: dass man, zumindest wenn man sie bei einer seriösen Bank aufnimmt und nicht bei der Mafia,

Christoph: sich in dem Zeitpunkt beziffern kann, wie viele Schulden man noch hat,

Christoph: wie der Tilgungsplan ist, wie hoch die Zinsen sind und wie lange man noch braucht,

Christoph: um das Ganze abzustottern.

Christoph: Bei technischen Schulden ist es natürlich schon allein mal viel schwerer,

Christoph: da irgendwie eine Metrik dran zu hängen, weil es ist nicht Geld, was dran hängt.

Christoph: Es ist irgendwie so ganz abstrakt Qualität meiner Code-Basis.

Christoph: Technische Schulden sorgen vielleicht dafür, dass ich zukünftig,

Christoph: wenn ich neue Features implementieren will, sehr viel langsamer bin,

Christoph: als ich eigentlich sein könnte, weil ich vergessen habe, Modularität einzubauen.

Christoph: Und so wirklich eine ganz klar benennbare Metrik, wie das bei finanziellen Schulden

Christoph: der Fall ist, gibt es bei technischen Schulden einfach nicht.

Christoph: Und das sorgt natürlich auch dafür, dass es sehr leicht ist,

Christoph: sich in diese Schuldenfalle reinzumanövrieren, weil man ja gar nicht genau weiß,

Christoph: wie schwerwiegend das am Ende dann sein wird, was man dann zurückzahlen muss.

Simon: Ja, ich stimme da absolut zu und vor allem, wenn man jetzt die finanzielle Metapher

Simon: mal nochmal reinbringt,

Simon: genau, diese Zinsen sind einfach nicht bekannt, die man da zahlen muss und die

Simon: ändern sich auch ständig und ich muss quasi zu jedem Zeitpunkt analysieren,

Simon: welche technischen Schulden sind jetzt für mich in diesem Moment teuer,

Simon: also welche sind für mich wichtig abzuzahlen,

Simon: damit ich meinem Ziel näher komme und das kann sich permanent ändern.

Christian: Also wenn ich das aus dem Infrastrukturbereich mache, dann hätte ich ja auch

Christian: widersprochen dieser reinen Analogie der Schulden.

Christian: Aber den Begriff finde ich gar nicht so schlecht, weil es ja doch um Aufwände,

Christian: um Kosten, wenn man so will, auch wenn es nur Zeit ist, die man hat,

Christian: die man aber erst feststellt, wenn sie da sind.

Christian: Also ich denke auch, das ist ein stetes Spannungsfeld, sich bewusst zu machen,

Christian: wie viel Technical Debt, ich würde es auch vielleicht eher sagen,

Christian: wie viel Wartung, Unterhaltungsaufwand für das eine oder andere noch da ist.

Christian: Das ist ja gerade in Betriebsthemen bei Infrastruktur immer so ein Spannungsfeld,

Christian: man hat was aufgebaut, das ist die aktuellste Software-Version,

Christian: das ist allen Anforderungen gerecht geworden,

Christian: aber irgendwie reicht es nicht, wenn man das System dann einfach sich selbst überlässt.

Christian: Ich benutze ja jetzt weniger selbst erstellte Software in dem Einsatz,

Christian: also wo ganz konkrete Anforderungen sind, aber auch die, die dann programmiert

Christian: werden, aber auch Integration von Softwarekomponenten.

Christian: Da gibt es ja viele externe Faktoren.

Christian: Klar, es gibt neue Softwareversionen. Ist das ein Problem?

Christian: Also muss ich die benutzen? Haben die irgendwas, was ich unbedingt brauche?

Christian: Ist das eine Schuld, die ich auf mich nehme, wenn ich nicht die neueste Version,

Christian: das neueste Werkzeug einsetze? Also unabhängig davon, ob ich ein Feature zum

Christian: Beispiel davon überhaupt benutze.

Christian: Aber es könnte ja ein Punkt kommen, wo ich extern gezwungen werde zum Beispiel,

Christian: weil irgendein Lebenszyklus von einem Produkt abgekündigt ist.

Christian: Oder wenn dann der Punkt gekommen ist, wo ich die ein oder andere Funktionalität

Christian: benutzen will, dann kommt plötzlich, also daher mag ich eure Analogie mit der

Christian: Mafia da, dass auf einmal diese Schuld mir ganz schnell bewusst wird.

Christian: Das heißt, ich bin voll bei euch, sich bewusst zu machen, an welchen Punkten

Christian: man wie viel potenzielle Risiken oder Schuld hat,

Christian: lässt einen dann zwar nicht direkt losrennen, all diese Dinge zu beseitigen,

Christian: ich glaube, das ist noch eine eigene Diskussion, aber man weiß,

Christian: oder etwas besser weiß man dann, was einen an der einen oder anderen Stelle

Christian: erwartet, wenn es dazu kommt, dass man da dran muss.

Christoph: Das ist ein sehr guter Punkt, den du gemacht hast. Ich sehe das auch so,

Christoph: dass Software eigentlich nie fertig entwickelt ist und dann kann man sie einfach

Christoph: so lassen, wie sie ist und nie wieder anfassen.

Christoph: Software ist ja immer Teil eines Ökosystems und dieses Ökosystem entwickelt

Christoph: sich weiter und mit diesem Ökosystem muss man mitgehen egal ob man das will oder nicht,

Christoph: weil wenn man das nicht macht kommt man irgendwann früher oder später an einen

Christoph: Punkt wo es nicht anders geht weil das Ökosystem,

Christoph: gewechselt hat sich so weit verändert hat dass wir jetzt wirklich was anfassen

Christoph: müssen und wenn man dann auf einmal auf einen Schlag riesige Anpassungsarbeiten machen muss,

Christoph: ist es natürlich sehr viel aufwendiger, als wenn man immer in kleinen Schritten

Christoph: mitgeht und am Puls der Zeit bleibt.

Christoph: Dann sind es halt immer viele kleinere Änderungen, die man durchführen muss,

Christoph: aber die dann eben schön verteilt über die Zeit, anstatt einmal den großen Aufwand

Christoph: zu haben, der dann richtig wehtut.

Wolfgang: Ja, das kenne ich. Also ich habe da ein sehr, sehr gutes Beispiel.

Wolfgang: Und zwar, ich habe mal vor vielen, vielen Jahren das Vergnügen gehabt,

Wolfgang: da durfte ich mit JBoss arbeiten.

Wolfgang: Gibt es heute gar nicht mehr. Heißt heute, glaube ich, Wildfly,

Wolfgang: was viel cooler ist als JBoss.

Wolfgang: Das ist ein Java-Application-Server.

Wolfgang: Und ich weiß noch, das war schon lange her.

Wolfgang: Also als wäre es gestern gewesen, habe ich es noch im Kopf auf jeden Fall.

Wolfgang: Und da musste ich ein Upgrade machen für einen Kunden und zwar hatten wir,

Wolfgang: also in der Firma, in der ich damals gearbeitet habe,

Wolfgang: wir hatten das schon in Enterprise Software entwickelt und die lief damals auf

Wolfgang: JBoss 3 und die sollte migriert werden auf JBoss 5.

Wolfgang: Und das ergab sich zu einer Zeit, wo sowas eine einzelne Person gemacht hat.

Wolfgang: Und ich dachte, das ist halt super easy,

Wolfgang: da musst du halt drei, vier Sachen vielleicht anpassen und dann läuft das und

Wolfgang: ich glaube, ich habe da zwei oder drei Monate dran gearbeitet,

Wolfgang: und da musste man halt alles anfassen, weil sich alles verändert hat und man

Wolfgang: hatte halt diese Software damals einfach,

Wolfgang: keine Ahnung, nicht irgendwie so richtig gut gepflegt beziehungsweise nicht

Wolfgang: auf neue Releases von J-Boss irgendwie mal portiert, sondern hat einfach viele Jahre gewartet.

Wolfgang: Und das war halt einfach unglaublich viel Arbeit, hat gar keinen Spaß gemacht

Wolfgang: und war unterm Strich wahrscheinlich auch schon teurer,

Wolfgang: als wenn man mit jedem Release einfach mitgegangen wäre und dann jedes Mal vielleicht

Wolfgang: nur ein bisschen was angepasst hätte, weil die ganzen Features,

Wolfgang: die halt so nachentwickelt wurden, die wurden halt alle damals noch auf Basis

Wolfgang: von J-Boss 3 entwickelt und nicht auf J-Boss 5.

Wolfgang: Also es wurde halt auch immer und immer mehr.

Wolfgang: Und das ist sehr ähnlich wie vielleicht bei diesen ganzen COBOL-Applikationen,

Wolfgang: die jetzt noch bei Banken, Krankenkassen, Versicherungen irgendwo im Keller

Wolfgang: schlummern, beziehungsweise nicht schlummern, sondern da immer noch ihr Tagwerk tun.

Simon: Ja, weil wir jetzt über Versionsupgrades sprechen und über sich wandelnde Ökosysteme in der Software.

Simon: Wir leben ja jetzt auch in einer Zeit, da sammelt sich ja kontinuierlich und

Simon: die ganze Zeit Technical Debt und Schulden an allein, weil es vergeht kein Tag,

Simon: an dem keine Sicherheitslücken irgendwo entdeckt werden.

Simon: Also jeden Tag gibt es eine Library, gibt es eine Software, gibt es ein Produkt,

Simon: wo Sicherheitslücken entdeckt werden, womöglich schon ausgenutzt werden.

Simon: Das heißt, allein deswegen, weil Software ist ja mittlerweile...

Simon: Hat ja eine riesige Menge an Abhängigkeiten von Bibliotheken etc.

Simon: Das heißt, allein dadurch sammelt sich so viel Debt an, die man oder Aufmerksamkeit,

Simon: die man aufbringen muss, um diese Sicherheitspatches die ganze Zeit auf dem Schirm zu haben.

Simon: Mittlerweile haben wir da Tools, die uns da das Leben leicht machen.

Simon: Aber dennoch müssen wir als Entwickler ständig auf der Hut sein und dem entgegenstehen.

Christian: Ich glaube, das Beispiel hätte ich auch gewählt, dass du sagst,

Christian: da sind jetzt die Werkzeuge so ein bisschen mitgewachsen. dass man da ein bisschen Schritt hält.

Christian: Das ist ja so, würde ich, oder würdest du sagen, das ist so Wartung,

Christian: Unterhaltung von der ganzen Sache.

Christian: Also mein Gedanke, wo es dann schwieriger wird, ist, wenn ich so externe Einflussfaktoren

Christian: habe, dass etwas nicht mehr gut genug ist.

Christian: Also das ist das ganze Werkzeug. Also im Fall vielleicht eine Bibliothek.

Christian: Ich muss die Bibliothek wechseln oder die komplette Implementierung des Application Servers.

Christian: Weil dann ist der Schritt ja gar nicht mehr so einfach, kleiner zu machen.

Christian: Dann habe ich irgendwann so einen richtigen Sprung. Dann kann ich sagen,

Christian: hey, ich mache den erstmal noch nicht mit, das ist noch gut genug für mich,

Christian: aber dann irgendwann wird es ein Problem.

Christian: Ich glaube, wir sind uns einig, dass man bei den, mit kleineren,

Christian: graduellen Veränderungen, also kleinere Updates zum Beispiel, auch gerade mit guten,

Christian: gut abgedeckten Tests und Integrationsautomatisierung, also mit CICD,

Christian: dass man da ganz gut Schritt halten kann, auch wenn es viele Komponenten sind,

Christian: die sich in kleinen Schritten eben vorwärts bewegen, aber wenn du so fundamentale

Christian: Themen hast, wie der Wolfgang eben aufgebracht hat.

Christian: Also für mich zum Beispiel in der Infrastruktur, da gibt es ja auch noch einen

Christian: weiteren Punkt, das sind auf der einen Seite die Werkzeuge, aber es sind auch Trends.

Christian: Und ich vermute mal, das ist im Softwarebereich nicht anders,

Christian: dass dann auf einmal das eine Framework ist nicht mehr en vogue und dann ist

Christian: es dann schon dead. Also kann man dann schon sagen, das passt nicht mehr.

Christian: Also ich weiß nicht, entschuldige mal die stumpfe Analogie, aber das ist so

Christian: ein bisschen, wenn ich ein älteres Auto fahre.

Christian: Ich kenne die Macken und so weiter, ich kümmere mich auch darum,

Christian: ich warte es. Ja, wann ist der Punkt, wann es zum Risiko wird?

Christian: Also wann es wirklich eine Liability ist, die auch geschäftskritisch ist,

Christian: wo man sagt, wenn da jetzt was drankommt, dann bleibe ich liegen irgendwo und so.

Christian: Und das ist für mich dann vielleicht eine ganz andere Qualität von Debt,

Christian: die ich habe, als einfach nur ein paar Verfärbdates zu machen.

Wolfgang: Ja, ich finde, da ist ein sehr, sehr guter Punkt drin oder mehrere gute Punkte

Wolfgang: drin in dem, was du da sagst, Christian.

Wolfgang: Denn wenn es jetzt darum geht, ob jetzt ein Framework noch cool ist,

Wolfgang: ich glaube, da muss man schon ein bisschen unterscheiden.

Wolfgang: Ist es jetzt wirklich so, weil in der Branche sprechen jetzt alle über das neue

Wolfgang: Framework und ich kenne das, vielleicht ist es auch nur ein Vorurteil,

Wolfgang: ich kenne das aber eher so aus diesem Frontend-Bereich, wo es irgendwie laufend

Wolfgang: neue, coole Frameworks gibt, mit denen man was anders oder vielleicht auch besser

Wolfgang: oder effizienter machen kann.

Wolfgang: Also ist es nur so, weil jetzt alle das neue Framework nutzen und du möchtest

Wolfgang: dabei sein, möchtest nicht abgehängt werden oder möchtest vielleicht auch erfahren,

Wolfgang: wie es ist, mit etwas Neuem zu arbeiten und da vielleicht auch ein bisschen

Wolfgang: selbstgefordert zu sein.

Wolfgang: Ich glaube, das ist vielleicht die persönliche Präferenz.

Wolfgang: Das andere ist aber sicherlich zu dieses, wie hast du gesagt, geschäftskritische.

Wolfgang: Also ist es jetzt ein altes Framework, wo es halt keine Leute mehr gibt,

Wolfgang: die sich damit auskennen?

Wolfgang: Dann ist es für mich schon geschäftskritisch, wenn ich jetzt sage,

Wolfgang: Oh, ich habe jetzt in der Firma jetzt nur noch den Christian,

Wolfgang: der sich damit auskennt und der geht jetzt schon irgendwie auf die Rente zu.

Wolfgang: Und wenn der weg ist, dann müssen wir uns super teure Consultants holen,

Wolfgang: die irgendwie 5000 Euro am Tag kosten.

Wolfgang: Dann ist das schon geschäftskritisch. Oder wenn es nicht mehr supported wird,

Wolfgang: wenn es keine Sicherheitsupdates mehr gibt, ist es geschäftskritisch.

Wolfgang: Und ich glaube, last but not least, wenn wir am Markt sehen,

Wolfgang: es gibt jetzt ganz viele andere,

Wolfgang: vielleicht auch schon gut abgehangene, etablierte Frameworks,

Wolfgang: die einfach viel effizienter sind, weil ich beispielsweise nicht mehr so Unmengen

Wolfgang: an Boilerplate-Code schreiben muss.

Wolfgang: Also ich komme aus der Java-Welt und ich kenne auch so Java Enterprise Version 2.

Wolfgang: Wenn ihr es nicht kennt, seid froh. Da musste man unglaublich viel Boilerplate-Code

Wolfgang: schreiben und da gab es dann auch Generatoren, die das generiert haben.

Wolfgang: Aber wenn man dann halt guckt, irgendwann gab es dann sowas wie Spring und das

Wolfgang: hat das Gleiche gemacht, aber du musst es einfach viel weniger tippen.

Wolfgang: Dann ist das auch, glaube ich, geschäftskritisch, weil ich dann einfach viel

Wolfgang: weniger Zeit brauche, um irgendein simples Feature zu implementieren.

Christian: Ich glaube, für die Entwicklung ist das wahrscheinlich wirklich ein valider Punkt.

Christian: Aber aus dem Betrieblichen ist es natürlich so, dass man auch Erfahrung mit

Christian: einer konkreten Komponente haben muss, um auch Stabilität zu kriegen.

Christian: Es ist ja nicht einfach nur der Code, den die Komponente ausmacht,

Christian: sondern es ist auch einfach die Zeit, die sie schon der harten Realität ausgesetzt

Christian: ist. Also ich bleibe mal bei meinem Autobahrspiel.

Christian: Also mein eigenes Fahrzeug dann, das kenne ich, da kenne ich die Macken.

Christian: Ich weiß vielleicht bei der einen oder anderen Problematik, was ich tun kann,

Christian: aber ich würde sagen auch, geh mal einen Schritt weiter raus von der einzelnen Instanz.

Christian: Das Produkt selber, wenn das Produkt schon sehr reif ist, sehr lange gebaut

Christian: wird, dann wird man schon die typischen, ich sag mal, die Kinderkrankheiten

Christian: sowieso vom Anfang, aber auch typische bekannte Probleme, für die gibt es schon

Christian: Lösungen, Herangehensweise.

Christian: Das heißt, auch zu sehr dem Druck zu unterliegen, das Neueste einzusetzen,

Christian: ist natürlich auf der einen Seite ein Problem, was man sich selber macht,

Christian: aber eben auch ganz konkret der Wechsel hin zu einer anderen Komponente.

Christian: Selbst wenn sie auch reif ist, ich habe die Erfahrung noch nicht.

Christian: Ich weiß noch nicht, wie gut man damit umgeht.

Christian: Also ich habe vielleicht auch oft Betriebsparameter zum Beispiel.

Christian: Ich habe vielleicht noch im Monitoring der Komponente einfach noch nicht so

Christian: viel Erfahrung, um sie effizient oder vor allen Dingen aber auch fehlerarm zu betreiben.

Christian: Das heißt also, der Gegenentwurf dazu, vorne dran zu sein, ist natürlich,

Christian: ich brauche irgendwas zwischen unausgereift und buggy und deprecated.

Christian: Irgendwo dazwischen sucht man halt den Sweets-Programm.

Wolfgang: Ja, sehr, sehr spannend. Wie sieht es denn dann bei dir aus,

Wolfgang: Simon, in der DMA, wenn man da über diese Aspekte spricht?

Simon: Ja, also was in der DMA nochmal so ein ganz eigener Faktor für sich ist,

Simon: ist sicher das Thema Datenqualität, also wo Schulden entstehen können.

Simon: Denken wir dran, wir kriegen oft ungesäuberte Daten irgendwo her und jetzt sagen

Simon: wir vielleicht auch, okay, wir verstehen die Daten vielleicht nicht zu 100 Prozent,

Simon: wir nehmen die jetzt mal so als gegeben und wir bauen daraus ein Datenprodukt.

Simon: Und dann ist das auch eine Form von Schulden, weil eigentlich sind wir angehalten,

Simon: diese Daten zu überprüfen, sicherzustellen,

Simon: dass diese Daten auch eine gleichbleibende Qualität haben.

Simon: Und da sind wir jetzt auch wieder bei dem Punkt, in dem POC zum Beispiel,

Simon: wo man sagt, okay, wir wollen jetzt erstmal die Machbarkeit analysieren,

Simon: ob sowas funktioniert, können wir auf diesen Datenmodell trainieren.

Simon: Dann geben wir das mal einem Kunden und der darf das mal ausprobieren.

Simon: Aber am Ende, wenn wir mit so einem Produkt dann live gehen,

Simon: das dann wirklich in den Einsatz kommt, dann wollen wir eigentlich sicherstellen,

Simon: dass wir checken kontinuierlich, sind die Daten plausibel, sind die Daten vollständig.

Simon: Das ist sicher nochmal so ein Aspekt, der in der Datenwelt dazukommt,

Simon: weil wir viel mit Unbekannten arbeiten, wenn wir eben Sensordaten oder ähnliches bekommen.

Wolfgang: Und bei dem POC ist ja auch immer wichtig, dass man den nicht einfach so dann

Wolfgang: produktiv wirklich weiterverwendet, sondern dass man eben im Nachgang noch die

Wolfgang: Zeit reinsteckt, die man halt vorab gespart hat,

Wolfgang: weil man es halt schneller umsetzen wollte,

Wolfgang: um herauszufinden, ob das generell funktioniert.

Simon: Genau, das ist ein absolutes Muss.

Wolfgang: Es klang jetzt schon ein bisschen durch in unserem Gespräch,

Wolfgang: dass es verschiedene Möglichkeiten gibt,

Wolfgang: mit diesem Themenkomplex umzugehen und ich glaube, man braucht da natürlich

Wolfgang: auch verschiedene Möglichkeiten, weil die Ursachen für technische Schulden ja

Wolfgang: auch sehr divers sind einfach,

Wolfgang: je nachdem, vor allem auch in welchem Bereich, dass wir hier unterwegs sind.

Wolfgang: Aber vielleicht kriegen wir ja trotzdem hin, mal uns drüber zu unterhalten,

Wolfgang: was denn eurer Meinung und eurer Erfahrung nach gute Möglichkeiten sind,

Wolfgang: generell mit dem Themenkomplex umzugehen, weil das Ganze zu erkennen,

Wolfgang: okay, das ist natürlich super wichtig und auch immer so die absolute Basis dafür,

Wolfgang: irgendwas zu tun und irgendwie in die Handlung zu kommen.

Wolfgang: Aber ich sehe jetzt mindestens 30 Jahre Erfahrung vor mir, vielleicht sogar

Wolfgang: auch ein paar Jahre mehr, wahrscheinlich ein paar Jahre mehr.

Wolfgang: Was sind denn eurer Meinung nach gute Möglichkeiten oder vielleicht auch so

Wolfgang: Best Practices, um mit dem Thema umzugehen und zu vermeiden,

Wolfgang: dass einem am Schluss das einfach komplett auf die Füße fällt?

Wolfgang: Was würdest du denn da vielleicht in der AD machen oder in der Softwareentwicklung, Christoph?

Christoph: Punkt 1 wir brauchen Problembewusstsein,

Christoph: Ich denke, dass auf der Arbeitsebene, also bei den Leuten, die direkt mit dem

Christoph: Code arbeiten, die direkt an diesem Produkt mitentwickeln, dieses Bewusstsein

Christoph: in aller Regel vorhanden ist.

Christoph: Je weiter hoch man in der Organisation geht, desto abstrakter wird das Ganze natürlich.

Christoph: Und dann muss man dafür sorgen, dass dieser Thematik auf den höheren Ebenen

Christoph: ein ausreichender Stellenwert eingeräumt wird,

Christoph: weil gerade diese Ebenen ja noch viel mehr und direkter den wirtschaftlichen

Christoph: Zwängen unterworfen sind.

Christoph: Und gerade das mittlere Management ist dann ja oft in diesem Spannungsverhältnis.

Christoph: Von oben kommt der Druck. Wir müssen jetzt hier Zahlen, Zahlen, Zahlen gut kriegen.

Christoph: Und von unten heißt es dann, wir können nicht so schnell, weil wir haben dann

Christoph: so die technischen Schulden.

Christoph: Und da ist es erstmal wichtig, ein gemeinsames Verständnis für die Problematik zu schaffen.

Christoph: Und was da, denke ich, ganz gut helfen kann, sind Metriken.

Christoph: Es gibt jetzt nicht die Metrik, die genauso gut wäre wie das Finanzielle bei

Christoph: finanziellen Schulden, aber es gibt zumindest so ein paar Indikatoren,

Christoph: die man vielleicht ganz gut ranziehen kann.

Christoph: Ich denke jetzt an sowas wie gängige Architekturmetriken, so Kopplungsmetriken

Christoph: zwischen Komponenten, Warnungen vom Compiler und von Lintern, solche Sachen.

Christoph: Anhand dieser Metriken und anhand dieser Trends kann man sicherlich schon ganz

Christoph: gut verargumentieren, dass wir jetzt gerade ein Problem in unserer Code-Basis

Christoph: haben und dann vielleicht mal aufräumen müssen.

Christoph: Solche Metriken dürfen natürlich nicht zum Selbstzweck werden.

Christoph: Es gibt dieses schöne Gesetz von Goodheart, sobald eine Metrik zum Ziel wird,

Christoph: hört sie auf, eine sinnvolle Metrik zu sein.

Wolfgang: Ich kenne Projekte, da war die Testabdeckung eine sehr, sehr wichtige Metrik

Wolfgang: für einen Jahresbonus und ich habe Projekte erlebt, wo die Testabdeckung bei 100% war.

Christoph: Ja, das sind genau solche Effekte. Wenn dann Leute anfangen,

Christoph: Indikatoroptimierung zu betreiben, dann bringt es natürlich nichts.

Christoph: Ich habe auch eine schöne Anekdote gehört von einem größeren Konzern,

Christoph: der sehr prozessgetrieben gearbeitet hat.

Christoph: Die haben einen Open-Source-Compiler verwendet und das Entwicklungsteam wollte

Christoph: gerne auf eine neuere Version hochgehen, weil neuer Compiler bringt bessere

Christoph: Code-Qualität, mehr Performance und auch bessere Compiler-Warnungen.

Christoph: Der Prozess hat es leider nicht zugelassen, weil eine neue Compiler-Version

Christoph: senkt leider die Code-Qualität.

Christoph: Warum ist das so? Naja, eine neue Compiler-Version bringt halt mehr Warnungen.

Christoph: Mehr Warnungen heißt schlechterer Code, also macht der neue Compiler unseren

Christoph: Code schlechter, also können wir den nicht benutzen. In die Falle sollte man

Christoph: natürlich nicht reinlaufen.

Christoph: Trotzdem hilft es, denke ich, solche Metriken zu erheben, mit solchen Metriken

Christoph: dann entsprechend auch zu kommunizieren.

Christoph: Und das Ziel muss dann sein, entsprechende Maßnahmen, also Arbeiten an der Code-Qualität,

Christoph: Arbeiten an der Software-Architektur, gerade ziehen von Sachen, die nicht passen.

Christoph: Einzuplanen in die normale Entwicklungsarbeit. Also wenn wir jetzt agil arbeiten,

Christoph: zum Beispiel, dass wir eben in unserem Backlog nicht nur Feature-Arbeit haben,

Christoph: sondern auch Architektur-Arbeit, um diese Schulden wieder gezielt abzubauen.

Christian: Ja, das deckt sich so ein bisschen mit dem, was ich meinte mit Betriebsthemen.

Christian: Also ich meine, was bei euch im Softwarebereich ist, ich habe gewisse Unterhaltungskosten.

Christian: Also bei meinem Autobeispiel zu bleiben, ich kann es nicht nur fahren.

Christian: Ab und an muss ich auch, weiß ich nicht, Reifen wechseln, neue Bremsbeläge.

Christian: Ich habe diese Aufwände.

Christian: Ich kann bei einer längeren Fahrt vergessen, dass es sie gibt,

Christian: aber irgendwann wird mich das komplexe Ding daran erinnern, dass es diese Aufwände gibt.

Christian: Und spätestens dann, wenn jemand sagt, kannst du mich mal schnell 500 Kilometer

Christian: irgendwo hinfahren und ich stelle fest, dass das ein oder andere dem entgegensteht.

Christian: Also, dass das Ding einfach nicht breit ist, mit den Features oder mit den geschäftlichen

Christian: Anfällen, die reinkommen.

Christian: Ich fand das super, dass du sagst, eine Metrik, weil Metrik bei dem Begriff

Christian: ist für mich immer wirklich messbar, objektiv.

Christian: Und das finde ich immer gut, weil du, gerade wenn du andere Unternehmensteile,

Christian: die vielleicht ja weniger konkret mit der Technik, mit dem Code arbeiten,

Christian: also dass auch diese Dimensionen gar nicht verstehen können,

Christian: weil sie diese Einsichtereien ja gar nicht haben,

Christian: dass man das mit Metriken sichtbar macht, die dort auch verstanden werden können.

Christian: Und auch, wenn ich jetzt unsere Bereiche mal so nebeneinander lege,

Christian: die auch ganz andere Bereiche sind, dass man also Metriken findet,

Christian: die übergreifend funktionieren.

Christian: Und ich finde, dann ist natürlich klar, so Indikatoren wie komplex ist irgendwas,

Christian: wie oft wird irgendeine Methode woanders aufgerufen oder wie verbreitet ist, was ist eins.

Christian: Ich finde aber auch dann relevant für die eigene Änderungsrate zum Beispiel,

Christian: die ein Unternehmen oder diese Anwendung hat,

Christian: welche Pfade, also welche Komponenten werden sehr häufig angefasst,

Christian: werden sehr häufig geändert, von wem werden sie geändert, wie viele Personen

Christian: sind das, das ist ja auch noch eine Dimension.

Christian: Also ich finde, eine Schuld ist auch, wenn es den einen niederkennt,

Christian: das glaube ich aus seiner Berufserfahrung, es gibt dann irgendwann die eine

Christian: Kollegin oder den einen Kollegen, wo man denkt, boah, wenn der nicht da ist

Christian: oder sie nicht da ist, das fassen wir nicht an, da kennt sich niemand mit aus.

Christian: Und das ist natürlich unternehmerisch gesehen auch eine Schuld,

Christian: wenn man sie will oder ein Risiko.

Christian: Also das ist so ein bisschen wie das Spezialwerkzeug, was dir dann fehlt,

Christian: um das eine oder andere heile zu machen. Selbst wenn du wüsstest,

Christian: was du zu tun hast, du kannst es einfach nicht.

Christoph: Ja, in dem Sinn kann man auch das Fehlen von Dokumentation oder das Fehlen von

Christoph: aktueller Dokumentation als technische Schuld bezeichnen, weil für das Schreiben

Christoph: von Dokumentation ist ja eh immer zu wenig Zeit und das fällt dann auch sehr gerne mal runter.

Simon: Absolut, ja. Oder auch fehlende Code-Konventionen, Clean Code.

Simon: Also neben den Schulden, die man ja metrisch bewerten kann, also wo man eine

Simon: Zahl ranhängen kann, gibt es ja auch ganz viele Schulden, die sind uns allen

Simon: bewusst, aber da kann man keine Zahl dranhängen.

Simon: Und das sind Schulden, die uns einfach im täglichen Geschäft vielleicht begegnen

Simon: und uns langsamer machen.

Simon: Aber das lässt sich einfach schlecht beziffern. Und ich denke,

Simon: Priorisierung ist da eine ganz große Herausforderung.

Simon: Also wie wiegt man dann die Schulden, die man bewerten kann,

Simon: gegen die, die man nicht bewerten kann, ab?

Simon: Ich glaube, da muss jedes Team irgendwie den eigenen Weg dann finden,

Simon: wie man die zusammenbringt und gegeneinander priorisiert. Weil die Zeit ist am Ende endlich.

Simon: Ich glaube, wir wissen, wir müssen alle Zeit dafür schaffen.

Simon: Das muss man auch sehr bewusst tun, Zeit für diese Themen schaffen.

Simon: Die Herausforderung ist, denke ich, die Priorisierung. Also welches Thema gehe ich als erstes an?

Simon: Was blockiert mich gerade am meisten? Was kostet mich am meisten Zeit, Geld, Ressourcen?

Wolfgang: Ja.

Wolfgang: Also ich finde das total gut und nachvollziehbar, was ihr da sagt,

Wolfgang: also die Idee mit den Metriken sichtbar machen etc.

Wolfgang: Ich habe nur noch so diesen einen Gedanken dabei und zwar in vielen Projekten,

Wolfgang: in denen ich war, war es so, dass die einzigst valide Währung des Projekts war

Wolfgang: diese ominöse Velocity.

Wolfgang: Also wie viel kann so ein Team eigentlich an neuen Features umsetzen?

Wolfgang: Und ich habe viele Diskussionen miterlebt mit Product Ownern,

Wolfgang: wo es darum ging, dass man wirklich hart verhandelt hat, ob es jetzt nicht möglich

Wolfgang: ist, in diesem Sprint mal noch einen halben Tag zu investieren,

Wolfgang: um vielleicht technische Schulden anzugehen oder so ein Betriebsthema.

Wolfgang: Diesen Begriff von dir, Christian, finde ich übrigens echt super.

Wolfgang: Weil man ja immer so diesen Unterhalt irgendwie auch bezahlen oder investieren muss.

Wolfgang: Aber da habe ich sehr viele Diskussionen miterlebt, in denen das wirklich sehr,

Wolfgang: sehr schwer war und wo oft auch ein bisschen das Verständnis gefehlt hat,

Wolfgang: was ich nachvollziehen kann. Dann Softwareentwicklung ist halt im Vergleich

Wolfgang: zum Handwerk einfach sehr abstrakt.

Wolfgang: Und ich glaube, jeder Mensch kann nachvollziehen, wenn man sich jetzt ein Auto

Wolfgang: kauft, dass man das Auto halt jetzt nur bekommt mit Lenkrad und mit Gurt irgendwie.

Wolfgang: Und wenn ich jetzt zum Autohändler gehe und sage, ja, Gurt brauche ich nicht,

Wolfgang: ich schneide mich sowieso nicht an, kannst du es billiger machen,

Wolfgang: dann lacht mich halt der Autohändler wahrscheinlich aus, vermute ich mal.

Wolfgang: Und wenn ich zum Bäcker gehe und sage, ich hätte gerne einen Erdbeerkuchen,

Wolfgang: Aber ohne Erdbeeren, dann bekomme ich den wahrscheinlich auch nicht,

Wolfgang: weil das die berufliche Ehre des Bäckers vielleicht oder der Bäckerin ist,

Wolfgang: das Produkt mir nur komplett über den Tresen zu reichen.

Wolfgang: Im Softwarebereich ist es immer so ein bisschen anders, weil,

Wolfgang: glaube ich, das Verständnis oft fehlt.

Wolfgang: Und ich glaube in den Teams steckt das überall drin, ich glaube in den Teams

Wolfgang: wissen die meisten Leute, wann was in Anführungszeichen gut und was schlecht

Wolfgang: ist oder was vielleicht uns auf die Füße fallen kann.

Wolfgang: Was sind denn vielleicht Möglichkeiten, wie man solche Dokumentation oder so

Wolfgang: eine Sichtbarmachung vielleicht so ganz natürlich in den Arbeitsalltag mit einfließen lassen kann?

Wolfgang: Weil Dokumentation ist auch wichtig, aber bei einer klassischen Doku musst du

Wolfgang: dich halt vielleicht wieder hinsetzen, hast die Zeit nicht.

Wolfgang: Aber gibt es da eurer Meinung nach vielleicht irgendeinen Modus,

Wolfgang: den ich so ganz einfach in meinen Arbeitsteiltag einfließen lassen kann,

Wolfgang: um das zumindest sichtbar zu machen und die Awareness dafür zu schaffen?

Christoph: Was immer hilft, ist natürlich solche Tätigkeiten von vornherein in den Prozess

Christoph: zu integrieren und entsprechende Vorgaben zu machen und das auch im Team zu leben.

Christoph: Und was natürlich immer hilft, ist, wenn genügend Leute das machen,

Christoph: haben sie eine Vorbildfunktion und ziehen alle anderen mit.

Christoph: Und insofern ist es ein ganz guter Weg, technische Schulden zu verhindern,

Christoph: indem man von vornherein dafür sorgt, dass sie gar nicht auftreten.

Wolfgang: Ja.

Christoph: Ich kann mir da viele Dinge vorstellen, die man machen kann.

Christoph: Das eine ist, das, was ich gerade gesagt habe, dass man über den Prozess eben

Christoph: sauber arbeitet und auch solchen

Christoph: Themen wie Dokumentation und Code Review und dergleichen Raum gibt.

Christoph: Zum anderen bin ich selber auch ein ganz großer Freund davon,

Christoph: Architekturrichtlinien werkzeuggestützt zu überprüfen, mithilfe von der CI-Pipeline

Christoph: und dadurch dafür zu sorgen,

Christoph: dass so bestimmte Dinge, bestimmte Degenerationsprozesse, die jede Code-Basis durchläuft,

Christoph: aktiv verhindert werden.

Christoph: Code neigt dazu, zusammenzuklumpen. Eine schöne, saubere Architektur,

Christoph: die man am Anfang des Projekts mal ausgearbeitet hat,

Christoph: neigt über die Jahre dazu, zu degenerieren, weil neue Leute dazukommen,

Christoph: die wissen nicht so ganz genau Bescheid über die Architektur,

Christoph: dann wird da mal schnell an der Stelle, wo es eigentlich nicht hingehört,

Christoph: das Feature implementiert und dann wird das Ganze von diesem schönen,

Christoph: sauber geschnittenen System zu diesem großen Klumpen.

Christoph: Und wenn man aber werkzeuggestützt die Architekturrichtlinien forciert,

Christoph: dann passiert das nicht so leicht.

Christian: Also da gehe ich absolut mit. Wir haben eben ja das Thema Updates und so weiter.

Christian: Also es gibt sehr gute Werkzeuge, um auch solche Konventionen zum Beispiel automatisiert

Christian: zu überprüfen und sowas im Grunde schon in die Erstellungsphase mit zu integrieren,

Christian: dass man von vornherein sauber beginnt.

Christian: Und ich glaube aber dann auch daran, dass man das immer noch im Spannungsfeld des Pragmatismus ist.

Christian: Man kann nicht immer sagen, ja, wenn ich es alles nochmal neu machen würde,

Christian: dann würde ich es anders machen.

Christian: Also man hat schon das lebende Objekt. Manchmal muss man auch,

Christian: nicht zuletzt, weil man vielleicht auch noch keinen neuen Entwurf hat,

Christian: wie man es ganz anders machen würde oder man weiß noch nicht,

Christian: na, das Tool, das knarzt jetzt schon ein bisschen, das ist nicht perfekt,

Christian: aber ich hätte auch jetzt keine Alternative,

Christian: also man ist einem gewissen Pragmatismus unterlegen,

Christian: aber dass man dann eben auch genauer schaut,

Christian: welche Dinge oder an welchen Punkten kommt es besonders häufig vor.

Christian: Also ich glaube, im Software-Bereich, an welchen Codestellen wird sehr viel

Christian: Änderungen gemacht, was ist der heißeste Codepad, um das ein bisschen zielgerichter zu haben.

Christian: Also auf der einen Seite eben, wo ist die Differenz zwischen Optimum,

Christian: wenn man das so definieren will, was man sich immer, was man sich gesetzt hat,

Christian: und aber auch Häufigkeit oder Risiko.

Christian: Also das ist ganz, ganz kritische Komponente, wo man sagt, boah,

Christian: da müssten wir binnen kürzester Zeit auch auf Änderungen reagieren können,

Christian: da wollen wir was dran machen.

Christian: Und das Produkt aus beidem, wenn es extrem komplex ist,

Christian: extrem risikobehaftet ist, aber nicht häufig benutzt wird, dann hat es auch

Christian: Gewicht, aber auch etwas, was vielleicht noch nicht ganz so viel debt hat,

Christian: was noch nicht ganz so schlecht ist, was aber extrem häufig benutzt wird oder

Christian: wo sich nur ganz wenig Leute mit auskennen mit dieser Komponente,

Christian: dann ist es auch schon Risiko.

Christian: Und ich glaube, diese Metriken durchaus auch mal als Produkt zu verstehen und

Christian: dann eben so zielgerichtet aufzuzeigen, dass man nicht so fundamental sagt,

Christian: weil das ist, glaube ich, schwierig in der Akzeptanz, dass man sagt,

Christian: ja, wir würden gerne mit höherer Qualität arbeiten, das will man eigentlich immer,

Christian: aber eben, ja, die Pragmatik des Alltags zwingt einen natürlich dazu,

Christian: auch mal, ja, zu liefern, zu releasen, den Sprint zu beenden und dann aber,

Christian: ja, Metriken zu haben, die über die Zeit vor allen Dingen aufzeigen,

Christian: was wären Punkte, die absolut,

Christian: Aufmerksamkeit erfordern und andere, ja, die unterliegen in dem Pragmatismus.

Christian: Die sind nicht perfekt, aber die sind dann eben so.

Simon: Vielleicht nochmal auf so einer ganz individuellen Ebene, also auch zum Thema

Simon: Pragmatismus, weil ich glaube, wir müssen uns da auch alle an die eigene Nase fassen.

Simon: Also wir sind wahrscheinlich alle schuldig in der einen oder anderen Form,

Simon: mal Schulden in Anführungszeichen fürs Team aufgenommen zu haben.

Simon: Ich glaube, da hilft es auch. Das klingt jetzt banal, aber ich glaube,

Simon: es hilft sich auch immer wieder, die Sprüche in den Kopf zu ruft.

Simon: Also wenn ich ein Stück Code anfasse, dann will ich es besser hinterlassen,

Simon: als ich es vorgefunden habe.

Simon: Oder was ich auch gerne mache, so ein Daily Wrap-Up. Also am Ende des Tages

Simon: sich vielleicht nochmal eine halbe Stunde Zeit nehmen und sich überlegen,

Simon: was habe ich heute alles gemacht?

Simon: Habe ich das in einem guten Zustand hinterlassen? Habe ich die Dokumentation geschrieben?

Simon: Habe ich meine Doc-Strings ordentlich geschrieben? eben sie einfach die Zeit

Simon: dafür nehmen, nochmal so ein Wrap-up zu machen und dafür zu sorgen,

Simon: dass alles in einem guten Zustand den Tag sozusagen übersteht.

Christoph: Genau. Du sprichst das Pfadfinderprinzip an, also jeden Ort,

Christoph: den man besucht, ein bisschen sauberer zu hinterlassen, als man ihn vorgefunden hat.

Christoph: Heißt dann halt metaphorisch, wenn man irgendwelche Plastikverpackungen von

Christoph: Schokoriegeln auf dem Boden findet, die aufzuheben.

Christoph: Und das ist aus meiner Sicht auch was, was man ganz normal in seinen Arbeitsalltag

Christoph: integrieren kann und dann nicht noch irgendwie extra Planungen dafür anstoßen

Christoph: muss, sondern das sollte einfach gelebte Praxis sein.

Christoph: Wenn man als Pfadfinder auf dem Campingplatz natürlich Fässer mit Sondermüll

Christoph: vorfindet, muss natürlich eine entsprechende Planung rein.

Christian: Ja, der Sondermüll lässt mich schmunzeln, ja. Also was,

Christian: er hat jetzt eben auch schon mal kurz erwähnt, den Begriff Code-Review zum Beispiel,

Christian: also weil wir sind ja noch so ein bisschen daran zu überlegen,

Christian: wie kann man verhindern, dass die Schuld allzu groß wird oder dass man sich

Christian: gar nicht bewusst macht.

Christian: Also was mir immer wieder auffällt, ist wie sehr Qualitätsbewusstsein,

Christian: Pfadfinderprinzip, was er gerade sagt, aber auch im Einklang mit einem Code-Review,

Christian: vielleicht auch mit einem Code-Review durch jemanden mit viel Erfahrung,

Christian: das so ein bisschen mitigiert.

Christian: Also man merkt, das ist eine kleine unschuldige Änderung, der Pragmatismus.

Christian: Ja, im Bereich Infrastruktur, wo ich bin, da wird ja...

Christian: Sehr wenig typisierte Dinge, da wird sehr viel mit Strings gearbeitet,

Christian: also dem Ganzen eine gewisse Semantik und Qualitätsanspruch und so weiter zu

Christian: geben und den auch zu halten, damit man sich darauf stützen kann,

Christian: damit das ein Konstrukt ist. Ich meine, ich gucke mal in deine Richtung,

Christian: Simon, das ist ja im Datenbereich auch so.

Christian: Das sind erstmal alles einfach nur Felder mit arbiträren Werten,

Christian: bis jemand sagt, da gibt es eine gewisse Semantik, die oben drauf ist.

Christian: In der Infrastruktur ist das nicht anders. Also, dass man streng damit ist.

Christian: Ja, Wertebereiche, also gültige Werte für irgendwas einzuschränken,

Christian: also jetzt nur mal ein paar technische, konkrete Sachen zu machen.

Christian: Und diese Weitsicht, muss man sagen, bekommt man mit der Zeit durchaus.

Christian: Das heißt, es hilft schon, wenn jemand, der eben, ja, schnell Ergebnisse liefern

Christian: will, jemand mit ein bisschen weniger Erfahrung, durchaus auch ein bisschen

Christian: Guidance und, ja, Code-Review oder Anleitung bekommt, zu sagen,

Christian: dass man die Konsequenzen von sowas, wenn das ein bisschen größer wird.

Christian: Also es ist schnell die einzelne Aufgabe jetzt hier gelöst.

Christian: Man kann da einfach schnell mal ein Feld einfügen und irgendwelche Dinge mitmachen

Christian: und dann ist es doch genauso, wie man will.

Christian: Aber dass man sagt, naja, aber mit der Einführung des Feldes musst du dich ab

Christian: jetzt auch darum kümmern.

Christian: Du hast jetzt was eingebaut, was jetzt Teil vom Ganzen geworden ist und das

Christian: musst du jetzt über den ganzen Lebenszyklus bringen. Was ist,

Christian: wenn jemand Drittes das verwendet?

Christian: Bist du dir sicher, dass du alle Auswirkungen kennst, wenn jemand mal einen

Christian: anderen Wert darüber übergibt und so weiter?

Christian: Dann wird es halt ganz schnell schwergewichtiger, als es am Anfang aussah.

Christian: Und dann hast du schon auch noch so eine Moderation dieses Pragmatismus so ein bisschen.

Christian: Also ohne, dass man jetzt immer als erfahrener Kollege da auf der Bremse steht

Christian: und sagt, Hauptsache alles ganz langsam und so. Das will ich damit nicht sagen, aber dass man.

Christian: Dieses Pfadfinderprinzip, dieses Qualitätsbewusstsein, die Auswirkungen davon,

Christian: dass man die mit etwas mehr Erfahrung natürlich besser absehen kann,

Christian: als jemand, der eben schnell, schnell zum Ergebnis kommen will und vielleicht

Christian: auch besser darstellen kann, weil das war das Beispiel ja auch schon,

Christian: wieso ist das so aufwendig?

Christian: Es ist kein Problem, es schnell mal ans Laufen zu bringen, aber wenn wir als

Christian: Teil von einem größeren Ökosystem etwas machen, dann müssen wir uns den gesamten

Christian: Lebenszyklus angucken.

Christian: Also auch die Konsequenz, wenn das mal zwei, drei, vier, fünf Jahre im Betrieb

Christian: ist oder gar noch, wenn man das rausgibt an Dritte, die man nicht kontrollieren

Christian: kann, die man nicht anrufen kann.

Christian: Also wenn du was an Endkunden rausgibst und so, dann ist natürlich der Lebenszyklus ganz anders.

Christoph: Ja, das ist die klassische Falle, wo man häufig reinrennt.

Christoph: Da hat jemand einen Prototypen gebaut und der Prototyp sieht da eigentlich schon ganz gut aus.

Christoph: Kann man das nicht gleich als Produkt auf den Markt bringen?

Christoph: Und die Antwort ist halt meistens nein. Da muss nochmal weitere Entwicklungsarbeit

Christoph: reingesteckt werden. Das muss noch gerade gezogen werden.

Christoph: Sonst fällt uns das über kurz oder lang auf die Füße.

Wolfgang: Ja, da braucht man vielleicht dann aber auch so das Selbstbewusstsein,

Wolfgang: vor allem, wenn man halt einfach schon länger dabei ist und Erfahrung irgendwo gesammelt hat.

Wolfgang: Und selbst wenn man vielleicht am Ende nicht das letzte Wort hat,

Wolfgang: wann das Release gemacht wird, glaube ich, ist es halt einfach wichtig,

Wolfgang: dass man halt laut darauf hinweist, dass vielleicht manche Dinge nicht perfekt sind.

Wolfgang: Und ich kenne halt auch so diese ganzen Diskussionen, wenn es um sowas wie Testing

Wolfgang: geht oder Dokumentation geht,

Wolfgang: dass das bei vielen Leuten, die vielleicht ein bisschen weiter weg sind von

Wolfgang: der Entwicklung, dann eher sowas Optionales ist oder noch schlimmer,

Wolfgang: so die Selbstverwirklichung von den Leuten, die entwickeln.

Christian: Wobei die Industrie natürlich auch sehr laut schreit, also was neue Tools,

Christian: neue Herangehensweisen angeht.

Christian: Da gibt es natürlich ganz klar Innovation, das wäre ja verwegen,

Christian: wenn ich sagen würde, das ist nicht so.

Christian: Neue Werkzeuge, die das Leben wirklich leichter machen, aber natürlich,

Christian: ja, ob man eine Fachkonferenz oder Publikationen oder die ein oder anderen Blogs

Christian: sucht, jeder benutzt immer das Allerneueste und ist nur deswegen total erfolgreich

Christian: und es war alles total easy.

Christian: Und das ist natürlich auch so ein, ja, das ist sehr laut, dieser Druck,

Christian: der einem das Gefühl vermittelt,

Christian: ja, gibt ja so ein bisschen die Gegenbewegung, zumindest in meinem Metier,

Christian: der Boring Technology, man muss jetzt also nicht die, was weiß ich, fanzigste NoSQL,

Christian: NoCode, sonst wie Approach nehmen, um ein kleineres, kleines Ding umzusetzen.

Christian: Also auch die etablierte, langweilige, gut verstandene Technologie kann sich da zum Ziel bringen.

Christian: Das ist auch natürlich sowas, muss man auch den einen oder anderen,

Christian: habe ich im Kundenfeld schon mal häufiger, dass man daran erinnert,

Christian: dass die IT, gerade wir sind ja als Dienstleister unterwegs,

Christian: dass die IT dem Business,

Christian: dem Geschäftsinteresse des Unternehmens dienen soll und nicht nur eine Selbstverwirklichung ist.

Christian: Also ich finde das interessant, dass das oft, also zumindest mir geht das so,

Christian: oft auch aus unserem Munde kommen muss, obwohl wir natürlich total technologiebegeistert sind.

Christian: Wir würden gerne immer das Neueste benutzen, aber natürlich wissen wir auch.

Christian: Das ist ja kein Sandkasten, kein Spielplatz, dass IT ist Mittel zum Zweck und

Christian: die Diskussion über Technical Debt ist ja,

Christian: dass wir da vital bleiben, aber nicht, dass wir irgendeinem künstlich auf oktuierten

Christian: Neuheitsdrang irgendwie nachgeben müssen, dass nur wenn das mit der neuesten

Christian: Technologie umgesetzt ist oder so,

Christian: dass das dann gebrauchstauglich ist oder dass es immer dem Geschäftsinteresse dient,

Christian: etwas neu zu machen oder mit dem neuesten Ansatz umzusetzen.

Wolfgang: Ja, das ist ein guter Punkt. Letztendlich gibt es halt einfach super viele Punkte,

Wolfgang: die man beachten muss bei einer Auswahl von der Technologie und aber auch bei

Wolfgang: der Auswahl von der Vorgehensweise einfach.

Wolfgang: Und das macht es natürlich dann auch spannend.

Wolfgang: Wenn wir jetzt mal alles nochmal uns durch den Kopf gehen lassen,

Wolfgang: was wir jetzt die letzte Stunde besprochen haben, gibt es dann vielleicht doch

Wolfgang: irgendwie von eurer Seite so diese ultimativen Geheimtricks, wie man mit Techniker,

Wolfgang: wie spricht man es aus?

Wolfgang: Techniker Death? Ne, warte mal, das ist der technische Tod.

Wolfgang: Techniker, also ich bin nicht so gut im Englischen aussprechen.

Christian: Also ich glaube Techniker Death, also das B ist still, ist glaube ich der Okay.

Wolfgang: Also, dann habe ich es einmal richtig gesagt für das Protokoll,

Wolfgang: Technical Dead oder so ähnlich,

Wolfgang: wie man damit umgehen kann, weil ich glaube, man hat vielleicht die Projekte,

Wolfgang: wo man so Greenfield-mäßig neu anfängt und dann hat man vielleicht auch viel

Wolfgang: unter Kontrolle oder auch nicht, ups, we did it again,

Wolfgang: aber man kennt ja auch diese Projekte, wo man irgendwann mal reinkommt,

Wolfgang: das Projekt läuft schon seit fünf, sechs Jahren, man schaut es sich an,

Wolfgang: man merkt, uiuiuiuiui, da gibt es wirklich viel,

Wolfgang: Technical Dead, da ist noch der JBoss 3 im Einsatz und da gibt es keine Tests

Wolfgang: und keine Dokumentationen und ganz viele Shortcuts und überall sind so ein paar Pflaster drauf.

Wolfgang: Gibt es von eurer Seite aus irgendwelche Empfehlungen, Geheimtricks,

Wolfgang: wie man generell damit umgehen kann, wenn man mit sowas konfrontiert ist?

Simon: Genau, ich glaube, das Wichtigste ist, die Schulden im ersten Schritt mal zu

Simon: identifizieren und dann auch anzusprechen.

Simon: Also auch wenn man jetzt von der Codebase sitzt, die man vielleicht nicht mit

Simon: aufgebaut hat, sondern wo man,

Simon: mit reinkommt, ein neues Projekt, dann sollte man sich nicht schämen, Punkte anzusprechen.

Simon: Und dann geht es wiederum darum, zu priorisieren, ja, was blockiert mich jetzt

Simon: aktuell am Weiterkommen?

Simon: Was sind die nächsten Features, die ich entwickeln will?

Simon: Wo stehen mir jetzt diese Schulden im Weg?

Simon: Also, wo hindert es mich zum Beispiel an Skalierung? Also vielleicht habe ich

Simon: eine Technologie, die mich an der Skalierung händelt, aber ich will jetzt größere

Simon: Datenmengen verarbeiten oder eine größere Menge an Nutzern mit meinem Produkt bedienen.

Simon: Was steht mir dann da im Weg? Ich brauche eine neue Technologie, um skalieren zu können.

Simon: Also dann geht es wirklich darum, zielgerichtet und zielorientiert die Probleme zu identifizieren.

Wolfgang: Das klingt auf jeden Fall sehr gut strukturiert. Was würdest du dem noch hinzufügen, Christoph?

Christoph: Ich wünschte, es gäbe da eine magische Geheimwaffe, die das alles abgügelt,

Christoph: aber die gibt es leider nicht.

Christoph: Ich denke, alles, was wir jetzt besprochen haben in den letzten Minuten,

Christoph: muss einfach zusammenarbeiten.

Christoph: Auf der individuellen Ebene hilft es eben, dass man sich selbst hohe Standards

Christoph: setzt für die eigene Arbeit, die man leistet und eben immer ein bisschen sauberer

Christoph: arbeitet und immer ein bisschen aufräumt hinter sich.

Christoph: Auf der Prozessebene bedeutet das, dass man eben entsprechende Strukturen schafft

Christoph: und entsprechende Tätigkeiten vorsieht.

Christoph: Und auf der kommunikativen Ebene bedeutet das eben vor allem,

Christoph: dass man technische Schulden transparent macht,

Christoph: dass man ihre Auswirkungen auch klar macht und dass man vielleicht auch noch

Christoph: ein paar Zahlen in der Hinterhand hat, um das Ganze auch argumentieren zu können.

Christian: Und ich glaube, was unsere Beobachtungen eint, ist, dass es ein kontinuierliches Thema ist.

Christian: Also ich muss sagen, es gibt ja Zitate, die man immer wieder gerne aufbringt,

Christian: die einem in seiner täglichen Arbeit immer wieder in den Kopf kommen.

Christian: Eins von mir ist von Joel Spolsky, der seinerzeit bei Netscape war und da hat

Christian: man einen sehr schönen Post geschrieben.

Christian: Als man eben einen kompletten Rewrite der Software gemacht hat und hat es eben

Christian: rückblickend festgestellt, dass es etwas ist, was man niemals tun sollte.

Christian: Bei einem komplexen System zu glauben, man könne in kürzerer Zeit einfach das

Christian: Ganze mal mit einem neuen Ansatz nochmal umsetzen.

Christian: Das ist respektlos, denn tausenden Stunden, die man Erfahrung gesammelt hat

Christian: und in vielen Details stecken auch Komplexitäten drin, die man so einfach gar nicht sehen kann.

Christian: Und das ist ja ein Teil von dem Debt eigentlich.

Christian: Und wenn man dann glaubt, dass man den Debt im Grunde komplett abzahlen könnte,

Christian: indem man es einfach gerade nochmal frisch macht.

Christian: Ja, so einfach ist das nicht. Ich weiß nicht, die Autoanalogie hatte ich schon, das ist wie so ein Haus.

Christian: Also wenn ich ein älteres Haus habe und stell fest, ja, dann müssten wir mal Kleinigkeiten machen.

Christian: Ach komm, lass sein, wir bauen einfach ein Neues. Also zu glauben,

Christian: das sei alles viel einfacher.

Christian: Und man würde ja alle Fehler, die man bei dem einen gemacht hat,

Christian: auf keinen Fall mehr nochmal machen. und auch der Zeitraum, den das dauert,

Christian: bis das fertig ist, was machen wir denn so lange?

Christian: Lassen wir das andere Produkt dann weiter verschimmeln? Was machen wir mit den

Christian: geschäftlichen, betrieblichen Realitäten?

Christian: Ich muss es ja weiterentwickeln, weiter betreiben.

Christian: Also es wird sehr lange dauern, bis die neue Iteration da ist.

Christian: Das heißt, ich glaube, das eint uns hier. Das ist ein kontinuierlicher Prozess.

Christian: Den muss man sich optimalerweise natürlich von Beginn an bewusst machen.

Christian: Jedes Ding, was ich hinzufüge in ein komplexes System, In meinem Bereich ist

Christian: momentan der Begriff Platform, Platform Engineering ja in aller Munde.

Christian: Das ist ein integriertes Gesamtkonstrukt von verschiedensten Komponenten und

Christian: jede Komponente, die ich hinzufüge, der ich eben Konventionen,

Christian: Sinn und Struktur gebe, erhöht die Komplexität und erfordert automatisch dann auch Wartung.

Christian: Also das heißt, ich kann am Anfang schon überlegen, will ich das überhaupt haben?

Christian: Soll das ein Teil davon sein? Weil ich weiß, es wird Wartung erfordern.

Christian: Aber zu glauben, dass ich dieses ganze komplexe Ding en bloc durch ein anderes

Christian: komplexes Ding ersetze, mal nebenbei und dabei all die Schulden,

Christian: die ich aufgebaut habe, zu egalisieren, das ist wie gesagt,

Christian: du hast nicht von mir, sondern wie gesagt, der Joel Sportsker hat das sehr schön

Christian: rückblickend gesagt, das war einer der größten Fehler, die sie gemacht haben

Christian: und hat faktisch die Firma gefährdet.

Wolfgang: Ich glaube, da ist echt viel dran. Ich meine, das kennt man ja auch aus dem

Wolfgang: anderen Beispiel, das ich vorhin angeführt habe mit diesen alten COBOL-Systemen.

Wolfgang: Da gibt es natürlich viele Witze drüber und auch die Witze drüber,

Wolfgang: dass man heute richtig reich wird, wenn man nochmal mit COBOL-Entwicklung anfängt.

Wolfgang: Aber es gibt natürlich auch einen Grund, warum diese Systeme nach 30 oder 40

Wolfgang: Jahren vielleicht immer noch im Einsatz sind,

Wolfgang: weil es einfach zu riskant und zu teuer ist, das komplett neu zu machen und

Wolfgang: weil man dann doch lieber vielleicht so Stück für Stück erneuert oder außenrum

Wolfgang: Systeme ablöst, aber diesen Kobold-Kern immer noch bewahrt, weil man halt weiß,

Wolfgang: da sind tausende oder hunderttausende Stunden an Arbeit reingeflossen und es funktioniert.

Wolfgang: Und da braucht man, glaube ich, schon sehr viel Mut, um zu sagen,

Wolfgang: das machen wir jetzt komplett neu mit einer neuen, coolen Technologie.

Christian: Ja, ich glaube, mit diesem stückweiten Vorgehen bekommst du auch Management-Buy-in,

Christian: wie du das so schön eben gesagt hast, Christoph, also im Bewusstsein,

Christian: wenn ich eben einen Return aufzeigen kann.

Christian: Also ich kann einmal natürlich eine Metrik, wie wir eben besprochen haben,

Christian: aufzeigen, dass das etwas ist, wo man am ehesten Fokus drauflegen sollte,

Christian: aber dass ich dann auch eine Antwort oder eine Idee habe, wie man da vorgehen

Christian: kann, die in absehbarer Zeit einen Return bringt. Dass man nicht, ja,

Christian: so ein bisschen wie beim Renovieren, wenn wir das machen, dann können wir auch

Christian: noch das machen, aber wenn wir das schon dran sind, machen wir das,

Christian: dann machen wir doch was ganz Neues.

Christian: Und das, wo der Return ewig lang hin ist, und dann merkt man halt,

Christian: dass über die Zeit, drei, vier, fünf Sprints später ist der Fokus,

Christian: der so lupenklar war, was man machen wollte, der ist komplett verwässert schon.

Christian: Man weiß schon gar nicht mehr genau, was wollte man machen.

Christian: Es kommen noch neue Themen rein, und man hat wahrscheinlich die Komplexität

Christian: von vornherein auch noch ein bisschen unterschätzt, die da drin ist.

Christian: Es wirkte so klein und unschuldig, dass man das nur mal schnell ändert.

Wolfgang: Nur mal schnell, das ist aber auch so ein Klassiker aus der Entwicklung, oder?

Wolfgang: Das machen wir mal ganz schnell nebenher am Freitagnachmittag.

Wolfgang: Ich fand unser Gespräch super interessant. Ich fand es spannend,

Wolfgang: mal jetzt so diese verschiedenen Perspektiven zu hören,

Wolfgang: wie es denn mit dem Thema technische Schulden aussieht und zwar eben in den

Wolfgang: verschiedenen Bereichen, die jetzt in der Softwareentwicklung relevant sind.

Wolfgang: Und ich muss sagen, Christian, so dein Beispiel oder deine Analogie mit den

Wolfgang: Wartungskosten oder Betriebskosten, die eben anfallen,

Wolfgang: das finde ich sehr, sehr, sehr gut und ich muss sagen, ich finde,

Wolfgang: dass das auch einfacher vermittelbar ist als vielleicht wirklich das Konzept

Wolfgang: der technischen Schuld, wenn man es mit Leuten spricht,

Wolfgang: die halt nicht so tief technisch irgendwo drinstecken.

Wolfgang: Weil ich glaube, das kann man gut verstehen, weil wenn ich mir jetzt,

Wolfgang: um noch ein weiteres Beispiel von dir zu klauen,

Wolfgang: wenn ich mir jetzt ein sehr teures, hochwertiges Auto kaufen würde und an diesen

Wolfgang: Betriebskosten spare, dann würde ja wahrscheinlich auch irgendwann,

Wolfgang: keine Ahnung, was kaputt gehen, weil ich was nicht gewartet habe oder die Bremse

Wolfgang: funktioniert nicht mehr.

Wolfgang: Weil die Bremsbeläge abgefahren sind oder so.

Wolfgang: Und mich hat es auch sehr positiv gestellt, dass ihr da auch ganz coole Strategien

Wolfgang: und Ansätze habt, wie man einfach damit umgehen kann.

Wolfgang: Und ich glaube, was uns allen klar ist, ist, es gibt kein Wundermittel,

Wolfgang: mit dem man technische Schulden ab sofort vermeiden kann, denn die sind halt

Wolfgang: einfach ein Bestandteil vom ganzen Entwicklungszyklus.

Wolfgang: Zyklus und ich finde, es ist dann halt wichtig, dass man sich dessen halt bewusst

Wolfgang: ist und je bewusster man damit umgeht, desto weniger ist das irgendwann mal

Wolfgang: ein Risiko, oder? Ja, absolut.

Wolfgang: Ja, ich habe keine Fragen mehr, was selten ist, aber wie sieht es bei euch aus?

Wolfgang: Habt ihr noch Fragen, habt ihr noch spannende Punkte, die ihr zum Besten geben wollt?

Wolfgang: Ich gehe mal die Reihe durch, damit sich niemand verstecken kann,

Wolfgang: wie damals in der Schule. Christian, wie sieht es denn bei dir aus?

Christian: Ja, weiß ich, du willst immer noch so einen letzten Satz haben oder sowas.

Wolfgang: Power-Claim, nicht weniger als einen coolen Claim oder so.

Christian: Also eine Sache, die ich gerne, wenn es um die Boring-Technology geht,

Christian: gerne nutze, wenn jemand sagt, ja, das müssen wir noch mit Fans XY machen,

Christian: dann sage ich immer, das ist natürlich ein bisschen aus euren Bereichen entliehen,

Christian: aus der Software-Technik, man kann auch mit PHP Milliardär werden. Auch heute noch.

Wolfgang: Da kenne ich mich auch noch mit aus mit PHP. Habe ich mal vor 20 Jahren gelernt.

Christian: Ich sagte Milliardär werden.

Wolfgang: Ja, Milliardär werden, da fehlt mir aktuell noch die Perspektive.

Wolfgang: Aber hey, the sky is the limit.

Christian: Nein, aber was ich damit sagen will, ist, man klammert sich,

Christian: das meine ich, so eine gewisse Technikverliebtheit haben wir natürlich alle.

Christian: Und sonst hätten wir ja auch nicht die Kompetenz, wenn man nicht so ein bisschen

Christian: das Ohr an der Schiene hätte.

Christian: Aber sich jetzt einfach nur daran zu klammern, dass etwas mit der oder der Technologie

Christian: gemacht wird, das ist nicht alles.

Christian: Also das reicht nicht. Das ist kein valides Produkt.

Christian: Das ist nicht automatisch gut oder schlecht oder ein Debt oder nicht,

Christian: nur weil es mit der Technologie gemacht ist.

Christian: Das ganze Know-how, was investiert ist in die komplexe Umsetzung des jeweiligen

Christian: Produkts oder der jeweiligen Anwendung oder Infrastruktur, die wir damit gebaut

Christian: haben, Das ist das große Investment, was man gemacht hat.

Christian: Dass die Technologie vielleicht veraltet ist und dass sie aus anderen Gründen

Christian: getauscht wird, das mag valide sein, aber dass man eben nicht sich nur beim

Christian: Technical Debt an eine bestimmte Technologie klammert und sagt,

Christian: wenn ich dieses Trigger-Wort höre, dann weiß ich ja, das ist alter Quatsch.

Christian: Oder das kann man damit viel schneller, viel neuer und überhaupt machen.

Christian: Das mag natürlich Performance und solche Dinge, das mag valide sein,

Christian: ganz klar, aber nicht so zu tun, als wenn es nur an der Psychologie hinge,

Christian: die man mal gerade von A nach B austauscht, dass das alles ist,

Christian: was der Dead ist, den man da drin hat.

Christian: Es ist mehr auch die Millionen oder Hunderttausenden Entwicklerstunden,

Christian: die da mit reingeflossen sind, die vielen Zehntausenden Menschen,

Christian: die Operations gemacht haben, die operative Erfahrungen damit haben,

Christian: Die wissen, na, wenn das passiert, dann gucken wir da hin oder hier können wir

Christian: gegensteuern, mit der Konfiguration läuft es in dem Falle am besten.

Christian: Das darf man nicht einfach so wegwischen und einfach so tun,

Christian: als wenn die Technologie der Dette wäre.

Wolfgang: Finde ich sehr stark, also würde ich auch absolut so unterschreiben.

Wolfgang: Christoph, wie sieht es denn bei dir aus?

Christoph: Ich bin in der Branche unterwegs, wo die Grundhaltung deutlich konservativer ist.

Christoph: Da wird jetzt da gibt es nicht den großen Zwang,

Christoph: immer auf das neueste Pferd zu satteln und immer den neuesten heißen Scheiß

Christoph: benutzen zu müssen, sondern da wird sehr viel mehr Wert gelegt auf Stabilität.

Christoph: Gerade weil,

Christoph: Gerade weil die Produkte, die wir bauen,

Christoph: ja nicht Software-as-a-Service sind, was ständig aktualisiert und neu ausgerollt

Christoph: wird, sondern da ist der Ins-Feld-Bring-Prozess noch ein deutlich komplizierterer.

Christoph: Deswegen findet man sich in meiner Branche eher auf dem anderen Ende der Skala

Christoph: wieder, wo man gezwungen ist,

Christoph: Technologien zu ersetzen, weil

Christoph: jetzt schon die Komponenten nicht mehr gewartet werden vom Hersteller.

Christoph: Die Grundproblematik ist natürlich dieselbe. Das ist die Frage,

Christoph: welche konkrete Schlussfolgerung ich da daraus ziehen will.

Christian: Du willst zumindest nicht überrascht werden von dem Punkt. Du solltest wissen,

Christian: dass in zwei Jahren wird uns das,

Christian: wieder begegnen, dass wieder eine Version, die wir zwar sehr gut verstanden

Christian: haben, aber dann wird es uns das Extern aufgezwungen. Dann wird Ende sein mit der Version.

Christoph: Ja, genau, das ist ein guter Punkt. Deswegen gibt es externe Zwänge,

Christoph: die eben dazu führen, dass man nicht stillstehen kann, sondern dass man weiter vorangehen muss.

Christoph: Und es gibt den schönen Spruch, wenn es weh tut, machst du es nicht häufig genug.

Christoph: Und am meisten tut es natürlich weh, wenn man etwas lange, lange,

Christoph: lange vor sich her schiebt. Und dann auf einmal alles auf einmal machen muss.

Christoph: Wenn man kontinuierlich ein bisschen mehr am Puls der Zeit bleibt und in kleineren

Christoph: Schritten seine Technologie aktualisiert, kann man es eben als Teil des normalen

Christoph: Routine-Prozesses handhaben.

Wolfgang: Ja, absolute. Also absolut. Das

Wolfgang: erinnert mich ja nicht nur an das bereits erwähnte Beispiel mit dem JBoss.

Wolfgang: Ich hatte auch mal so ein Elasticsearch-Projekt, wo man zwei,

Wolfgang: drei Versionsnummern überspringen musste dann irgendwann, weil man halt ewig

Wolfgang: keine Updates gemacht hat. Und das war auch so ein Gott.

Wolfgang: Ich mag mich gar nicht mehr daran erinnern. Da hatte sich halt alles in der API verändert.

Wolfgang: Und das ist dann halt wirklich immer sehr schmerzhaft und sehr, sehr teuer.

Wolfgang: Simon, du bist in der Wunderwelt der Daten und natürlich auch in der Wunderwelt

Wolfgang: der KI unterwegs und wir müssen jetzt noch ganz kurz über KI sprechen,

Wolfgang: weil das ist ein sehr gutes Keyword und damit wird wahrscheinlich der Podcast

Wolfgang: auch noch viel erfolgreicher, wenn wir sagen,

Wolfgang: KI-basierter Umgang mit technischen Schulden.

Wolfgang: Wie sieht es bei dir aus? Was sind so deine vielleicht letzten Gedanken zu dem Thema?

Simon: Ja, also bei KI sind wir quasi unmittelbar beim Vibe-Coding.

Simon: Das ist ja auch in aller Munde gerade. Das ist natürlich auch ein großer Produzent

Simon: von Technical Debt. Ich glaube, das wissen wir alle.

Simon: Da sind wir auf jeden Fall alle auch gespannt wo das uns noch hinführt ob wir

Simon: dann alle bald nur noch Reviewer sind oder dann die KI eine Woche lang entwickeln

Simon: lassen und dann die Technical Dead am Ende aufräumen müssen,

Simon: aber so ganz abseits der Datenwelt habe ich noch einen Gedanken,

Simon: Technical Dead ist ja auch so ein Verruf, da hat niemand Lust drauf,

Simon: das macht keinen Spaß das ist irgendwie lästig,

Simon: und von der KI zu den ganz allgemeinen Tools, also können auch KI-Tools sein, aber ich glaube,

Simon: wir tun uns einen großen Gefallen, wenn wir die Tools, die wir wählen,

Simon: um Schulden abzubauen, sei es ein Linter oder ein CodeCleanly-Analyse-Tool oder

Simon: das Tool, mit dem wir Dokumentation schreiben, vielleicht auch mit KI,

Simon: die müssen Spaß machen, weil wenn sie Spaß machen, dann machen wir die Arbeit

Simon: gerne und gut und oft und ich finde, das muss das Ziel sein.

Wolfgang: Mega. Also mega. Wenn es Spaß macht,

Wolfgang: ist es einfach viel angenehmer und du drückst dich halt nicht davor.

Wolfgang: Das ist das Gleiche, finde ich, bei der Dokumentation. Wenn du die in irgendeinem

Wolfgang: Wiki machen musst, was so mega umständlich zu bedienen ist,

Wolfgang: wo du einfach sagst, allein in den Edit-Modus zu kommen, muss ich 13 Mal klicken

Wolfgang: und dann speichert es das nicht irgendwie und die Formatierung ist kompliziert

Wolfgang: und mache ich vielleicht morgen.

Wolfgang: Ja, was die KI angeht, ich habe erst heute Morgen gelesen, dass der Chef von Softbank gesagt hat,

Wolfgang: seine Vision für die Zukunft ist, dass jede Person, die Software entwickelt

Wolfgang: in der Firma, ersetzt wird durch 1000 KI-Agenten und die machen dann alles.

Wolfgang: Also er hat so ausgerechnet mit einer geheimen Formel auf eine Entwicklerin

Wolfgang: oder einen Entwickler kommen 1000 KI-Agenten und die entwickeln und reviewen

Wolfgang: und machen das dann alles richtig gut und dadurch sparst du viel Geld,

Wolfgang: weil die Stromkosten dafür, die belaufen sich wohl auf 220 Dollar im Monat und

Wolfgang: das durchschnittliche Entwickler, Entwicklerinnengehalt,

Wolfgang: das liegt ja bei deutlich mehr als 220 Dollar.

Wolfgang: Also insofern, vielleicht erledigt sich das ganze Thema ja auch automagisch in der Zukunft.

Christian: Ich sehe schon, wir sind alle biological dead hier, wenn du diese Zukunftsdystropie da prophezeist.

Wolfgang: Also wenn ich mir für 220 Dollar 1000 Agents kaufen kann, die meine ganze Arbeit

Wolfgang: machen und die Qualität gut ist, also das kann ich mir, glaube ich, leisten.

Wolfgang: Ich fahre kein Auto, das heißt, ich spare da schon die Betriebskosten,

Wolfgang: die könnte ich dann für meine 1000 Agents investieren und dann machen die halt Podcasts.

Wolfgang: Freunde, es hat mir super viel Spaß gemacht. Vielen Dank natürlich für eure

Wolfgang: Zeit und für eure tollen Gedanken, die ihr hier geteilt habt.

Wolfgang: Aber auch nochmal ganz großes Danke an euch und an den Kollegen Sebastian Schmidt

Wolfgang: fürs Einfädeln von diesem Thema.

Wolfgang: Ich finde es ein sehr wichtiges Thema,

Wolfgang: weil ich weiß gar nicht mehr, wer es jetzt im Detail gesagt hat,

Wolfgang: aber dem Begriff technische Schulden, das Englische kann ich nicht so gut aussprechen,

Wolfgang: dem haftet halt so etwas Negatives an und ich glaube, wir haben ganz gut herausgearbeitet,

Wolfgang: dass es das halt gar nicht ist und wenn man versucht, das zu vermeiden,

Wolfgang: dann wird es halt zum Problem und wenn man es akzeptiert als Teil vom ganzen

Wolfgang: Prozess, dann ist es eine Chance.

Wolfgang: Vielen Dank und ich hoffe, dass wir uns in der Zukunft irgendwann mal wiederhören.

Wolfgang: Also hier im Podcast und sonst natürlich auch gern in echt.

Simon: Vielen Dank, es hat sehr viel Spaß gemacht.

Christian: Ja, besten Dank. Tschüss.

Christoph: Ciao.

Wolfgang: Das war das Gespräch mit Christian, Simon und Christoph.

Wolfgang: Ich hoffe, es hat euch Spaß gemacht. Wenn ihr Feedback habt,

Wolfgang: dann erreicht ihr mich per E-Mail unter podcast at inovex.de.

Wolfgang: Wir hören uns in der nächsten Folge wieder und bis dahin wünsche ich euch viel Spaß und eine gute Zeit.