Tools und Prozesse in der Softwareentwicklung: Von Versionierung bis Refactoring #10

Ja, Moin ihr Lieben hier sind wieder Gerrit und Burkhard aus Hamburg zum Podcast. Gerrit, wie siehts aus? Ich weiß natürlich, was los ist, aber ich glaube, ich kann nicht erzählen. Wie sind die Hörer verwirrt? Also ich geb dir das Wort mal gucken wieviel wird am Ende die Zuhörenden sind also lass uns heute sprechen über das Software Ökosystem und den Software Lebenszyklus.

Was gehört alles dazu? Wir hatten ja mal das Thema Software und 100 genau und sehr, sehr technisch, teilweise sogar theoretisch und heute mal ganz praktisch. Was werden für Tools benutzt, was gibt es für Prozesse? In der Softwareentwicklung ne also angefangen von Planung, über Entwicklungen, über das Testen, das Deployen, das Hosten von Software und natürlich auch die Pflege und Wartung das ist unser Thema, das ist ein riesiges Thema.

Ich glaube, da würden andere wahrscheinlich irgendwie ein Buch drüber schreiben, aber wir versuchen das mal in der Kürze der Zeit. Wir können alles gleich n bisschen, aber das reicht vielleicht auch.

Genau das ist die Idee, dass man einfach als Zuhörer Zuhörerinnen ein Gefühl dafür bekommt, was alles dazu gehört und wo auch Stolpersteine. Sind ja ja OK alles klar soll ich mal anfangen oder total gerne ja ja, wir haben genau 10 haben wir gesagt und schreiben von Software und so weiter, aber bevor man überhaupt das erste Stück Funktionen Code irgendwas schreibt, glaube ich kommt noch kommt schon ein riesiges Kapitel vor ja. Das ist zum Beispiel, glaube ich

1 von den. Hab ich früher auch gemacht, ne wenn nur Entwickler ist dann natürlich Spaß dran und irgendwie schnell was programmieren weil dann sieht man ja auch was und so weiter und fühlt sich so an, als käme

man schnell voran. Aber ich glaube wenn man früh anfängt einfach los zu entwickeln, dann dann wird das einfach nicht gut, ja also so ne Software ist halt klar wenn du kleines schreibst du irgendwas kannst du dann hast du das irgendwie im Kopf so und dann schreibst du das hin und dann ist das fertig. Aber wenn wenn das Ding n bisschen größer ist, dann software ich ich mach gerne so ein Vergleich mit. Das klingt ein bisschen

philosophisch. Aber ich finde eine sehr große Software, die sehr gut geschrieben ist. Am Ende des Tages und gut funktioniert wie eine Symphonie den Komponist komponiert hat. Also da gibt es brauchst Themen du brauchst roten Faden, du brauchst verschiedene Aspekte und so weiter und ja, der die das sind quasi die Noten, aber ich glaube so Komponist, wenn einfach schreibt irgendwelchen Hingeklatscht so, dann klingt das halt auch wenig.

Ja also man braucht schon ein Konzept, einen Plan und es braucht eine gewisse Eleganz irgendwie in diesem ganzen Ding so das macht es glaube ich ja. Ich sag ja philosophische Last, aber also für mich ist das ein bisschen so ja klar und also es fängt an mit der Planung und da scheiden sich die Geister und ich glaube, da gibt es keinen, also das macht jeder anders. Ich bin ein Mensch der. Ich versuche, mir vorzustellen wie sieht das finale Produkt aus?

Und wenn es nicht gerade irgendwas ist, was nur im Hintergrund arbeitet, als mittelbare oder irgendwas, wo man nichts visuelles hat, dann dann versuche ich mir also, wenn es grafisch ist, dann versuche ich mir vorzustellen wie könnte die finale Anwendung aussehen und wie? Ich müsste die bedienbar sein was würde ich als Nutzer, wenn ich klicke und und und Dragon Drop und so weiter erwarten wollte? Story in?

Ja, so ich genau, das kann man auch sehr, sehr chemisch betreiben dieses also, da gibt es richtig viele Prozesse, also User Stories aufschreiben lastenheften formulieren genau alles ausarbeiten und so weiter. Da bin ich auch nicht der Typ.

Aber ich glaube, es ist total gesund, sich mal so auf dem und ich bin auch nicht der Typ, der es gibt, dann wieder Software Tools, die machen, so Mock UPS, wo man quasi dann irgendwie schon so hin mocken kann so n bisschen powerpoint mäßig ne wie das alles aussehen würde mach ich auch nicht, dass mir dann auch zu fusselig irgendwie aber ich nehme schon NA 4 Seite und im Bleistift. So wie vielleicht die Architekten ganz früher das gemacht haben, so ne ganz grobe

Linie, und dann versuche ich zu verstehen welche Komponenten habe ich und so weiter und fokussiere mich drauf und denke es aber ich denke Software immer vom Ende her, also von der Nutzbarkeit und dann versuche ich quasi rückwärts zu denken was muss man dafür alles bauen, ne? Und tatsächlich das ist glaube ich, die größte Herausforderung

für tatsächlich. Für Softwareentwickler ist, sich zurückzunehmen und zu sagen OK, ich sitze halt vielleicht ein 234 Tage oder sowas mach gar nix ich denke nur nach mach mir paar Notizen irgendwie will Sammlung. Recherchiere ganz viel wir hatten jetzt ne Folge schon über über Open Source und so weiter recherchiere, weil ich vielleicht gar nicht weiß wie kann ich was realisieren, mit welchen Tools, was gibt es da

schon? Gucke mir an, welche Open Source Komponenten kann ich vielleicht reinziehen? Wie funktionieren die, was bräuchte ich dann noch als Schnittstelle, als Glycose quasi um das mit einer anderen und so weiter zusammenzubasteln macht also einen groben Plan erstmal?

