Skillbyte Podcast #9: Bull's Eye Software Development - Einfach und fokussiert auf Unternehmensziele

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Bull's Eye Software Development - Einfach und fokussiert auf Unternehmensziele

// Inhalt //

1. Definition: Das Ziel von Software
2. Unternehmen kommunizieren Unternehmensziele von Software oft nicht klar.
3. Der Wert von SCRUM
4. Für Entwickler: Was bedeutet professionelle Softwareentwicklung?
5. Fazit: Bessere Kommunikation von Unternehmen & zielgerichtete Entwicklung

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Herzlich willkommen, liebe Zuhörer, zur neunten Folge des Skillbyte Podcasts Bulls Software Development einfach und fokussiert. Wenn Ihr gerne mehr zum Thema wissen möchtet, dann schreibt gerne eine Frage an Podcast Skillbyte abonniert unseren Podcast, der mittlerweile schon einige Folgen hat und wir freuen uns immer über Bewertungen und Anregungen. Ich bin heute hier wieder mit dem Geschäftsführer von Skillbyte Masiar.

Hallo Masiar, hallo!

Hallo und wir sprechen über das Thema Bulls Eye Software Development. Vielleicht sollte ich kurz sagen, was damit gemeint ist. Es geht einfach darum, dass man mit der Softwareentwicklung, die man durchführt, das ist jetzt auch übertragbar auf Data Science oder Dev OPs arbeiten, dass man genau das vom Kunden intendierte Ziel trifft, also möglichst wenig unnütz entwickelt, sondern direkt das Ziel versteht sich eine Architektur überlegt und zielgerichtet entwickelt. Ich glaube, das ist ganz wichtig. Ich würde kurz nach der Definition davon geben, was ich glaube, was das Ziel von Software ist.

Masiar Gerne. Also in meinen Augen muss ich ganz ehrlich sagen, ist Software kein Selbstzweck. Software wird im Unternehmen erstellt, um einen Wert zu schaffen, neudeutsch Business Value, also etwa ein neues Produkt ermöglichen. Könnte man sich vorstellen, wenn eine Versicherung statt eines normalen Papier Antrages eine digitale Antrag erstrecke hat, worüber man eine Versicherung abschließen kann, wird da ein neuer Wert geschaffen. Bestehende Prozesse können durch Software standardisiert werden oder optimiert werden. Da denke ich, können sich unsere Zuhörer auch was drunter vorstellen, oder?

Software kann einen Erkenntnisgewinn schaffen, etwa aus Daten Auswertungen. Das sind meiner Ansicht nach ist der Sinn von Software, also Business Value schaffen, Prozesse optimieren oder standardisieren oder einen Erkenntnisgewinn aus vorhandenen Daten. Also das heißt, die Software besteht nicht für sich selber, sondern ist letztlich ein Werkzeug zur Erreichung eines Unternehmens Ziels. Ganz wichtig und meiner Ansicht nach unterstützt gute Software diese Unternehmensziele. Also das können so schnöde Sachen sein wie Gewinnmaximierung, aber auch Steigerung der Innovationskraft. Gute Software unterstützt diese Unternehmensziele zuverlässig und ist halt auch erweiterbar.

Das heißt, wenn sich die Unternehmensziele ändern, kann man die Software einfach anpassen oder erweitern, um diese neuen Unternehmensziele auch mit aufzunehmen. Das denke ich oder ist aus meiner Perspektive sehr, sehr wichtig, dass diese Kriterien getroffen werden. Jetzt kommen wir aber direkt zu meiner Beobachtung. In der Praxis möchte ich aber gespannt.

Ja, genau. Ich erzähle erst mal, was ich beobachtet habe. Dann bin ich gespannt, was du beobachtet haben in diversen Projekten. Und zwar sehe ich relativ häufig, dass die Software Entwicklungsabteilungen diese Unternehmensziele gar nicht zu 100 prozent verstanden haben oder gar kennen. Also die Unternehmen nehmen sich nicht die Zeit, um zu sagen das ist das Ziel. Und genau das soll erreicht werden und auch genau das und das und das soll nicht erreicht werden. Also eine ganz klare Ziel Projektion.

Das ist das Ziel, was wir mit diesem Projekt, mit dieser Software, mit diesem Thema erreichen möchten. Und aus dieser unklaren Ziel, Beschreibung oder der nicht vorhandenen Beschreibung entstehen dann in den Köpfen der Menschen, aus denen diese Teams zusammengesetzt sind, ganz, ganz viele unterschiedliche Ziele. Dadurch läuft meiner Ansicht nach oft die Softwareentwicklung oder auch bei Big Data Themen, die Datenauswertung nicht so stringent und schnurstracks auf das Ziel ausgerichtet, wie sie das eigentlich könnten, sondern die Leute fangen an, ihre eigenen Ziele einzubringen und probieren etwas aus, wovon gar nicht klar ist Okay.

Hilft uns das bei der Zielerreichung? Oder Sie bringen selber neue Themen ein? Das ist nicht schlecht. Ich möchte das ganz klar herausstellen, aber es ist einfach nicht fokussiert, zielgerichtet und da wird sehr viel Energie verbrannt, die nicht auf das Unternehmensziel einzahlt, was am Ende durch diese Software unterstützt werden muss. Also das ist meine Beobachtung, die ich sehr oft in Projekten mache. Ganz praxisnahe Beispiele. Ich habe das jetzt auf einer sehr hohen Flughöhe erklärt. Neue Tools werden integriert, die irgendwelche Bugs finden sollen, oder neue Schnittstellen werden integriert, die Status Informationen über das System ausgeben, was ja per se nicht schlecht ist.

Aber vielleicht ist es gar nicht das Ziel, dass diese Software Schnittstellen bietet, um Informationen über den eigenen Anwendungs Status herauszugeben. Wenn es sich beispielsweise nur um einen Konverter handelt, der einmal Daten in einem Datenformat in ein anderes Datenformat überführt, also eine Anwendung, die einmal läuft und die danach im Grunde weggeworfen werden kann, weil der Arbeitsschritt erledigt ist. Oder dann entsteht dann der Wunsch Ja, okay, ich hätte gerne eine Continuous Delivery Pipeline für das Projekt. Und dann stellt sich raus, dass das Projekt genau so ein einmal wegwerfe Tool ist oder dass da im Grunde nur irgendwelche Daten angepasst werden müssen.

Und dann ist das ganze Projekt überfällig. Aber diese Person hat noch nie eine CCD, die Pipeline. Aufgesetzt oder in Betrieb genommen und würde das gerne tun im Zuge dieses Projektes und das wäre doch jetzt ein schöner Moment, um das mal auszuprobieren. Da hat jemand quasi eher seinen eigenen Sibi oder seinen eigenen Interessen im Blick. Statt dem wirklichen Unternehmensziel. Und das ist eine Beobachtung, die ich wirklich sehr, sehr oft mache. Das aufgrund von fehlender Zielorientierung die Leute anfangen, sich ihre eigenen Ziele auszusuchen.

Und dann nimmt man natürlich das, was man gerne macht und meidet. Vielleicht das, was man nicht so gerne macht, was aber vielleicht nötig ist für das Unternehmen oder für die Umsetzung dieser Software.

Also ich mache eine sehr sehr, sehr ähnliche Beobachtung. Ich bin jetzt selber Entwickler, seit ca. 25 Jahren Software und ich komme quasi wirklich klassisch aus diesem Wasserfall Modell, wo es Projektmanager gab. Diese alten Rollen, wo mehrere Menschen Konzepte sich Tage, Wochen, Monate eingeschlossen haben, um mal eine Art Pflichtenheft zu basteln. Und die Projekte sind meistens schiefgegangen, auch damals. Und zwar einfach weil das sehr lange gebraucht hat, bis du diese Spezifikationen geschrieben hast. Und dann hat da haben die Entwickler angefangen diese Spezifikation umzusetzen.

Also da warte ich bis auf den Button, was als Text gelten soll, welche Farbe es soll oder alles runtergeschrieben. Nur was man angefangen hat, diese Dinge zu entwickeln, gab es schon Änderungen. Sei es jetzt irgendwie aus dem Markt heraus, aus der Branche heraus, aus den Köpfen heraus der Leute, die auf einmal festgestellt haben Nee, das muss man doch so und so! Und es gab immer Diskussionen mit den Entwicklern, mit ihren Dienstleistern, dass jetzt gewisse Änderungen notwendig sind.

Und meistens, wenn man so ein so ein bisschen die Spezifikation hatte, hat man noch einen Festpreis genannt. Das heißt, es war klar, was das Ding kostet. Das wurde in der Zeit daran gesetzt. Man wusste auch, wann die Software rauskommt, aber das hat nie geklappt. Also die Projekte waren zu 85 prozent out of time und out of budget, einfach weil diese diese Anforderungen sich quasi, während du sie niedergeschrieben hast, schon fast geändert haben.

So, und da kommen wir zu einem wichtigen Punkt, was das mir sehr negativ auffällt, dann kann das das Thema Scrum. Scrum war eine andere Methodik, um Software zu entwickeln. Das heißt einfach der Tatsache geschuldet, dass man gar nicht weiß, was die Anforderung einer Software am Markt wirklich sind. Das heißt, die Unternehmens eigenen Mitarbeiter haben sich eingeschlossen, haben gedacht, was die Software können muss. Und aus ihrer eigenen Erfahrung, aus ihren Beobachtungen haben sie dann diese Dinge runter spezifiziert.

Es war aber nie am Mann, also nie am Markt. Und wenn man dann live gegangen ist, hat man festgestellt Oh, Kunden erwarten eigentlich was ganz anderes. Und deswegen ist er entstanden, das Thema Agilität, indem man gesagt hat, dass auch wir spezifizieren gar nicht monatelang, wie die Software aussehen soll, sondern wir setzen rudimentäre Anforderungen um und versuchen so schnell wie möglich, das zu testen am Markt. Das heißt, ich gebe in der Software, was vielleicht nicht perfekt ist, aber die Mindestanforderungen erfüllt, die ich an den Markt gucke, wie die Kunden damit klarkommen, wie sie reagieren, welches Feedback sie geben.

Und kontinuierlich verbessere ich das Produkt und bringe nach und nach Features rein, die der Markt mir gesagt hat, dass es das will. So, das war und ist Scrum. Nicht mehr, nicht weniger. Was ich aber beobachte in den Firmen ist, dass Konsum zum Selbstzweck mutiert ist. Das heißt plötzlich tauchen, weil die Unternehmen selber haben jetzt gehört, es ist bei den angekommen Agilität. Wir müssen agiler werden in unseren Entscheidungen, in unseren Prozessen und setzen das aber leider gleich mit Scrum.

Und dieses zum Selbstzweck mutiert sein geht sogar echt bis dahin wo ich habe es kein Unternehmen mehr in der letzten Zeit gesehen, was sich eigentlich wirklich auf Softwareentwicklung konzentriert, sondern alles ist nur um dieses Thema Scrum aufgebaut. Das scheint mir fast wichtiger geworden zu sein, als als eine hohe qualitative Software zu liefern, sondern alles Scrum und Scrum wird auch den Entwicklern sehr viel Verantwortung zugespielt. Das heißt, alles was die im und um diese Software tun, entscheiden sie selber.

Es gibt keinen klassischen Architekten mehr wie früher, der sehr erfahren war, der sich in vielen Bereichen zu Hause gefühlt hat und gesagt hat So und so müssen wir das machen, sondern das Team entscheidet. Und je nachdem, wie groß die Teams sind, kommen viele verschiedene Meinungen, die aufeinanderprallen und man diskutiert sehr viel herum um das Thema. Und wie du gesagt, dass ein Ding, was dabei rauskommt, ist, dass jeder tut, was er will. Jeder setzt die Libri ein, die er will, weil er es gehört hat, weil es eben gelesen hat und teilweise ist.

Ich habe Projekte im selben Projekt durch diverse Neubesetzungen von Leuten auch also Scrum, wechselnde Scrum Mitglieder, verschiedenste Bibliotheken für ein und das gleiche im Einsatz war in alten Versionen in neuer Version ein Wildwuchs von Technologien, wo hinterher wirklich keiner mehr Herr ist. Aber ich meine, man muss nach wie vor qualitativ hochwertige Software herstellen und das ist halt. Meines Erachtens nicht möglich, wenn ich alles Neue ausprobiere. Hinterher natürlich auch nicht aufräume, nur mein Zivi zu verschönern oder nur das zu machen, was mir Spaß macht.

Das nimmt so absurde Tendenzen nehmen da Gestalt an. Wow, aber Spielchen gespielt werden, wo man in ist. Beispiel zum Beispiel bei Scrum gibt es ein Konstrukt Retrospektive, wo man sich alle zwei Wochen hinsetzt nach einem Sprint und sich drüber unterhält Hey, was ist gut gelaufen, was ist schief gelaufen? Und da geht es darum, Kommunikation zu fördern. Das ist Sinn und Zweck und nicht mehr und nicht weniger. Früher hat sich jeder eingeschlossen, hat seine Spezifikation runter programmiert und man hat nicht über den Tisch mit dem anderen gesprochen.