Da muss man sich zusammenreißen, dass man hat n schlechtes Gefühl, sag ich mal ne also als Softwareentwickler ist man n auf Drogen, sag ich mal ja, wenn du wenn du Software schreibst, dann hast du sofort ein Ergebnis, das ist total befriedigend, du schreibst was du siehst es du kannst es klicken kannst es nutzen oder was machst du irgendwas?

Ja, das ist sehr befriedigend. Und wenn du als Software gar nur 3 Tage nachdenkst, hast ich auf deinem Schreibtisch nur du hast deine Gedanken im Kopf und ein paar Zettel lose liegen dann ist das ziemlich unbefriedigend. Erstmal so in das ist auch glaube ich gerade für jüngere Softwareentwickler. N Problem ja, aber man muss sich.

Und man muss dann quasi auch als Teamleiter irgendwie das ganze Team zusammenhalten, sagen OK, wir müssen doch schon erstmal Design und planen, deswegen gibt es auch die Architekten den Bau, ja also dann einfach hergehen und ich schon mit den Steinen zumauern und sagt Oh, das wird schon passen beim beim Bau so mache ich das so, wie ich es irgendwie will.

Ich glaube, das wird nichts oder Software nicht da hab ich jede Menge Sachen zu kommentieren ich jetzt auslassen kann erstmal bestätigen, dass du so vorgeht und weiß ich nicht 3 Viertel der Zeit planst und dann oftmals in wirklich kürzester Zeit da n. Ergebnissen nutzbares Ergebnis was ich dann sogar als Anwender schon benutzen kann Hinzauberst das ist wirklich Wahnsinn wäre ich gar nicht der Typ für ich muss immer sofort irgendwas kann

ich irgendwann fang ich halt an. Ich sage auch nicht, dass ich dafür bin. Ich muss mich zusammenreißen, das ist wirklich Willenskraft. Willenskraft der Macht das auch keinen. Also Spaß macht schon immer Spaß, aber das ist also macht schon mehr Spaß?

Irgendwie ist dann zu machen und direkt zu sehen ja genau und dann hast du jetzt gerade, du sprichst von Bau und Architekten, aber es gibt ja auch Architekten ja, genau die Arbeit eines Software ja genau, wenn ich glaube, wenn man richtig krass auf die Spitze treibt, dann ist ein Software Architekt, der muss gar nicht grün können, es gibt sogar krasser Weise informatikstudiengängen, das weiß ich, wo du nicht beigebracht bekommst, wie man Code schreibt oder Code entwirft.

Du lernst nochmal Programmiersprache oder irgendwas also nur abstrakt. Konzepte ja klar objektorientierung und so weiter.

Die Konzepte der Software alles im Detail und Netzwerktechnik und den ganzen Kram, Laufzeit, Abschätzung sehr theoretisches Studium. Das versetzt sich in die Lage, genau das zu tun, also sehr abstrakt über über eine große Software nachzudenken und das ist wirklich also große Software ist wirklich ne, also hat richtig viel Quellcode und die Sachen müssen gut ineinander Haken und arbeiten. Das halte ich aber auch für komplett falsch.

Ja, weil das ist am Leben vorbei, das ist ja das ist halt so der akademische Elfenbeinturm wenn du, wenn du so arbeitest weil. Ich glaube, auch der beste Architekt ist jemand, der auch nicht nur ganz akademisch vom Studium her weiß, wie man es zu machen hätte. Denn wenn du nämlich nicht weißt, welches sind die aktuellen Materialien, was gibt es für tolle Möglichkeiten, Fenster irgendwo einzubauen oder fassadenverkleidungen oder vom Material her und von der Verarbeitung her und so weiter?

Wenn die Prozesse nicht kennst, dann kannst du auch nicht.

Dann kannst du dann bist du nicht dabei, einen Zeitplan zu machen, dann kannst du nicht abschätzen also ich glaube, man muss auch schon von dem Handwerk, wenn man vergleicht das Handwerk ist das Coden ja mit verschiedenen Programmiersprachen, man muss sein Handwerk auch können als Architekt oder wissen zeitgemäß solardach heutzutage oder ne Wärmepumpe ja genau weil die Architektur muss ja mit einfließen hat gesagt die Technologien ja du findest du

schreibst ja nicht von Scratch, sondern du musst wissen was gibt es und was was führt mich da schneller zum Ziel? Wenn du das nicht weißt, dass das Handwerk Teil des Handwerks

das nicht weißt? Ist auch nicht richtig so, weil es stimmt schon der Architekt ist mehr Designer, der muss auch nicht selber machen, aber er sollte wissen, was er tut ja OK, das war die Planung haben wir doch jetzt bisschen länger gesprochen und irgendwann geht's hoffentlich auch mal in die Entwicklung. Genau die Entwicklung geht ja was brauchst dafür also wir haben schon mal über Entwicklungsumgebung hab ich gesagt, dann angriff sowie

Visual Studio Code ja genau das ist ja e also es genau das Integrated Development environment. Das ist ein bisschen so wie gehabt, was wir auch in der Open Source schon mal haben, ja, vielleicht ein bisschen, jetzt kommts jetzt kommts ziemlich stark drauf an. Wer geht in die Ausführung? Wie viele gehen in die Ausführungen? Das ist vielleicht der wichtigste Punkt. So ja also es macht einen riesen Unterschied, ob du jetzt nach der Planung irgendwie sagst.

K 120 Köpfiges Entwicklungsteam setzt das jetzt um oder wir 2? Und zwar aus mehreren Gründen du musst ja erst mal deine Planungen also wenn du die nicht gerade irgendwie einen tollen powerpoint s fertig hast wo. Wo sich da ein mentales, abstraktes Bild, das du in deinem Gehirn angesammelt hast, als Planung quasi widerspiegelt und erklärbar wird für den

nächsten das ausführen soll. Dann musst du ja irgendwie den Erklärbär machen du musst irgendwie den Umsetzer so ein bisschen was von deiner Perspektive mindestens den Teil der jetzt gerade dran ist, mal irgendwie erklären können und so weiter ja, das ist natürlich bei Windows 20 Leuten erklären wir ne andere Nummer als wenn du irgendwie 2 Leuten erklären willst, so ja, genau das ist das eine und dann kommt noch bei der Umsetzung drauf an also wir haben mehrere Komponenten.

Wir müssen ja erstmal. Wir müssen ja schreiben in einem Editor, ja also früher hat man tatsächlich gab es eigentlich IO Max. Entweder war die mein alter Chefarzt I Typ. Da gab es halt, das war so krass ist so, Linux ist richtig, Nerd mäßig so ja, das war quasi ein Notrad für Entwickler, ja aber auch nicht viel besser also es war eigentlich nur ein n besserer Texteditor und die hatten ganz viele Shortcuts auf dem auf dem Keyboard so ja, also eigentlich. Das ging nur deswegen schnell.

Du musst halt tausende 1000 n Schrott auswendig können und dann machst du das Ding, kannst markieren, einfügen und dass ich alles und entweder hast du halt die I schaut Katze im Kopf gehabt oder die von Emails, die man anders so ja und wehe man musste wie bedienen da völlig aufgeschmissen. Umgekehrt heute haben wir noch viel krassere Editoren, also die nennt sich d Integrated Development, weil die eigentlich der nicht nur erlauben, den Text zu schreiben, sondern die sind

halt voll integriert, das heißt. Du kriegst dann die Dokumentation, wenn es irgendeine Open Source Komponente ist, dann noch eingeblendet ist, das macht er automatisch einen Syntaxcheck, das formatierte, das auf einen Knopfdruck formatiert ihr das ganze Dokumente in bestimmten Art und Weise und so weiter das nimmt dir extrem viel Arbeit ab, dass du du siehst wie Sprache. Du musst schon, aber es wird ja

echt. Ganz viel Arbeit abgenommen so, und das hat dann jeder Entwickler unter der Hand und ich ja genau, ich mache Werbung für Microsoft Visual Studio Code das ist ne freie Entwicklungsumgebung ist mega mächtig so ich hab lange herumexperimentiert und jetzt bin ich schon seit sehr vielen Jahren.

Bei diesen Dingen ist echt cool da aber genau kann man mal gehört haben wieder vergessen so und dann und dann ist das hab ich schon mal gesagt, dann ist es ja so wenn wir jetzt über die Symphonie denken, dann ist aber nicht nur Mozart, ja der Sinn komponiert, sondern wir haben jetzt einmal ganz also der hat sich ausgedacht und jetzt gibt es viele. Ausführen, die das Schreiben müssen und jetzt fangen?

Jetzt müssen die, aber es ist schon so, dass es halt ein Stück Symphonie Noten, die müssen jetzt von mehreren

aufgeschrieben werden. An der richtigen Stelle und so weiter. Das ist ein riesen Koordinationsaufwand ja und oft ist nicht perfekt im ersten Mal da muss nochmal bearbeitet werden und so weiter, dann passiert es mal, dass 23 Mitarbeiter an der gleichen Stelle irgendwas rum editieren. Ja, da kriegst du dann Konflikte in dem Dokument und so weiter und da gibt es genau da gibt es jetzt sionssysteme ist ganz wichtig. Das muss man kennen. Also g ist da heute.

Das das Standard Ding früher hieß es VN und davor CVS. Das sind Managementsysteme, die die managen für viele für viele Leute zusammen das Erstellen einer Codebasis ja und und regeln alle diese Konflikte, da passieren dass Emerging das zusammenführen und so weiter, weil du am Ende wie Du schreibst nur einen ein Buch mit vielen Leuten, also ganz konkret, wenn 2 Personen in einer gleichen Zeile Code editieren, dann gibt es da einen automatischen. Wie geht das denn, der wieder in

ja genau? Das gibt es tatsächlich, dann gibt es keinen automatischen Weg, das ist die einzige Sache. Es gibt ganz viele Automatismen, aber wenn tatsächlich 2 unabhängig 2 verschiedene Versionen der gleichen Stelle Code gemacht haben, dann auch das dann auch die Automatisierung nicht mehr wissen was ist richtig?

Dann muss man sogenanntes Konflikt kriegt man Konflikt mal angezeigt, dann kriegt man angezeigt hier sagen wir mal, ich hätte mir gedacht der Gerrit hat diese Teile so geändert und ne, das kommt jetzt vom Server rein bei dir und du hast die so geändert was sollen wir denn jetzt nehmen? Ja, dann muss man diesen Konflikt. Immer Reserven, sagt man so ja, dann muss man leider auch als Softwareentwickler kommunizieren.

Wird nach persönlicher ist Scheiße, ja, das Konfliktmanagement ist da also auf dem Code ist da aber die sind die Idee ist ja die sind die s und in denen ist quasi dieses früher war alles repariert. Aber ist genau das alles mit eingebaut. Schon da ist dann geht es mit drin genau genau du siehst auch sofort wenn du wenn du ein Stück hast und ihn zu editieren macht das farbig ne was hast du geändert? Was ist alles total transparent? Da geht es jetzt nicht.

Lab Nee geht es geht es quasi, die geht ein kleines Stück Code ist tatsächlich Onlineshop vom. Ich glaube, vom Linus Torvalds geschrieben. Der Autor von von Linux hat er also ich glaube, die Anekdote ist, dass mehr oder weniger am Nachmittag zusammengepackt hat und jetzt die ganze Welt immer noch seit Jahren benutzt. Das auch G Lab ist quasi ist noch mehr drumherum, da hast du quasi eine Weboberfläche, wo du dann auch Reviews machen kannst und so weiter.