Und das soll Scrum auch ändern. Aber das ist so weit führt, dass man Spielchen macht, indem man das zu machen, womit man unzufrieden ist in Form eines Star Wars Filmes und Star Wars Charaktere beschreiben soll, was einem nicht gefällt. Also mein lieber Mann, es gibt Auswüchse, da kann ich mir nur an den Kopf fassen, sagen okay, wenn es okay Unternehmen für so was bereit ist zu zahlen. Ich habe es so gesehen auf Signer hatte eine sogenannte agile Coaches haben sogar ein Scrum Spiele Buch geschrieben, also welche spielt man mit den Entwicklern spielen soll, um ja spielerisch an diese Kommunikation ranzukommen.

Meines Erachtens totaler Bullshit ist am Ende und du hast es ganz am Anfang den Satz gesagt es geht darum, wer zu schaffen für das Unternehmen und das ist komplett aus den Augen verloren. Es ist nur noch Selbstzweck. Es ist Entwickler bespaßen und nicht mehr Softwareentwicklung als ernsthafte Ingenieurs Technik.

Er ist wirklich Bespaßung. Also ich sehe den Wert von Scrum darin. Zwei Punkte sind ganz essenziell oder für mich persönlich und da würde ich zum einen das Daily hinzuziehen. Man erzählt, was man gestern gemacht hat und was man heute machen wird. Das zwingt aber implizit jedes Teammitglied einen Tagesplan zu machen. Im Prinzip Was werde ich heute tun und was möchte ich erreichen? Was möchte ich heute Abend fertiggestellt haben? Und das halte ich für sehr wertvoll, diesen Plan zu machen und dann auch darüber zu sprechen.

Und dann entsteht ja so eine Art Accountability. Also ich habe jetzt gesagt, was ich heute schaffen will und dadurch habe ich die Verantwortung für meinen Tagesplan übernommen, dass ich das heute schreiben möchte. Also das ist ganz wichtig für den eigenen Fokus. Die Daily sind super wichtig bei Scrum und der zweite Punkt ist die alle zwei. Also je nach Sprint Länge. Meistens sind es zwei Wochen. Ich hatte auch schon drei Wochen oder mal eine Woche die Retrospektive, die Demo.

Was ist in den letzten zwei Wochen geschehen? Idealerweise mit einem funktionsfähigen Release. Das sollte man immer anstreben. Das ist aber in so einer Concept Phase auch nicht immer möglich. Aber dann muss man halt zeigen, wie man weitergekommen ist. Eine Demo zeigen, das haben wir in den letzten zwei Wochen gemacht. Und ist das noch das, was du willst? Weil in den nächsten zwei Wochen werden wir das und das tun? Und sind wir noch auf Kurs, dann hat der Kunde oder der Stakeholder oder derjenige, der das ganze Projekt finanziert, ne Chance zu gucken.

Okay, reicht das schon gehen? Bewegen wir uns in die richtige Richtung? Oder muss sich eine Kursänderung vornehmen? Also wie auf einem Segelschiff? Der Kurs ist eingestellt, man fährt der Sonne entgegen und ab und an guckt man mal auf den Kompass. Stimmt das noch so? Was ich da, in welche Richtung wir uns bewegen oder müssen wir das Segel ein bisschen nachjustieren? Und genau das sind meiner Ansicht nach die zwei wichtigsten Punkte von Scrum dass man diese Baileys und diese Review Kontrolle hat mit dem Menschen, der letztlich ja das ganze Projekt verantworten muss.

Und das war's auch. Das sind die Ursprünge, was du gerade aufgezählt hast in die ursprünglichsten und reinsten Scrum Methodologie, die bei dem agilen Manifest festgelegt worden sind. Alles andere, dieses Zeug also ich habe mich fast sogar in Projekten, wo ich vielleicht zwei Stunden am Stück entwickeln konnte, weil permanent irgendwelche Kosmetik sind. Ob das im Refrain ist und Grooming ist Coming 1 Coming 2 Rückfall. Wenn ein Zufall mit 2 es ist mutiert, das will ich damit sagen.

Es ist zum Selbstzweck mutiert. Warum kann ich auch genau sagen, wenn ein Coach kommt, dann hat er die Methodologie in drei Tagen erklärt und vielleicht in zwei Wochen begleitet. Und dann ist man eigentlich vom Stoff für fertig. Das heißt, was würdest lernen, wenn du Coach wärst und dein Geld damit verdienen würdest? Würdest du sagen Okay, ich mach das zwei Wochen und dann such ich mir einen neuen Kunden? Oder versuchst du natürlich, im Unternehmen zu bleiben, sie permanent zu begleiten?

Natürlich fängst du dann an, das ist doch nur menschlich. Und aus wirtschaftlicher Sicht gesehen findest du was drum herum, was du noch machen kannst. Und Spielchen hier und Meetings da. Die haben das Ruder übernommen, da das für das Management den Entwicklern nicht vertraut oder oder denen nicht glaubt und eher Beratern wie z.B. Accenture akzentuierte, da reinkommt und sagt Kann ein Unternehmen auf agil umstellten, das soft links und die Berater kommen, die so was erzählen, dann glaubst du denen, die glaubt, du glaubst denen das ja mit dieser Methodologie, mit all diesen.

Zeugs was da rein gehört, kann nicht mein Unternehmen und das verbrennt produktive Entwicklungszeit plus wenn man diese auch ein Ding was daraus entstanden ist, ist diese Selbstverantwortung dem Team zu übergeben. Ich habe sogar ein Unternehmen erlebt, die gar nichts mehr entscheiden. Es gibt null Hierarchie und das Team kann komplett selbst entscheiden was es tut und das Chaos ist da vorprogrammiert. Das ist genauso wie aktuell in der deutschen Politik. Wenn zu viele Leute mitreden können, dann kommst du nicht vorwärts, weil man nur noch diskutiert.

Und das ist genau der Punkt, was ich in vielen Unternehmen erlebe, die sagen Wir wollen jetzt unbedingt agil werden und diese Selbstverantwortung in die Teams legen. Man diskutiert sogar teilweise Oh, ich habe jetzt ein Rollcontainer, der hat keinen Rat mehr, der funktioniert nicht mehr. Da wird darüber diskutiert, wie man dieses Problem behebt oder wie man neue Kleiderständer bekommt, überlegt, dass man sich teure Entwickler stunden. Meistens sind es sogar nur externe. Fasste In einem Team sind die Kosten pro Stunde 100, 120, 30 Euro.

Ja, kann man machen. Muss man nicht. Und das tut mir als ob. Ich bin ja nicht nur Entwickler, sondern auch Unternehmer. Und das tut mir jedes Mal, wie wenn ich das sehe. Ich kann mich nur sehr schlecht mit identifizieren. Ich bin der Meinung Agilität ja viel besser als es früher der Fall war. Es ist die richtige Richtung. Aber nicht übertreiben, nicht komplett ausufern lassen.

Da schließt sich ja gewissermaßen der Kreis wieder. Warum wird die Zeit in diesen Meetings versenkt? Weil halt das Ziel nicht klar ist. Also wenn das Unternehmen sich hinstellen würde und sagen würde, das ist das genaue Ziel, was wir mit dieser Software erreichen möchten. Das kann ja auch ein Meta Ziel sein oder auf einer sehr hohen Flughöhe bekanntgegeben werden, damit aber jeder weiß okay, darauf arbeiten wir hin und dass jeder im Team sagen kann Warum machen wir das Ganze?

Warum sitzen wir hier? Welches Ziel des Unternehmens müssen wir mit der Software unterstützen? Damit die Entwickler natürlich sich auch eigene Ziele setzen können, die sie dem großen Ziel unterordnen können. Natürlich ist das super, wenn Sie eine neue Technologie bei der Projekt Umsetzung lernen, wenn Sie einen interessanten Algorithmus implementieren und das Projekt dadurch vorwärts bringen. Aber dennoch, glaube ich, ist es wichtig, dass auch der Entwickler weiß Was ist denn der kritische Pfad? Welche Themen müssen wir auf jeden Fall behandeln?

Und dann kann man dabei ja schauen. Ok, kann ich das besonders effizient umsetzen oder kann ich da eine neue Library mit einbringen? Wenn das nämlich nicht passiert, dann entsteht dieses Klischee oder dieses Klischee. Gibt es bereits dieser Spiel Kind Entwickler, die hier mal was basteln, da mal was basteln, sich hinter Fachbegriffen verstecken und es fürs Management gar nicht so klar ist. Arbeiten die jetzt für das Projekt oder probieren sie nur irgendwas aus? Oder ist dieser Arbeitsschritt wirklich notwendig?

Weil das kannst du ja oft. Wenn du als Manager oder als Projektleiter nicht vom Fach bist, kannst du das ja an einem gewissen Detailgrad gar nicht mehr genau herausarbeiten oder feststellen. Und da glaube ich, ist es wichtig, diese Ziele, diese Software Ziele mantraartig zu wiederholen vom Management und zu sagen Das ist genau unser Ziel. Bitte prüft eure Arbeitsschritte genau zyklisch. Zahlt das, was ihr gerade macht, auf dieses Ziel ein und kommen wir dadurch weiter.

Ja, und das hilft den Entwicklern, die Balance zu halten zwischen Exploration. Ich benutze ein neues, neue Library und komme damit vielleicht sogar schneller ans Ziel. Das ist ja total begrüßenswert und Fokus. Also du hast immer dieses Exploration Fokus Exploration Fokus diese Waage bei Custom Software oder selbst geschriebener Software, zwischen dem man balancieren muss. Manchmal eine das kennst du sicher auch, weiß man nicht. Okay, komme ich mit A, B oder C ans Ziel, dann machst du ein kleines sogenanntes Proof of Concept.

Also du probierst irgendwas aus, was vielleicht auch wieder weggeschmissen wird, wenn es nicht funktioniert oder wenn es funktioniert. Man findet den besseren Weg, kann es ja auch wieder rausgeschmissen werden. Aber dass man kurz guckt, funktioniert das so, wie ich mir das vorstelle und dann wird es integriert. Aber das ist für mich dann so der richtige Mix aus Fokus und Exploration. Aber dafür müssen die Softwareentwickler natürlich wissen Was sind denn die Ziele, die man erreichen möchte?

A Dass und b man versucht durch solche ich sage mal Spielchen wie kommen wir? Wir machen jetzt ja etwas und überlegen uns Shantanu Namen und schnitzen uns zarter Maskottchen. Alles schon gesehen? Es gibt alles. Da geht es darum, als aus Management und aus agile Coach Sicht dieses eben Nerds einzufangen, die die, die, die im Prinzip dieses spielerische und so weiter. Aber man verkennt die Situation. Der Entwickler will nicht spielen, will sich keinen Namen aussuchen, Entwickler will ernst genommen werden, wertgeschätzt werden und er will selbstständig arbeiten können, ohne dass ihm einer vorschreibt, was er zu tun hat.

Ohne einen Chef zu haben, der von der Materie keine Ahnung hat, ihm aber verklickern will, wie er es tun soll. Solche Dinge sind es, die Entwickler reizen und ein gutes Arbeitsklima und nicht solche Spielchen und und. Natürlich sind aber die Leute diese Spielchen verkaufen, verklickern das Management so, dass man solche Dinge braucht. Nein, braucht man nicht. Das braucht der Entwickler nicht.

Mir ist aufgefallen, dass innerhalb der Teams. Du hast es eben schon angesprochen, da ist man bemüht, keine Hierarchie aufkommen zu lassen. Jeder ist gleichberechtigt, wir hören uns jede Meinung an. Aber bei Entwicklern oder Leuten oder Data Scientists, die merke natürlich sehr schnell untereinander. Auch wer wirklich viel Erfahrung hat und da viel beitragen kann und wer vielleicht noch nicht so weit ist. Es entsteht schon so eine Hierarchie anhand der Kenntnis sozusagen. Und das finde ich wiederum ganz gut.

Natürlich, wenn jemand dann neu im Team ist und vielleicht ein halbes Jahr bei dem Unternehmen arbeitet und da ist jemand, der hat das schon zehn Jahre begleitet. Also ich glaube, die können beide voneinander lernen. Aber wenn der Architektur aufgesetzt wird, ist es natürlich so, dass derjenige mit mehr Erfahrung da ein höheres Gewicht oder die Aussagen von dieser Person ein höheres Gewicht haben. Und solange das fachlich stimmig ist, glaube ich, hat auch niemand ein Problem damit.

Also das so meine Erfahrung.

Da spricht aber das nächste Problem an, weil in Scrum gibt es keine detaillierte Spezifikation und das ist das aber auch, was ich jetzt, was ich erzähle gleich von vielen Entwicklern höre in Teams, dass die User Stories nicht hinreichend genug beschrieben sind. Das heißt, meistens ist eine User Story eigentlich ein, zwei Zeilen lang unterschiedlich viel drin. Die Idee dahinter ist ja, dass man im Team bespricht, wie man das macht und eine Komplexität abschätzt und das umsetzt und der Kunde aber das immer begleitet und sehen kann.