Dann kommen wir noch zu, wenn Du ein großes Team hast, dann hast du noch mehr Prozesse als nur n bisschen Konfliktmanagement hast du quasi Junior Entwickler und Senior Entwickler und so weiter und bevor dann irgendwie ein Stück Code von einem Juniorentwickler in den. Man sagt Master Branches meistens, gibt verschiedene Modelle, gibt meistens quasi in Hauptentwicklung Branch quasi immer die aktuellste Version.

Das muss nicht dierelease.de, also die dem Kunden zugespielt aktuellste Version sein, aber die aktuellste Version Entwicklungsstand quasi aufgebaut wird, bevor da was reinfließen kann, muss auch mal ein Stück Software, vielleicht auch auf Qualität geprüft werden. Ja, wenn Junior ist ganz normal ja auch selbst wenn er sich anstrengt genau ist doch egal ob es ist auch egal ja, aber genau. Aber es muss natürlich einen Review.

Ach ja, das machen natürlich typischerweise die Seniorinnen Entwickler, um zu gucken hierarchisch da gibt es nicht einfach n sag ich mal 4 Augen Prinzip unabhängig von gibt es bestimmt auch total je nach je nach Firma, ne aber ich würde also in meiner Firma aber immer so, dass die, die die erfahrensten Entwickler die Reviews machen, weil Erfahrung also ich will überhaupt keinen sprechen können alle ganz intelligent sein und du kannst ja auch als Junior Entwickler

total intelligent sein. Intelligenz schützt dich aber nicht vor schlechtem Code. Nur Erfahrung ist ne ganz krasse Meinung, also ist hilft nur Erfahrung, Erfahrung, Erfahrung du musst ganz viel gesehen haben, ganz viele Fettnäpfchen abgetreten haben. Und nur dann kommst du soweit, dass du Sachen siehst im Code, die später kaputt gehen, ne weil man muss sich ja, wenn man so Code liest, man muss sich ja quasi schon also bei mir fühlt sich immer das Programm quasi

schon im Kopf aus, was dann so passiert ja und ich glaube man kann nur mit Erfahrung irgendwie die ganzen Seiteneffekte mitbedenken. Das hat man als Junior einfach nicht drauf. Ich glaube, das ist Intelligenz. Quotienten unabhängig ja sind wir denn jetzt schon im Test des kommt jetzt sind wir noch ne ja jein eigentlich schon, weil so ne man schreibt quasi ja, wenn man Code schreibt.

Schreibt natürlich der irgendwie finale Anwendungen widerspiegelt und dann schreibt nochmal genauso viel Code den Code. Die finale Anwendungen widerspiegelt. Testet also man testet Software mit Software. Man hofft darauf, dass die Frameworks und frei sind, sie

auch. Und genau das ist relativ viel Aufwand und typischerweise ist es so und so haben wir es auch gehandhabt in allen Firmen. Ich war, wo wir mehr als ein Entwickler waren, man ist angehalten, zu jedem Feature zurück, dass neu schreibt auch n Test. Zu schreiben, der das testet, was man gerade geschrieben hat ja. So und zum Testen können wir nochmal Eigenkapital machen, da gibts halt verschiedene Ebenen, auf denen ich abstraktionsebenen ich testen kann.

Das kleinste Level ist Unit Testing müssen wir gehört haben und dann gibt es die Integration Testing und n Testing und so weiter. Man kann sich quasi. Ja, du kannst dir vorstellen und testen dann schreibst du halt eine Funktion hin und dann überprüft Unit Test wenn ich da was eingebe ob das rauskommt? Was also testet eine Funktion erwartest du ja das kleinste atomische Level ich testen kann

ne? Sehr aufwendig und es entsteht wieder sehr viel Code Test Code. Ja, also ich bin gar nicht so ein Freund von und dann kannst du leben. Kannst du Komponenten testen, dann sagst du zum Beispiel wenn I hab ne Web API oder irgendwas nicht knallt das Ding da rein dann erwarte ich, dass da rauskommt ne w ist glaube ich und was das ist ich aber vielleicht irgendwer erklären oder ein anderes Beispiel ja also was ist eine typische

Komponente? Also wir haben ja die Folge schon über Microservices gehabt, ne Komponenten typischerweise in Microservices heutzutage gepackt und eine Microservice. Hat immer eine standardisierte Schnittstelle nach außen, ne und im Container drin sind ganz viele Funktionen, ne? Die könnten die Tests abdecken, die ganzen Funktionen drinne, so aber jetzt kann der Container an sich dann ja auch quasi ein Label dran machen und sagen wenn ich da das Reingebe sollte.

Nach Durchlaufen von x Funktionen, das wieder rauskommen, ja und das kann ich auch testen ja, ich nicht n Loch im Schlauch ist, sondern das Fahrrad rollt n bisschen ja, genau das ist vielleicht ein gutes Beispiel ja, genau du guckst beim Fahrrad quasi. Jede Schraube an, sondern erst einmal um Block und wenn das Ding sich irgendwie stabil anfühlt und ordentlich gefahren ist, dann weißt du impliziert, dass auch die Schrauben fest waren.

So deswegen finde ich eigentlich wertvoller die Tests auf einer höheren Abstraktionsebene zu schieben, weil du implizit vieles mit testet. Das ist irgendwie irgendwann nicht mehr ganz richtig, weil du ne. Ne kombinatorische Explosion von allen Möglichkeiten hast die du nicht von oben alles testen kannst am Ende hast du ja auch nicht also am Ende hast du auch bestimmte Anwendungsfälle, die