Hey, das läuft in die falsche Richtung, also wollte ich das nicht. Bekomme das Bild von grün auf gelb. Das ist Agilität, dass ich Software agil entwickle. Agil bedeutet Änderungen sind willkommen und nicht verboten, wie es früher der Fall war. Ja, wo Change gestellt werden musste, da muss ich genau überprüfen. Okay, was kostet so ein? Das gibt es bei Scrum oder soll es alles nicht mehr geben? Und das denken aber die Product Verantwortlichen ist ein Freifahrtschein für nicht über das Produkt nachdenken.

Und so schreiben sie halt irgendwas als User Story auf und Entwickler weiß nichts damit anzufangen. Und da ist das größte Problem, weil wenn man schon agil arbeitet und Scrum umsetzen will, muss man die Rollen, die diese Methodik vorgibt, auch verantwortungsvoll und ernsthaft besetzen. Wie zum Beispiel Product Owner, der im Prinzip, das das Produkt besitzt, von der meistens von der Fachlichkeit kommt und dem Team erklären kann, was er eigentlich will. Und diese Rolle habe ich also die einen besetzen es gar nicht.

Das heißt, normalerweise musste auch im Team sein und nicht irgendwo her für eine Stunde dazu kommen.

Nun auf Zuruf irgendwas tun und diese Rolle wird einfach nicht ernst genug genommen, ein abzustellen, der im Prinzip das Produkt versteht sich da rein denkt und überhaupt mal in Wort und Schrift fassen kann, was er gerne möchte. Und und da entsteht halt Chaos ohne Ende. Das ist aber auch der der Natur der Sache geschuldet. Er kann vielleicht nur eben ein ganz einfaches Beispiel Ich möchte mich einloggen können. Okay, dann würde ich jetzt vielleicht direkt daraus schließen. Username Passwort.

Aber es geht ja jetzt weiter. Wie sicher muss das Passwort denn sein? Wie viel Zeit? Also was bedeutet an sich das Passwort? Bin ich eine 2 Faktor Authentifizierung will? Es geht um dieses kleine Thema. Könnte man Bücher drüber schreiben? Das weiß aber der Provider oder vielleicht gar nicht. Deswegen meines Erachtens fehlt ein Architekt in diesem Konstrukt, der so viel gesehen hat, so viel Know how von der Front, von der Software hat, der anleiten und helfend unterstützen, dem Produkt oder und dem Team helfen kann, zusammen zu kommen.

Diese Rolle fehlt einfach und das sehe ich auch, dass die Firma unheimliche Schwierigkeiten haben, ihren, ihren Wunsch oder was den Mehrwert ihrer Software eigentlich liefern soll, zu formulieren, was selten ist, was aber unheimlich hilft. Und mein Bruder sagt mir, in amerikanischen Unternehmen ist das gang und gäbe, weil die auch schon wahrscheinlich noch mehr auf die Nase gefallen sind und die Lehre daraus gezogen haben. Ist wenn du einen Product Owner vielleicht noch gar nicht mal. Aber wenn du so einen Projektmanager hast, der selber mal Software geschrieben hat und von der technischen Seite, der muss nicht mehr entwickeln können, aber von der technischen Seite ein großes Verständnis mitbringt, aber auch von der fachlichen Seite ein großes Verständnis mitbringt und der diese Welten zusammen bringt in einer Person, der wird von dem Team respektiert, weil er eben technisch sagen kann Nein, das können wir so machen, das können wir so machen, das kann man so machen und und einfach durchscheinen lässt.

Ich weiß technisch genau, wovon ich rede. Diese große Aufgabe brechen wir in kleine Bröckchen runter und dann kann jeder von euch entwickeln. Aber lasst uns die Architektur gemeinsam entwickeln und ich weiß, dass ich das machen kann. Und auf der anderen Seite fachlich, dass dem Management auch ich sage mal knifflige Entscheidungen so verkaufen kann und sagt Leute, ich verstehe die Techniker, ich verstehe natürlich auch eure Anforderungen. Aber um beides zusammenzubringen, müssen wir und jeden Trade off eingehen oder drei Wochen länger entwickeln.

Was auch immer dann in der konkreten Situation von Nöten ist. Und diese Menschen, wenn es die gibt, die sind ein unheimlicher Gewinn für jedes Team und auch für jedes Unternehmen.

Und ein echter Glücksfall.

Definitiv, was hinzu kommt. Das ist jetzt ein Wandel im Leben, Unternehmen haben das jetzt entdeckt und müssen sich natürlich auch transformieren in diese Richtung, aber man versucht beide Welten zu vermischen, wie zum Beispiel früher wusste ich, wann, wann, wann ich die Software haben kann, zu welchem Preis, wie viel Tage es dauert. Und im Scrum ist es halt nicht vorhersagbar, sondern du hörst, nach jedem Spin kannst du rein theoretisch aufhören.

Das war auch früher ehrlich gesagt nicht vorhersagen, aber gab es auch eine Zahl draufsteht und ein Datum und aber. Aber trotzdem konnte ich eine gewisse Wahrscheinlichkeit, dass weil sich da viele Leute mit beschäftigt haben und die Anforderungen relativ klar waren oder festgeschrieben wurden. Okay, das kommt dann und dann raus. Also du hattest auch viel mehr Informationen als du jetzt hast. Dass sie dann hinreichend ungenau waren und das nicht funktioniert hat, sei mal dahingestellt, aber man versucht dieses beizubehalten.

Das heißt, ich habe so oft erlebt, man fängt gerade als Schreibprojekt an und da steht schon jemand da und fragt Wie lange dauert das Masiar? Ich schätze doch mal bitte ab. So, dann erklärst du ja, aber in Scrum schätzt man ja keine Tage auf, sondern wir schätzen ja Komplexität Punkte ab. Und mit der Zeit finden wir heraus oder kriegen ein Gefühl dafür durch Birnen und Charts, wie schnell wir vorwärts kommen und wie viele Tickets wir innerhalb von einem Sprint umsetzen können.

Das versteht man nicht, dass mensch versteht das nicht, dass versucht immer noch so ich. Es gibt sogar ohne Ende Projekte wirklich, wo diese Schätzungen, diese Fibonacci Reihe Schätzungen als Tage gedeutet werden und sich auch so etabliert haben, dass man damit Tage meint. Und das hat sich so schleichend rein interpretiert, weil das Menschen immer wissen will wann. Wann ist es so weit? Und da finde ich es im Moment echt Chaos. Da vermischen sich zwei Konstrukte, die nicht zusammengehören und das machen auch die Teams nicht glücklich, weil sie das sind die Dinge womit du Teams glücklich machen kannst und nicht so so wischiwaschi Dinge und Spielchen und Spielchen da.

Natürlich will das Management irgendwann wissen, die haben ja ihren klassischen Zeitplan, wann ist es fertig? Aber dann kann man ja sagen Alle zwei Wochen kriegst du immer nach dem Sprint eine kriegst und kommt zu der kommt zu dem Review. Guck an, ob es genug ist für das, was ihr damit vorhat. Und dann kann es direkt gelesen an dem Tag, wo du sagst Jetzt ist alles drin zu lesen. Natürlich ist mir auch klar, dass das Management gerade das höhere Management, das arbeitet natürlich mit Projekt, Plänen und Zeitplan und die müssen das wissen oder die würden das gerne wissen, aber im Grunde sind die alten Wasserfall Pläne ja genauso oder noch viel unzuverlässiger gewesen.

Also da muss man sich einfach dran gewöhnen, dass man sagt wir legen jetzt los. Wir schätzen, dass es ein halbes Jahr dauern wird, aber alle zwei Wochen machen wir eine Bestandsaufnahme und gucken, wie weit wir sind. Was ich glaube, was in dieser Welt ganz, ganz schwierig geworden ist. Also ich möchte jetzt hier gar keine Dystopien aufmachen, oder? So ist dieses Thema Fokus halten. Überall entstehen neue Tools, neue Methoden, Ablenkung, überall.

Es gibt eine neue Methode, wie man dies macht, wie man das macht. Hier ein neues Tool, da ein neues Tool an allen Ecken und Enden. Und du musst dir du musst im Grunde jeden Tag dich hinsetzen. Wie so eine sture Eisenbahn fährst du deine Schienen runter um und die Schienen münden auf dieses Unternehmensziel, was klar kommuniziert ist, um schnell ans Ziel zu kommen und eben dann auch die gewünschte Software zu liefern oder den gewünschten Business Wert dann liefern zu können oder heben zu können mit der Software.

Also ich glaube, desto größer das Projekt, desto schwieriger wird das. Weil natürlich auch die Unternehmen verändern sich, werden gekauft, verschiedene Helm und Ölgeschäfte wirbeln ganze alte Landschaften durcheinander. Und das ist auch von Management Sicht, muss man ehrlich sagen. Auch wenn ich natürlich eher auf der technischen Seite bin. Natürlich eine Herausforderung, das alles unter einen Hut zu kriegen. Was mir noch wichtig wäre Jetzt haben wir dem Management gesagt Okay, kommuniziert klar eure Ziele, dann können wir als Techniker können uns darauf ausrichten und können diese Ziele fokussieren.

Was können wir denn den Entwicklern geben? Was bedeutet professionelle Softwareentwicklung für Entwickler? Also ich habe mir mal so ein paar Gedanken gemacht, die ich denke, die die Kernthemen ganz gut treffen. Und zwar würde ich jedem Entwickler oder Techniker sagen Bei allem was ihr tut, konzentriert euch auf die Erreichung der Unternehmensziele mit der Softwareentwicklung, die ihr gerade macht. Schreibt nur Komponenten, die dieses Ziel versuchen zu erfüllen. Hinterfragt euch jeden Abend habe ich das, was ich heute gemacht habe, zahlt das auf dieses Ziel ein?

Unterstützt meine Software oder das, was ich heute erstellt habe, diese Ziele jetzt besser? Oder bin ich da irgendwie weitergekommen? Also wirklich diesen Fokus zu halten, um diesen Fokus zu halten, würde ich persönlich versuchen, so wenig Code wie möglich zu schreiben. Weniger Code heißt oft weniger Fehler, weniger Wartung. Der wenige oder nicht geschriebene Code muss von niemandem sonst gelesen werden. Weniger Zeitaufwand. Ich muss keine Tests schreiben. Ich muss nicht unnötig unnötig geschriebenen Code lesen.

Von anderen Entwicklern vielleicht, sondern wirklich wenig Code. Deutet Beschäftige dich erst mal relativ lange auf dem Papier. Wie könnte eine Lösung aussehen und macht dir Gedanken über das Problem, was du zu lösen versucht? Das ist für mich immer ganz wichtig, weil desto mehr ich mich mit dem Problem beschäftige, desto klarer wird eigentlich schon die Lösung. Es gibt dieses berühmte Zitat Ich weiß gar nicht, wer es gesagt hat. Wenn ich 5 Stunden Zeit hätte, einen Baum zu fällen, würde ich 4 Stunden und 50 Minuten darauf verwenden, die Axt zu schärfen, um dann mit einem Schlag sozusagen den Baum direkt zu fällen.

Weil wenn die Axt messerscharf ist, braucht es nur einen Schlag. Und hier ist es so ähnlich. Wenn ich viel mit dem Problem beschäftigt habe, dann wisst ihr irgendwann, wie das Problem zu lösen ist und dann ist es wird die Lösung klar oder was? Offensichtlich und man kann mit sehr wenig Code direkt das Ziel treffen.

Das hat Lincoln gesagt.

Übrigens nehmen wir das einfach mal so. Aber ich weiß es wirklich nicht. Habe ich ein paar Mal gelesen. Okay, okay, dann ist es von Abraham Lincoln gut, dann habe ich auch kein Copyright Problem. Die Botschaft ist ganz klar Verbringe viel Zeit damit nachzudenken. Wie könnte die Loewy, wie sieht das Problem aus und wie kann man das angehen? Und dann wird die Lösung relativ offensichtlich und man kann sie sehr präzise formulieren. Nächster Punkt ist die Verwendung von STANDARD Komponenten.

Ich weiß, dass es gerade bei Entwicklern, die neue Dinge ausprobieren wollen, ein Thema, aber ich kann wirklich empfehlen, nutzt Patch Libraries oder Java Collections oder STANDARD Komponenten, die in 100000 Projekten bereits erfolgreich eingesetzt werden können. A Kennen die Leute, die also eure Entwickler, Kollegen und ihr selber habt sie vielleicht schon mal in Projekten eingesetzt? B Wenn darin Fehler auftauchen, also erst erstmal, ist es sehr unwahrscheinlich, dass da drin Fehler auftauchen und wenn, dann kann man sie mit einem einfachen Update beheben.