du für deine Software vorsieht. Für den Kunden und wenn du die gut durch Test, dann hast du schon viel geschafft so. Ja, genau genau und das testen die User sich anders verhalten als man dachte ja genau, das ist ja das ist ja der meiste Grund warum du hast also was wieso machst, warum klickt ihr denn da hin? So ja Ach, das geht auch so verdammt, da bin ich Kandidat ja genau.

Man braucht dann so die die ja OK gut, aber das testen wird mit also das ist halt auch alles integriert, also in diese es und in diese ganzen Plattformen und so weiter das das kannst du alles aufschreiben, das läuft dann automatisch repariert man dann irgendwie als Testcode gehabt den eigentlichen ja auf jeden Fall. 6 deklariert man auch ganz anderer Art und Weise, ist auch getrennt von dem von dem von dem Anwendungsquote darf auch zum Schluss nicht mehr ausgeliefert werden.

Der würde ja das alles langsamer machen und auch einfach dicker. Das ganze Paket, das muss alles raus dann, so ist dann alles organisieren und planen übrigens gar nicht so einfach. Da diese Tests auch die Tests zu schreiben und zu planen, also kompliziert der gute Test zu schreiben ist nicht einfach. Da gibt es eigene Stellen rollen, die sich nur ums Testen kümmern, ja, genau sagen Qualitätsmanagement ja, es ist also ein Software Projekt ist am Ende.

N ein komplexes Projekt so und da gibt es alles, was im normalen Leben auch gibt, so Planung, Ausführungen, Qualitätssicherung und dann kommen wir zum Ausrollen. Vielleicht können wir jetzt auch schon mal ansprechen.

Oft ist das oft versucht man uns heute zu integrieren, sich Continuous Integration und Continuous Deployment CICD also man versucht quasi hinzukommen, dass man sagt wenn ich den ich habe ja gesagt es gibt n Master Master Branch also quasi so ne Art. Den aktuellen Entwicklungen aktuellen Entwicklungsstand genau und wenn ich, wenn ich jetzt alles gut designt habe, das quasi die Software, die reinkommt, schon voll durchgetestet ist und jedes Mal,

wenn wenn sich dieser dieser neuesten Entwicklungsstand ändert, dass der quasi das passiert heute, der stößt quasi automatisch anders machen muss, stößt er quasi nochmal das testen an meistens gar nicht mehr auf meinem persönlichen Rechnern alles in der Cloud. Da wird quasi der, der der Code von dem Master stand, einfach reingezogen in eine Testumgebung

wird ausgeführt. Ja. Rechner oft meistens gibt es sogar so weit geht, wenn Open Source Projekt hast, kriegst du alles umsonst, dann riesige Software zur Verfügung, die einen durch und wenn das noch so aufwendig ist. Scheißegal ja Ach, das war das, was du in der Folge erwähnt hattest, dass wenn du deine Software unter Open Source Lizenz veröffentlicht, kriegst

du diese genau das. Denn zum Beispiel wenn du hast ja genau das ist super ja, das ist alles super organisiert und das das läuft alles von alleine durch und dann kannst du sogar so weit gehen, dass du sagst OK dann nicht weiß, dass der Code gut getestet und es funktioniert nicht. Bin ich auf meine Tests verlassen? Kannst ja auch schon könntest du schon ausrollen zum User das passiert halt auch und dann das CD Continuous Deployment und dann quasi und besaß ist besonders spannend.

Da kannst du quasi sofort wird interne Versionsnummer hochgezogen machst du auch nicht mehr haha und sofort die nächste Version zur Verfügung wird getagt wird vorbereitet, kannst du runterladen vom Server oder ist halt quasi schon online und wenn das nächste Mal wenn der wenn der Nutzer irgendwie die App aktualisiert ist schon ne, dann musst du dich überhaupt nicht mehr ums Deployment kümmern. Was heißt aktualisiert einfach auf Macht?

In dem Fall aufmacht ja aber das hat natürlich ganz viel zu tun, das kann nicht jeder Anwendung machen. Es kommt drauf an was will der und so weiter? Aber theoretisch versucht man quasi also von der Software Seite her sich das alles durch zu automatisieren. Das geht halt aber auch noch nicht so lange, weil es.

Alles dies sind, so Enabler Technologien durch diese ganze Cloud Software als Service Docker containerisierung Sachen sind auch quasi diese ganzen Tool links drum herum, um das um dieses Projekt Software zu entwickeln, so viel besser geworden, dass man das Halt leisten kann, ne früher Grüße Anekdote früher kam in einer anderen Firma kam immer die Entwickler und oft müssen die Juniors da dran ist n bisschen Abi, aber die müssen halt, weil Deployment das ist halt

irgendwie so. Das ist richtig Arbeit so wenn man das nicht gut vorbereitet hat, dann muss hier noch per Hand und da getestet und geguckt ist ja und dann mal einen Junior Developer hat immer so. Irgendwie zu Hause und dann, wenn es halt irgendwie Last Day war, dann mit dem Baum schon morgens an, dann dürfte man nicht ansprechen, aber den ganzen Tag haben Release so ja, ich muss da hart werkeln, ne und wenn er 2 Tage den Helm auf hatte, da wusste, dass irgendwas

gar nicht gut gelaufen ist so ja und das ist immer. Für einen Softwareentwickler ist, dass der Stress überhaupt so, ja also neues Release rauszubringen, so und dann hoffen und beten und dann irgendwann verpackt und fertig und ausgeliefert so und dann ist der Drops gelutscht, so wenn

etwas falsch ist, dann. Ja, das ist halt Mist, dann ist schon beim Kunden, dann kannst höchstens noch ein Release machen, das wixen und so aber dann siehst du natürlich wieder als Softwarefirma so ja, die haben grad rausgebracht und irgendwann später gibt es schon 301 den ersten Bugfix ja, aber das ist doch nicht geschafft habe so ja, aber so ist es halt ja und das das löst aber das Problem löst sich, wenn du n bisschen besser strukturiert und quasi diese Continuous Delivery