Und es ist einfach sinnvoll, gängige STANDARD Komponenten für STANDARD Aufgaben zu verwenden und dann nicht so viel Gehirnschmalz zu investieren, weil das schon viele viele tausende Software Ingenieure vorher alles gegeben haben und man da eine super hohe Qualität einfach nutzen kann, die man selber sehr schwer erreichen kann. Ein weiterer Punkt ist, das spielt eigentlich in die wenig wie möglich Regel ein, die Komplexität so gering wie möglich zu halten. Ganz oft fällt mir das auf. Jetzt mit den neuen oder neuen.

Die gibt es auch schon einige Jahre, aber sie setzen sich zunehmend überall durch diese Lambda Ausdrücke. Klar, da gibt es einen Einzeiler und dann sagt man Ja, das ist ein Einzeiler, aber da muss man nicht jeden Buchstaben vorsichtig lesen, um zu verstehen, was geschieht denn da überhaupt? Ich weiß nicht. Hast du mal diesen diese Debugging genutzt? Diese Flow wurde dann bei jedem Schritt so einhaken kannst. Und dann, wenn ich sehe, da hat der Lambda Ausdruck, hat 14 Steps mit Filter, Kriterien und so weiter.

Blickst du nicht mehr durch, kann es nicht mehr.

Klar steht er in einer Zeile und er kann nicht sagen das ist wenig Code. Aber vielleicht könnte man diesen Ausdruck auch in drei Zeilen aufteilen oder in drei Zwischenschritte aufteilen. Und der Compiler filtert das hinterher eh weg. Also der das wird nicht langsamer.

Wenn das dann kompiliert wird.

Aber man kann es einfach besser lesen, dass man sagt Okay, hier bereitet seine Liste auch vor, hier sortierte und gruppiert er sie nach gewissen Kriterien und am Ende wird sie vielleicht noch mal im YouTube gemacht oder so was. Und du hast nicht diesen riesen Block vor der Nase, wo man sagt Boah, okay, da muss ich jetzt erst mal zwei Minuten lesen und verstehen, was hier überhaupt passiert, weil am Ende kommt dann ein Treffer raus.

Ich kann es auf einen Satz reduzieren. Man muss nicht jeden neuen Scheiß ausprobieren, sondern kritisch nachdenken Was bringt das mir? Oder was bringt das dem Unternehmen oder dem was? Liegt es am Wert der Software bei? Und dann erst einsetzen oder vorher natürlich mit den Kollegen diskutieren statt ausprobieren, nur weil es jetzt irgendwo drei Mal erscheint, irgendwo im Englischen Nachrichten.

Wenn es eine neue Technologie gibt, die genau dieses Problem löst, an dieser Stelle, wo man steht und das hat man ja schon beim drüber nachdenken wie löse ich dieses Problem hat man ja oft schon erkannt. Also wie ist dieses Problem gelagert? Dann kann man durchaus hier und da natürlich auch neue Dinge ausprobieren, aber nicht einfach, weil man gestern Artikel gelesen hat auf dieser Ebene oder so was, das jetzt der neue Logger etwas viel besser kann. Und dann baut man alle Slovakei Logs auf, Apache log um oder so was.

Oder wenn man es überall macht, dann wäre es ja noch ok, aber man macht es dann in seiner Klasse so ungefähr und probiert mal in seiner eigenen Klasse das neue Logging aus, weil das irgendwie cooler Coding hat oder so was. Und das wird auch ganz toll, so dass wie gesagt, wenn man das macht Proof of Concept machen und dann vorschlagen das komplett durchzuziehen. Aber ansonsten sich erst mal an die Linie halten und möglichst am STANDARD orientieren. Es muss schon ein wirklicher Mehrwert entstehen, damit man eben Refactoring durchführt oder eine neue Komponente mit einbringt.

Und was ich auch immer ganz, ganz wichtig finde, ist und das ist ein Appell an alle Entwickler da draußen Wenn ihr ein Refactoring macht von irgendwas, dann seid ihr verantwortlich dafür, dass das hinterher genauso funktioniert wie vorher. Also wenn ihr sagt, ich reflektiere das jetzt, dann ist das euer Job zu sehen, dass ihr nichts kaputt macht, weil das ist auch ganz, ganz häufig. Kommt das vor? Und damit meine ich nicht unabsichtlich irgendwas kaputt zu machen, verstehe ich.

Passiert passiert mir auch, gar keine Frage. Alles gut, aber die Verantwortung liegt ganz klar bei demjenigen, der es dann angefasst hat.

Bei mir ist es immer so, ich versuche dann durch Tests sicherzustellen, dass ich nichts kaputt gemacht habe. Also das nach dem Refactoring alles funktioniert wie vorher. Dass ich auch ein Ende zu Ende Test gemacht habe. Dass ich sagen kann ja ich habe mal Unit Tests laufen Ende zu Ende hat sich auch nichts verändert und wenn man die abfragt, kriegt man die gleichen Antworten. Aber was ganz wichtig ist ist, wenn du ein Refactoring machst, hast du die Verantwortung für dieses Refactoring.

So lange, bis wieder alles funktioniert wie vorher und du niemanden vor den Kopf gestoßen hast, damit im Sinne von die API bricht oder andere Komponenten können nicht mehr darauf zugreifen. Das ist immer ein Parameter bei einer Methode hinzufügst oder wegnimmst. Dann können vielleicht einige Teamkollegen nicht mehr oder laufen deren Systeme nicht mehr oder deren Software nicht mehr, dann bist du dafür verantwortlich, das eben richtig zu stellen. Das ist ganz wichtig.

Meiner Ansicht nach ja genauso.

Oder was ich beobachtet habe damit dann Refactoring gemacht, dann funktioniert irgendwas nicht mehr und dann wird dann argumentiert Ja, aber so ist das ja viel besser. Aber jetzt funktioniert meine Bibliothek XY nicht mehr, die sich darauf verlässt, auf den alten Weg oder so was. Und dann wird da diskutiert. Ja, wer ist jetzt dafür verantwortlich, diese alte Bibliothek zu updaten oder anzupassen oder so was? Meiner Ansicht nach liegt das in der Verantwortung der Person, die das Ding macht oder beginnt.

Und das muss klar geregelt sein, damit man nicht in so einer Zuständigkeit Vakuum gelingt und sich keiner mehr verantwortlich fühlt. Und dann schiebt man sich die Schuld hin und her. Also es muss einfach klar sein, wenn ich etwas reflektieren möchte und etwas verbessern möchte, was ja total begrüßenswert ist, dann muss ich dafür Sorge tragen, dass hinterher alles okay ist. Sogar Linus Torvalds bei der Kernel Entwicklung hat eine goldene Regel We don't break user space. Wenn sich User Space Programme auf irgendwelche Bugs verlassen, die mal im Kernel drin waren, dann wird der Bug gefixt.