Continuous. Ich weiß nicht was nicht deployment aber bist du noch im wenn du das halt aufbaust, so ja, dann ist ja auch der Stress bei den Softwareentwicklern weg also. Wenn es eigentlich Zeit wissen cool, das läuft alles so ja, wir haben ja keine ja gerade in dem Fall, sondern eigentlich n Kreislauf durch die durch das CICDS passiert, laufen der, dass die Code oder der Text geändert wird. Und wie genau aussieht, laufen genau und man muss, das muss man einmal verstehen.

Vielleicht auch zuhören. Also Software ist halt irgendwie fertig. Ja, das ist zwar ein Aufreger für alle, für alle, die Software benutzen die sagen ja verdammt, jetzt muss ich schon wieder und so weiter einspielen. Es ist aber. Es ist aber einfach Fakt der Dinge, dass ich ja um mich herum ändert, sich ja ständig alles ja, ich glaub neue Hardware ich hab ne auf einmal gibt es

Smartwatches und so weiter. Ich habe ständig neue Anforderungen an den Code, alle alle Bibliotheken um mich rum die ich benutze, ändern sich ja auch das heißt, ich muss ständig

eigentlich meinen Code pflegen. Das heißt dieser Kreislauf ist genau das Richtige, ja, weil eine sagen es kann ja schon mal sein, dass du so ne Art Feature Freeze hast also du sagst jetzt mal neue Funktionalität kommt jetzt nicht dazu. Wir sorgen nur dafür, dass die bestehende Funktionalität weiter und dann hast du schon genug zu tun, ne? Ja, das ist doch erstmal alleine das ist schon Kreisverwaltung, dann ne ja genau das ist die Maintainance.

Und je größer deine Codebases, also je größer deine dein Produkt ist, desto mehr hast du quasi schon an diesen an diesem Grundrauschen zu tun, ne und das kann richtig substanziell sein, ne nur ne Software am Leben zu erhalten mit Feature Freeze was du gesagt hast, also keine passiert gar nichts mehr.

Ich muss nur funktionieren, also du siehst es nicht, aber der Firma die Software zur Verfügung stehen riesige Kosten nur für diese Maintainance. Das ist ein gewaltiger Aufwand, das ist völlig unsichtbar für den Nutzer.

Auch das ist glaube ich auch unsichtbar, so im im im Wissen so ne von unseren Zuhörern. Deswegen will ich nochmal sagen und deswegen ist es auch richtig und wichtig, dass gute Software, die gut gepflegt ist und von der man erwartet dass sie funktioniert, zu jedem Tag, dass sie auch ein bisschen was kostet, ja, weil die weil da entstehen halt auch ganz viele Kosten so. Das muss, irgendjemand muss ja irgendwann mal bezahlt werden, ne?

Genau also, das ist schon was macht man da konkret, wenn man eine Software flegt? Ist das auch ne Rolle, die jetzt wieder bestimmte Softwareentwickler und einfachen oder ist das etwas? Was übernimmt man für ein bestimmtes Projekt für immer die Verantwortung oder ist man immer die Person, die ja Features weiter pflegt oder so?

Also gibt Einteilung, der ich glaube, dass sie das irgendwie am Fließband auch ist, ne gibt es verschiedene Firmen, man hat glaube ich auch schon vieles ausprobiert und alles ausprobiert, ja also, es gibt ja auch ich glaube, w arbeitest, dann gibt es auch das Modell macht der eine Mitarbeiter immer nur diese eine Schraube an der Stelle rein so und kann dann total gut und FF ja also das hat viele Vorteile ja.

Oder und das andere Modell wäre so, dass die Mitarbeiter rotieren es nicht mehr, weil du nämlich, weil du nämlich in der Birne wird, immer das gleiche machst und dann bist du

irgendwie so ne irgendwie. Es hat nämlich Vorteile hat die Nachteile bei der Software ist genauso ja also es gibt, ich würde sagen in einem Team und wir hatten diese Folge mit agilem Entwicklungen. Deswegen macht man das auch gerne so agil entweder Kanban oder Sprint ist ja auch egal, aber ich hab ja diese Arbeitspakete und maintainance Qualitätsmanagement Test schreiben Feature entwickeln

Bugfixes und so weiter. Das sind ja alles einfach Tickets so ja, die sind erstmal gleichwertig und werde sich schnappt. Das steht auf einem anderen Blatt Papier und wenn man agil macht, dann kann sich immer jemand mal was Neues schnappen, ja und wenn man Lust hat, als Softwareentwickler auch mal über den Tellerrand zu gucken man hat halt irgendwie immer geschrieben und will mature entwickeln. Damit spricht man das im Team und nimmt sich halt so featuring raus. So ja.

Und so funktioniert es, glaube ich, in vielen Firmen, und das ist eigentlich eine gesunde Eigenschaften, will auch die Entwickler auch gerade die Union. Die wollen auch ein bisschen mehr sehen wollen, natürlich ihre Arbeiten bisschen weiterentwickeln, persönlich auch richtig so. Gut, dann ist es bis dahin eigentlich n Kreislauf. Wobei ne Planung muss ich anfangen, wenn ich eine Software ganz neue Form Scratch mache

wahrscheinlich ein bisschen mehr machen und dann und dann vielleicht noch genau genau mach dann noch ne und neue Version und der Rest ist dann ein gewisser Kreislauf, also die Entwicklung, das testen, was unter Umständen komplett parallel läuft und dann gibt es noch einen Punkt kann natürlich, der brennt mir auf dem Herzen sofort loswerden und vergesse es dann auch noch OK cool das sogenannte Refactoring.