Aber dennoch wird das Verhalten so emuliert, wenn diese alten Methoden aufgerufen werden, damit die Programme weiterlaufen und man nicht ganze Kaskaden von Tools, die über 10 Jahre entwickelt wurden, um schmeißt. Und ich denke, das ist eine ganz wichtige Regel zum Thema Verantwortung. Wenn du ein Refactoring machst, hast du die Verantwortung, dass das sauber ist.

Hast du da vielleicht noch eine Ergänzung zu Jetzt habe ich so viel geredet?

Im Grunde nicht.

Was ich für mich selber beherzige, ist nicht Versuch wirklich möglichst jede neue Technologie, die die aufkommt, mir anzugucken, einen Artikel drüber zu lesen, damit ich weiß, wie ich es einordnen kann und wo ich es einsetzen kann, damit ich einfach mitreden will. Wenn, wenn, wenn ich es irgendwo höre, bei einem Kunden, der das einsetzen will oder wie auch immer. Ich möchte wissen, worum es geht. Und das ist zwar sehr anstrengend, weil man ja sehr viel lesen muss und Dinge, die mir vielversprechend erscheinen und wo ich meine, diese haben eine höhere Halbwertszeit als eine Woche, dann arbeite ich gerne auch mal ein Tutorial durch oder versuche selber was umzusetzen, um so ein bisschen zu gucken wie Wie fluffig läuft das und welchen Mehrwert bringt das wirklich?

Und je länger du das machst, desto weil viele diese Technologien bauen aufeinander auf und dann kannst du Sachen, die dazukommen, viel schneller mit einem Blick einordnen. Und das ist so im Prinzip mein Vorgehen, um ich sage mal als Berater am Markt bestehen zu können, ohne schon mal den größten Mehrwert zu liefern. Und ich bin immer noch alte Schule. Tatsächlich man dadurch, dass ich auch Unternehmer bin, versuche ich diese Technik und dieses von Wert sein zusammenzubringen und mir nichts unnötiges zu machen, sondern wirklich Technologie dort einzusetzen, wo ich mir Arbeit erleichtert, vereinfacht und automatisiert.

Wie gesagt, Software ist kein Selbstzweck, sondern optimierte Prozesse, die du ohnehin wird oder ermöglicht. Werte, so eine Online Webseite oder eine Antrag Strecke ist ja natürlich auch ein Wert, den du ohne diese Technologie nicht hättest. Ja super. Also vielleicht noch mal unser Appell an die Unternehmen, die Manager, die Product Owner. Bitte kommuniziert klar eure Unternehmensziele, welche mit der Software, die wir bauen erreicht werden sollen. Im gerne mantra, artig und gerne mehrfach, um immer wieder die Leute daran zu erinnern.

Und an die Entwickler geht der Ruf raus Hinterfragt durchlaufende, ob eure aktuelle Arbeit auf das Ziel einzahlt, was eben kommuniziert wurde. Wenn ihr technische Schulden im Zuge von Refactoring beseitigt, geht die Verantwortung automatisch auf euch über. Für die korrekte Funktion des Refactoring ist das finde ich ganz wichtig. Und vielleicht noch mal zu dem Thema Wie bilde ich mich denn weiter? Oder wie setze ich neue Technologien ein? Ich mache es im Prinzip ähnlich wie du Masiar. Ich lese auch viel quer und schau mir die Sachen dann an Bei mir ist es dann so, wenn ich in der Vergangenheit ein Problem hatte und ich lese von einer Technologie, die imstande ist, dieses zu lösen, also Skalierbarkeit, Problem oder einfach eine Software, die ein Problem besser löst, dann interessiert mich das ganz besonders und ich schaue es mir intensiver an und ich versuche diese Ökosysteme zu verstehen.

Also zum Beispiel Node. JS und i pm not package Manager Wenn man sich das mal anguckt, dann funktioniert das im Prinzip. Also was PM für die Node.js Welt wäre Maven zum Beispiel in der Java Welt oder es gibt auch diese Packages für dort net oder diese Reports für dort net, wo man auch da dann einfach die Dependency einbinden kann und die automatisch runtergeladen werden können. Und die Konzepte sind oft, die verändern sich nämlich Gott sei Dank nicht so häufig und die Technologien dahinter sind es nur.

Und dann versuche ich so ein bisschen herauszuschälen. Was ist das? Ein neues Konzept? Oder ist das einfach nur eine technische neue Technologie, die ein altes Konzept neu umsetzt? Und was entstehen dafür? Vorteile raus? Also mein Lieblingsbeispiel ist, da hatte vor einigen Monaten jemand den Con Styling Dienst, den es sieht. Ich möchte mich jetzt nicht so weit aus dem Fenster lehnen, aber bestimmt seit den 70er Jahren. Gibt auf Unix System hatte den jemand in JavaScript nach implementiert und als ein PM, also als Node Package hinterlegt und das wurde auch benutzt von einigen Projekten muss man.

Das ist halt die Frage muss man das? Ergibt das einen Sinn in der Konstellation? Irgendjemand scheint das ja für sinnhaft gehalten zu haben und dieses Paket gebaut zu haben. Aber das ist ein ganz klarer Fall von alter Wein in neuen Schläuchen. Dieses Konzept des Scheduler ist, dass es 50 Jahre gibt, eben auf eine neue technologische Plattform gehoben. Und wenn man schon verstanden hat, dann kann man auch so fortfahren in der Welt oder in der JavaScript Welt verstehen, was diese Komponente macht und muss sich da nicht weiter damit beschäftigen, sondern weiß, dass ist einfach nur eine andere technologische Umsetzung.

Ist ja super, freut mich sehr schön, dann bedanke ich mich ganz herzlich bei dir Masiar sehr gerne unsere Zuhörer frage ich noch mal, wenn ihr Feedback habt zu der Episode, sendet gerne eine E-Mail an Podcast skillbyte und hinterlasst uns auch sehr gerne eine positive Bewertung oder abonniert den Podcast, damit wir euch auch zu anderen Themen auf dem Laufenden halten können. Oder wenn ihr möchtet, könnt ihr auch auf Skillbyte Island Blog vorbeischauen, wo wir interessante Artikel zu diversen Themen aus der IT-Welt veröffentlichen.

Masiar Ich möchte mich ganz herzlich bei dir bedanken. Du hast schon zum achten Mal mein Gast.

Bist du sehr gerne.

Vielen, vielen Dank. Danke dir. Bis bald.

Bis bald. Tschüss. Tschüss.