Das ist die, das ist der, das ist das macht den Chefs allen weiße Haare und die, die richtig sauer, wenn man das Wort refactoring sagt ja, ich finde, es ist so wichtig und muss in jedes in jedem Zeit und Budgetplan von einem Softwareprojekt sofort von Anfang an mit eingeplant werden und ich würde sagen, mindestens 20% da. Weil wir sind ja nicht die Mozarts und Beethovens ja die der Mozart hat sich ja, der hatte dann irgendwie seine.

Sein sein so nett oder seine Symphonie da im Kopf und hat die quasi in Reinschrift einmal hingeklatscht, aber das quasi fertig, ja also ich kann das nicht also auch nicht im Code also und das heißt selbst wenn man sich noch so viel Mühe gegeben hat ist zu planen, wenn das Projekt nur groß genug ist, wird man sehen irgendwann verflixte Kiste hier haben wir echt noch das Mist so, das haben wir schlecht geplant hieß das Design. Die Ausführung ist OK, laut Plan

aber das Design hier das krankt hier noch hier müssen das Misste man erkennt das halt oft, wenn man es erst erstmal hingebaut hatte und dann muss man find ich die Zeit und die Muße haben und auch das Geld zur Verfügung gestellt bekommen von ganz oben Management, das man dann. Das nochmal intern umbaute, ja so, als würde ich den Motor nochmal ein bisschen neu strukturieren, ja und das schlimme ist man sieht nichts ja

von außen also. Fixed WLAN n Bug noch gibt es ein neues Features völlig unsichtbares verbrennt einfach nach außen verbrennt einfach nur Zeit und Geld, so ja und deswegen hassen die Chefs das so ja, es ist Todeswichtig für eine Software, weil nur dann kannst du sonst auch technische Schulden aus. Auch Technical Debt is so ein wichtiges Wort. So technische Schulden heißt es. Ich weiß eigentlich, dass das. Nicht ganz richtig ist und irgendwann komme ich da nicht mehr weiter.

Das ist, wie wenn ich mein Fahrrad nicht vorbereitet, also sagen wir mal, ich hab da irgendwie noch 8 Hinterreifen so und so wenn ich langsam genug fahren es steht egal ja so bloß irgendwie noch Features Fahrrad dran machen ja auch irgendwann Gepäckträger und das müssen wir alles machen.

Ich sag halt, kümmert sich früh genug um die 8 im Reifen, dann irgendwann, sagt der Chef oder die Kunden jetzt geht aber mal Gas, ja und dann fällt das ganze Fahrrad wieder komplett auseinander, weil die 8 und die Unwucht drin hat alles zu Tode gemacht Chris. Probleme, Skalierung zum Beispiel richtig ja und das ist und das und das wird teurer, je

länger du das nicht behandelt. Das Problem ja, je länger du dann hast du nämlich investiert in deine Klingel, in dein Licht, in deinen Gepäckträger und zum Schluss fällt dir das alles wieder auseinander kannst du gerade alles nochmal neu machen? Ne, so ist es. Ich weiß nicht, ob das gut passt, aber das passt eigentlich nicht schlecht. Also refactoring refactoring. Ich hab quasi keinen echten Fehler und ich habe auch keinen echtes Feature Quest aber ich

weiß halt. Alle Softwareentwickler fühlen das und sehen das hier muss mal neu gemacht werden, ist wichtig, nicht mal unbedingt Tuning, sondern wirklich n Verbesserung des Status quo genau und da gibt es natürlich also man muss sich auch erwehren, davon ist alles neu schreiben zu wollen. Das ist auch so n das hat man gerade als als deswegen sag ich

mal Erfahrung also man muss auch genau im Mittelmaß finden, sonst denn alles neu schreibt so, dann hat man wieder ein neues Refactoring, wenn s da auch wieder nicht alles ne. Also man muss sich schon iterativ dem annähern. Aber man muss reflektieren dürfen und die Zeit dafür. Ganz wichtig ja. Das Thema was ich noch hatte, war jetzt OK. Wir haben diesen Kreislauf bestehend aus Wartung und Pflege und dem auch dem Refactoring.

Hoffentlich laufen wir irgendwann, ist dann auch dann doch ein Ende von Software erreicht oder? Des Lebenszyklus erreicht. Es gibt da manchmal abkündigung oder ach so ja genau ja das stimmt. Jetzt hatten wir das vor kurzem im Gespräch mit einem mit einem potenziellen Kunden. Sagte ja, wir haben halt auf die Io t Suite, sag ich mal SAP gesetzt in dem Fall also auch closed Source Software und es AP aus welchem Grund? Man kann nur mutmaßen, hat er gesagt.

Na ja, das verfolgen wir nicht weiter, und das wird dann damit eingestellt und abgekündigt passiert immer wieder. Wie wird das Gehändelt einmal aus Sicht von der Softwarefirma selber da? Passiert das überhaupt noch? Sangen das ist ja gekündigt werden und? Vielleicht den zu schließen zu Open Source ist da mal erwähnt kann ich da irgendwie als Firma auch vorsorgen, indem ich vielleicht gleich auf Open Source setzen oder zumindest mir den Quellcode irgendwie zugänglich mache?

Also ich glaube, das ist irgendwie schwierig, ne entweder also wird dir was abgekündigt oder kündigst du selber was aber genau das sind 2 Perspektive sind 2 p genauso also das schlimme ist natürlich, wenn irgendwas angekündigt wird, so ja tut mir leid so war oder irgendwas aus irgendwelchen Tausenden anders gibt irgendwie das Projekt mehr ja. Ja, dann stehst du natürlich da und dann ist halt die Frage wie kannst du das quasi tatsächlich loswerden? Alles und durch ein neues ersetzen?

Das ist bestimmt kostenintensiv und aufwendig, ja und die andere Möglichkeit, die hast du aber nur dann, wenn es vielleicht open Source war, ist dann zu überlegen OK, das ist vielleicht ist es die schlankere und bessere Alternative ist selber in die Hand zu nehmen, zu warten, oder?

Ist eine oder vielleicht quasi wie groß genug bist, kannst du ja quasi ein kleiner extra Firma gründen, die nur das Macht, dass sie quasi das, was vorher gemacht wurde, durch eine andere Firma wieder übernimmt und weiterentwickelt. Das kann man glaub ich nicht generalisieren, aber also die Option alleine hast du nur dann wenn Source ja aber Software ist nicht zwingend von Anfang an so geplant, dass es irgendwann Ende gibt, das hat man eigentlich nicht singen.

Ich weiß nicht, ob ich der richtige Antwort Partner bin für

weil also. Schönerweise muss ich sagen, in meinem Leben habe ich immer Software Projekte entwickelt, die eigentlich auf unendliche Zeit leben sollten, wenn es geht ja und sich weiterentwickeln sollten, also bestimmt nicht die ursprünglichen Codes so aber eigentlich keine kündigungs Grenze hatten also bei dem zum Beispiel, bei dem ich glaub er bei dieser Anlage die ich halt allein die Anlage geplant locker 2030 40 Jahre zu stehen und das ist natürlich für Software

Projekte gigantische Zeit, ja vielleicht Quantencomputer, dann irgendwo hin aber es ist immer darauf angelegt gewesen, dass er

ist. Also es gibt natürlich auch wegwerfware, ich mag irgendwie App für irgendwas so ja so dann klar das knallt irgendwie hin so und dann braucht ihr irgendwie einen ja und dann interessiert auch keinen mehr ja, aber ich tatsächlich war in solchen Projekten involviert so ja ist auch ganz schön, das ist ein bisschen wie beim Aftersales, da kennst du dich besser aus, ne, aber hast du natürlich so hast du also wenn du ein Software Projekt langlebig hast du einen

After sales Alarm so und hast du natürlich so ein Tamagotchi, was da einmal raushaust und dann ist auch egal ja, dann ist natürlich einfacher. Ich habe noch Windows gedacht, was er jetzt wieder der Fall ist. Glaub ich Windows 10 jetzt auch wieder keine Updates mehr erhält also abgekündigt ja genau der jetzt wenn man gezwungen auf Windows 11 zu gehen um noch weiterhin Updates zu erhalten.

Für die Software Firmen natürlich angenehm irgendwas anzukündigen und den Produkt an sich Windows bleibt ja da ist eben nur wieder ne neue Version. Na ja, das stimmt ja ja, aber du hast natürlich mit der neuen also mit sowas gut. Das ist natürlich Beispiele sind Betriebssysteme, das die

Endstufe von Software irgendwie? Aber ich glaube, das ist auch ganz gesund, es geht gar nicht ne, also man kann hohe Erwartungen ich also zum Beispiel eine ein Beispiel C plus Plus war als Programmiersprache ist ja auch quasi krasser Weise die Programmiersprache selber irgendwie Software, die waren ganz lange dafür bekannt und hat ewig lange Zyklen. C plus Plus war total stabil, ewig ja und jetzt haben die C plus 11 haben die angefangen

irgendwie auch ein bisschen schneller zu machen und auch mal. Denn das ist extrem. Es ist extrem schwierig, quasi rückwärts kompatibel zu bleiben,

so dass alles noch geht. Das ist aber bei Sprache natürlich noch wichtiger als bei allen anderen ne, aber es ist für n für Entwicklung und für eine Software insgesamt natürlich auch ganz heilsam irgendwas abzuschneiden, ne und du kannst ja nicht immer den ganzen alten Kram mit dir herumschleppen und so ja und irgendwann, wenn du mal die Möglichkeit hast n Neues herauszubringen und sie sagen OK die alten Kram den Support nicht mehr, dann wird natürlich auch

wieder ganz Kreislauf den du hast ein ganzes Stück schlanker, weil du nicht so ne so ne riesen Gießkanne. Den alten Krempel irgendwann kommt ne genau, man muss sich einfach nur dessen bewusst sein, was es mit sich bringt, wenn man da ein bisschen abschneidet. Ja, es mag der andere ein bisschen mehr Aufwand haben, vielleicht sein, aber langfristig oder auch vielleicht sogar mittelfristig einfach viel

mehr. Das ist halt die Kunst des richtigen Business, sag ich mal die richtigen Entscheidungen zu treffen, am Markt zu bleiben und gleichzeitig irgendwie.

In meinem eigenen Einsatz irgendwie schlank zu bleiben, das ist irgendwie, das war eine richtige Erfolge fand ich ne, ich hab aber trotzdem was gelernt über Softwareentwicklung worauf achten ist, ich denke der oder die andere kann da auch was mitnehmen und würde jetzt aber sagen passt soweit oder Deckel drauf hast du noch was hinzuzufügen?

Nö, ich lass mal erstmal so wie es ist, glaube ich, dass ihr denkt daran uns mal ne Bewertung dazulassen ne gute im besten Fall ja öfter mal gesagt, aber das bringt uns wirklich viel dass. Sehr nett und ansonsten würde ich sagen, bis nächste Woche danke zu hören und wenn auch hier, vielen Dank fürs Zuhören. Hamburg ciao.

Vielen Dank fürs Zuhören dieser Folge von einfach komplex die Folge gefallen dann lass uns doch ne gute Bewertung da oder Teile die Folge mit jemanden aus seinem Netzwerk für Kritik zufolge Anregungen und Fragen für neue Folgen, freuen wir uns auf deine Email an Podcast dateiserver.com Abonniere jetzt unseren Podcast, um keine Folge zu verpassen bis zum nächsten mal Tschüss aus Hamburg h.