Ach ja, der typische Lebenslauf eines Utility tools. 1. Schreib ein tool, was "ausser dir eh keiner verwendet." 2. Tool wird erfolgreich 3. Mach Anpassungen, weil andere Mitarbeiter natürlich feedback geben. 4. Der Spagetti Code wird immer länger. ... Rinse, Repeat Schritt 3 und 4 .... Nerfenzusammenbruch. ..... Rewrite in Rust Das zeigt eigentliche 2 große Dinge in der Software - Entwicklung. 1. Planung und klare Projekt-Anforderungen sind WICHTIG. 2. Nur weil etwas funktioniert, heißt das nicht, dass es Production-Ready ist.
Ich arbeite in einem Unternehmen, welches in einem engen Markt ein ERP System baut und dachte schon, ich wüsste, welches ERP da gemeint ist. Wir haben da einen Konkurrenten, der quasi den Markt dominiert und wo die Kunden immer gerne zu uns überlaufen 😁. Scheint aber doch eine andere Branche gemeint zu sein. Unabhängig davon kann ich bestätigen, dass das Thema Architektur und Skalierbarkeit viel zu selten als wichtig (oder greifbar) angesehen wird. Häufig ist die Skalierbarkeit ja auch eine Kombination aus vielen einzelnen Stellrädchen und ein Zeitlang ist es dann noch skalierbar, bis man das Limit erreicht und dann mit der verwendeten Technologie nicht mehr weiter kommt.
Wow..genau in dieser Situation habe ich an meiner aufgabe gesteckt...und es hat wirklich keinen spass mehr gemacht zu arbeiten. Aber das problem wurde erkannt und wir räumen nun auf es läuft wirklich besser
Leider schonmal erlebt. 2 Jahre an einem Projekt ohne Architekt gearbeitet. Die Entwickler des Teams hatte sehr unterschiedliche Skill-Level. Nach einem Jahr an den Vorgesetzten alle Probleme und absehbaren Folgeprobleme eskaliert. Kein Feedback. Nach 2 Jahren aus Frustration gegangen und mich wahrscheinlich vor frühzeitigen Ergrauen bewahrt 😂 Übrigens: Ich wollte gerade klugscheißern und mitteilen, dass das S in MES bereits für System steht. Daher wäre MES-System doppelt gemoppelt. Scheint sich aber, wenn man mal kurz die Suchmaschine anwirft, etabliert zu haben.
Der Architekt ist nicht immer der Problem. Interessant wird es z. B Personen Architekturentscheidungen treffen, die keine Erfahrung in der Informatik haben.
@ Bei uns dauert die Planung einer öffentlichen Einrichtung nun schon knapp 8 Jahre - es kann viel schief gehen noch überhaupt vor dem ersten Spatenstich :D
Bei einem Haus wird aber nicht mit einer Hütte in Wald angefangen, die zum unterkellerten Einfamilienhaus aufgestockt wird und am Ende ein Wolkenkratzer sein soll. Eine Software die auf 10 User ausgelegt ist für 100 oder 1000 fit zu bekommen mag noch funktionieren, spätestens bei der Million wird es nicht klappen. Habe ich eine Anwendung für einen usecase und will die für einen ähnlichen aber anderen erweitern muss nochmal so viel Zeit eingeplant werden wie für den ersten. Hier muss das Fundament gebaut werden, nur so sind weitere usecases dann günstiger umzusetzen. Plant man direkt das Fundament vom Wolkenkratzer mit den Anforderungen der Holzhütte ist das Fundament komplett ungeeignet und viel zu teuer. Es braucht im seltensten Fall Abstraktionen wenn es danach nur eine konkrete Ausprägung davon gibt, das muss dann eingebaut werden, wenn man weiß was die konkreten Anforderungen sind und dann auch nur zum Lösen vom konkreten Problem.
Ich glaube es hilft einfach grundsätzlich mit Profis zu arbeiten, oder? 😂 Ob Architekt, Requirements Engineer oder UX Professional: wenn man versucht mit nem ehemaligen Polizisten, ner ehemaligen Krankenschwester und ner Teilzeit Tierpflegerin ein Krankenhaus zu bauen, kommt da vielleicht eine Abdeckstation für Tierkadaver bei raus, aber Kein Ort, an dem Menschen Heilung erfahren können. Und egal ob man ein Krankenhaus oder ein ERP System baut, ohne gut bezahlte und erfahrene (wertvolle!) Profis kommt da nichts gescheites bei raus. Manchmal merkt man das früher, meistens aber wenn es zu spät ist. Lehrgeld ist teuer, und wer billig kauft, kauft zweimal :-)
Komisch, Quereinsteiger mit Erfahrung sind meistens eher die, die saubere Arbeit leisten und lernwillig sind. Die Leute, die ein meist eher nutzloses Papier von irgender FH oder schlimmer noch Uni an der Wand hängen haben, sich dann darauf ausruhen, sind nicht die, die man sich wünscht, obwohl diese auf dem Papier ja Profis sind. Es kommt drauf an, den Job erledigt zu bekommen, was vor 10 Jahren war, interessiert keinen ernsthaft. Das müssen ein paar in den 1990ern hängengebliebene Personaler noch hart lernen, aber die schreiben Ihre Stelle ja auch nicht wegen Unfähigkeit selbst neu aus.
@ ich hab auch nichts gegen Quereinsteiger, ich würde aber von jemandem, der schon 10 Jahre entwickelt auch nicht mehr von Quereinsteiger oder Neuling sprechen. Vermutlich habe ich zu oft in prekären Projekten gearbeitet, in denen aus Geiz und oder Dummheit billige frisch “qualifizierte” Quereinsteiger eingestellt wurden, weil die ja lernfähig und fleißig sind. Dann war die Katastrophe schnell passiert… oder auch “Ich stell lieber drei Juniors als einen Senior ein, die gegen keine Widerworte und machen was man von ihnen will…”
Wow, was genau ist denn an XML veraltet!? XML ist doch robust und eher zeitlos. (Also ich lasse mich natürlich gerne von Gegenteil überzeugen, wenn es so ist.)
XML braucht relativ viel Platz, ist schwer zu lesen und die XML frameworks sind nicht die effizientesten teilweise (Speicherverbrauch, CPU). Jede Nachricht enthält immer auch die Struktur (doppelt mit öffnendem und schließendem Element), während es Datenformate gibt, in der Struktur und Payload getrennt sind - das spart extrem viele Bytes im Netzwerk. Aber selbst JSON oder YAML sind vergleichsweise schlank und meist lesbarer. XML hat natürlich schon seinen Wert, aber es ist schon deshalb veraltet, weil es einfach nicht mehr eingesetzt wird in den meisten Schnittstellen - sei es aus gutem Grund oder schlicht aus "Trend". Allein 15-30% eingesparte byte auf der Netzwerk Rechnung sind halt z.B. ein Argument, das schwer wegzuwischen ist. Und die Byte müssen dann ja auch gelesen und verarbeitet werden - millionenfach oder milliardenfach.
@@vanivari359 Ich würde es nicht gleich als "veraltet" bezeichnen. Ja, gerade wenn etwas sehr oft gelesen/geschrieben werden soll, ist bspw. Json >>meistens
Hey, vielen Dank für die Antworten. Das Argument der fehlenden, modernen Tools ist für mich tatsächlich der plausibelste Grund. Ansonsten würde ich XML aber trotzdem nicht alles veraltet ansehen. Ich arbeite mit WPF und damit auch mit XAML. CSPROJ sind auch XML Dateien und bald auch Visual Studio Solutions (SLNX könnt hoffentlich bald). Ganz zu schweigen von den elektronischen XML Rechnungen, die ja auch gerade aktuell sind.
7:02 ohne unsere (interne) ERP Software läuft so gut wie nichts mehr in der Firma. Wenn unsere Software heute ausfallen würde, dann gehen wir einfach auf den Stand von vor dem Update zurück. Software fällt nicht ohne Grund aus. Es sei denn die Infrastruktur zickt rum aber dann liegt es nicht an der Software.
Du solltest Refactoring nicht mit einem Rebuild in einen Topf werfen. Refactoring dauert üblicherweise 30 Sekunden, 30 Minuten oder auch mal 3 Stunden und sollte fortwährend von Entwicklern durchgeführt werden. Wenn man ein Jahr lang daran herumdoktort, die Software zurück in einen erweiterbaren Zustand zu bringen, ist Refactoring nicht der beste Begriff dafür.
Da haben wir mehr oder weniger den Vorteil, dass unsere Software sowohl intern als auch extern genutzt wird. Dadurch kam bei uns keiner auf die Ausrede "Ist doch nur intern.."
Das ist doch unmöglich pauschal zu sagen, sondern kommt auf das System an. Bei mir ist Refactoring ein Teil der täglichen Arbeit. Wenn dann eine Anforderung kommt, die so nicht "elegant" zügig umgesetzt werden kann, sondern wenn dann grob zusammengehackt und übergestülpt werden müsste, nehme ich mir lieber die Zeit, das System so umzustrukturieren, dass es zügig geht. Frei nach Kent Beck: "To make a hard change, first make the change easy, and then make the easy change"
@@DagarCoH Refactoring bringt nur etwas, wenn du die Fehler siehst. Meist aber funktioniert alles am Anfang extrem gut. Erst mit der Zeit entstehen dann Probleme. Manche sind einfache Bugs. Das ist aber nicht immer so. Zwei Entwickler haben eine gemeinsame Vorgabe unterschiedlich umgesetzt. Schnittstellen werden nicht verstanden. Oder, Oder... Es gibt unzählige Möglichkeiten technische Schulden zu produzieren. Einmal wurde ich ich in Projekt als Externer eingestellt, weil das Team Probleme mit den Code hatte. Im Endeffekt hatten alle Schnittstellen durch ein Architekturfehler ein Memory Leak. Der Bug war so schwerwiegend, dass eine Neuentwicklung einfacher war. Im Endeffekt sollte man sich nie zu sicher in einen Projekt fehlen. Bugs können immer passieren.
Möglicherweise weil häufig Leute Softwareprojekte "steuern", die sich nicht für Softwareentwicklung interessieren und unter agiler Entwicklung Planlosigkeit verstehen.
@@lukasbacker5263 musste richtig lachen (und weinen), weil sich das nach meinem AG anhört :D aber hey, man macht das Beste draus, aber ich stehe als neuer Mitarbeiter (dem der Zustand nicht transparent kommuniziert wurde) ganz bestimmt nicht dafür gerade.
@@communityyoumustseekyoungp5630 Ungefähr so ging's mir vor paar Jahren aus, ich hab nach ca. einem 3/4 Jahr gekündigt, Kündigung zum Quartal hat mich aber noch 1/4 Jahr dort gehalten. Dort war es genauso, nur dass ein leitender Entwickler (nicht Mal ein Laie) mir einmal erklären wollte, was agile Entwicklung wirklich sei und dass diese Firma es richtig macht - bis auf die Tatsache, dass es weder SCRUM (wie behauptet wurde) noch Agil ist, sondern einfach nur Planlosigkeit mit fancy Namen :D Solche Projekte scheitern einfach immer.
Wir haben aktuell noch immer Software am laufen, die so alt ist, dass Hollerith Konstanten da noch eine technische Neuerung war. Die wurde über 60 Jahre weiterentwickelt, meistens von Mitarbeitern, die sich selbst zuhause im Keller per Zeitschrift Fortran beigebracht haben - denn Programmierer wurden und werden von der Managerebene selten als echte Berufsgruppe wahrgenommen und da lässt sich dann ja ganz gut laufende Kosten sparen; Einfach irgendwen machen lassen, den man ohnehin schon bezahlt. Schließlich war nur noch einer der Mitarbeiter im Unternehmen. Da dieser ja weiß, wie die Software ungefähr funktioniert, brauchte es auch nie eine Dokumentation. Auch hat es ja meistens funktioniert, also brauchte es auch keine automatischen Tests. Die abgebildete Business-Logik wurde auch niemals genauer definiert als der Code selbst; "Wir wissen ja, was wir hier machen". Das gesamte Herangehen an diese Sofware war über ihre gesamte Lebensdauer also von jeder Seite her nachvollziehbar - ist jetzt allerdings in einem Zustand, der uns immer lachen lässt, wenn ein JavaScript-Entwickler sich über "Legacy" beschwert :) So baut man technische Schulden auf.
Das Hauptproblem sind Manager, die nach drei Jahren immer noch derselben Tätigkeit nachgehen und daher keine guten Manager sind. Und Entwickler, die nicht in der Lage sind, Entwurfmuster zu verwenden. Und POs, die keinen Plan von dokumentationsgetriebener Entwicklung haben. Das betrifft leider alle Firmen in Deutschland. 🤷♂️
Das Video ist in weiten Teilen anekdotisch und nutzt Beispiele aus realen Projekten, um eine Argumentation für die Wichtigkeit von Architektur und Design aufzubauen. Die Kernbotschaft lautet: Unternehmen sollten Experten wie ihn engagieren, um von Anfang an hochwertige Softwarearchitektur zu gewährleisten. Ein typisch deutsches TH-cam "Ratgeber"-Video eben, wo der Ersteller sich primär als Problemlöser und Experte positionieren möchte.
Ist schon frustrierend dass ich bei jedem deiner Videos feststelle "Huh...das machen wir nicht. Kein wunder dass es so schlecht läuft"
Ach ja, der typische Lebenslauf eines Utility tools.
1. Schreib ein tool, was "ausser dir eh keiner verwendet."
2. Tool wird erfolgreich
3. Mach Anpassungen, weil andere Mitarbeiter natürlich feedback geben.
4. Der Spagetti Code wird immer länger.
... Rinse, Repeat Schritt 3 und 4
.... Nerfenzusammenbruch.
..... Rewrite in Rust
Das zeigt eigentliche 2 große Dinge in der Software - Entwicklung.
1. Planung und klare Projekt-Anforderungen sind WICHTIG.
2. Nur weil etwas funktioniert, heißt das nicht, dass es Production-Ready ist.
Ich arbeite in einem Unternehmen, welches in einem engen Markt ein ERP System baut und dachte schon, ich wüsste, welches ERP da gemeint ist. Wir haben da einen Konkurrenten, der quasi den Markt dominiert und wo die Kunden immer gerne zu uns überlaufen 😁.
Scheint aber doch eine andere Branche gemeint zu sein.
Unabhängig davon kann ich bestätigen, dass das Thema Architektur und Skalierbarkeit viel zu selten als wichtig (oder greifbar) angesehen wird. Häufig ist die Skalierbarkeit ja auch eine Kombination aus vielen einzelnen Stellrädchen und ein Zeitlang ist es dann noch skalierbar, bis man das Limit erreicht und dann mit der verwendeten Technologie nicht mehr weiter kommt.
Wow..genau in dieser Situation habe ich an meiner aufgabe gesteckt...und es hat wirklich keinen spass mehr gemacht zu arbeiten. Aber das problem wurde erkannt und wir räumen nun auf es läuft wirklich besser
War das Wortspiel bei 14:43 Absicht? O.O
Nein, ist mir nicht mal beim editieren aufgefallen.. oh Gott 😂
@@DavidTielke Dann ist das womöglich eine Neuschöpfung :D Nehme ich auf jeden Fall in meinen Sprachschatz auf
Leider schonmal erlebt. 2 Jahre an einem Projekt ohne Architekt gearbeitet. Die Entwickler des Teams hatte sehr unterschiedliche Skill-Level. Nach einem Jahr an den Vorgesetzten alle Probleme und absehbaren Folgeprobleme eskaliert. Kein Feedback. Nach 2 Jahren aus Frustration gegangen und mich wahrscheinlich vor frühzeitigen Ergrauen bewahrt 😂
Übrigens:
Ich wollte gerade klugscheißern und mitteilen, dass das S in MES bereits für System steht. Daher wäre MES-System doppelt gemoppelt. Scheint sich aber, wenn man mal kurz die Suchmaschine anwirft, etabliert zu haben.
Hab das Video gerade erst angesehen und würde erstmal sagen: Feature Creep.
Ein Haus wird ja auch nicht ohne Architekt gebaut. Sehr gutes Video zum Thema.
Es gibt auch genügend Architekten, die pfuschen, oder Fertighausanbieter, wo das Ding in die Hose geht..
Der Architekt ist nicht immer der Problem.
Interessant wird es z. B Personen Architekturentscheidungen treffen, die keine Erfahrung in der Informatik haben.
@ Bei uns dauert die Planung einer öffentlichen Einrichtung nun schon knapp 8 Jahre - es kann viel schief gehen noch überhaupt vor dem ersten Spatenstich :D
Bei einem Haus wird aber nicht mit einer Hütte in Wald angefangen, die zum unterkellerten Einfamilienhaus aufgestockt wird und am Ende ein Wolkenkratzer sein soll.
Eine Software die auf 10 User ausgelegt ist für 100 oder 1000 fit zu bekommen mag noch funktionieren, spätestens bei der Million wird es nicht klappen.
Habe ich eine Anwendung für einen usecase und will die für einen ähnlichen aber anderen erweitern muss nochmal so viel Zeit eingeplant werden wie für den ersten. Hier muss das Fundament gebaut werden, nur so sind weitere usecases dann günstiger umzusetzen.
Plant man direkt das Fundament vom Wolkenkratzer mit den Anforderungen der Holzhütte ist das Fundament komplett ungeeignet und viel zu teuer.
Es braucht im seltensten Fall Abstraktionen wenn es danach nur eine konkrete Ausprägung davon gibt, das muss dann eingebaut werden, wenn man weiß was die konkreten Anforderungen sind und dann auch nur zum Lösen vom konkreten Problem.
Ich glaube es hilft einfach grundsätzlich mit Profis zu arbeiten, oder? 😂 Ob Architekt, Requirements Engineer oder UX Professional: wenn man versucht mit nem ehemaligen Polizisten, ner ehemaligen Krankenschwester und ner Teilzeit Tierpflegerin ein Krankenhaus zu bauen, kommt da vielleicht eine Abdeckstation für Tierkadaver bei raus, aber Kein Ort, an dem Menschen Heilung erfahren können. Und egal ob man ein Krankenhaus oder ein ERP System baut, ohne gut bezahlte und erfahrene (wertvolle!) Profis kommt da nichts gescheites bei raus. Manchmal merkt man das früher, meistens aber wenn es zu spät ist. Lehrgeld ist teuer, und wer billig kauft, kauft zweimal :-)
Komisch, Quereinsteiger mit Erfahrung sind meistens eher die, die saubere Arbeit leisten und lernwillig sind. Die Leute, die ein meist eher nutzloses Papier von irgender FH oder schlimmer noch Uni an der Wand hängen haben, sich dann darauf ausruhen, sind nicht die, die man sich wünscht, obwohl diese auf dem Papier ja Profis sind.
Es kommt drauf an, den Job erledigt zu bekommen, was vor 10 Jahren war, interessiert keinen ernsthaft. Das müssen ein paar in den 1990ern hängengebliebene Personaler noch hart lernen, aber die schreiben Ihre Stelle ja auch nicht wegen Unfähigkeit selbst neu aus.
@ ich hab auch nichts gegen Quereinsteiger, ich würde aber von jemandem, der schon 10 Jahre entwickelt auch nicht mehr von Quereinsteiger oder Neuling sprechen. Vermutlich habe ich zu oft in prekären Projekten gearbeitet, in denen aus Geiz und oder Dummheit billige frisch “qualifizierte” Quereinsteiger eingestellt wurden, weil die ja lernfähig und fleißig sind. Dann war die Katastrophe schnell passiert… oder auch “Ich stell lieber drei Juniors als einen Senior ein, die gegen keine Widerworte und machen was man von ihnen will…”
Wow, was genau ist denn an XML veraltet!? XML ist doch robust und eher zeitlos.
(Also ich lasse mich natürlich gerne von Gegenteil überzeugen, wenn es so ist.)
XML braucht relativ viel Platz, ist schwer zu lesen und die XML frameworks sind nicht die effizientesten teilweise (Speicherverbrauch, CPU). Jede Nachricht enthält immer auch die Struktur (doppelt mit öffnendem und schließendem Element), während es Datenformate gibt, in der Struktur und Payload getrennt sind - das spart extrem viele Bytes im Netzwerk. Aber selbst JSON oder YAML sind vergleichsweise schlank und meist lesbarer.
XML hat natürlich schon seinen Wert, aber es ist schon deshalb veraltet, weil es einfach nicht mehr eingesetzt wird in den meisten Schnittstellen - sei es aus gutem Grund oder schlicht aus "Trend". Allein 15-30% eingesparte byte auf der Netzwerk Rechnung sind halt z.B. ein Argument, das schwer wegzuwischen ist. Und die Byte müssen dann ja auch gelesen und verarbeitet werden - millionenfach oder milliardenfach.
XML ist wie Gewalt, wenn das irgendwie noch nicht richtig funktioniert, benutzt du noch nicht genug
@@vanivari359 Ich würde es nicht gleich als "veraltet" bezeichnen. Ja, gerade wenn etwas sehr oft gelesen/geschrieben werden soll, ist bspw. Json >>meistens
Hey, vielen Dank für die Antworten.
Das Argument der fehlenden, modernen Tools ist für mich tatsächlich der plausibelste Grund.
Ansonsten würde ich XML aber trotzdem nicht alles veraltet ansehen.
Ich arbeite mit WPF und damit auch mit XAML. CSPROJ sind auch XML Dateien und bald auch Visual Studio Solutions (SLNX könnt hoffentlich bald).
Ganz zu schweigen von den elektronischen XML Rechnungen, die ja auch gerade aktuell sind.
7:02 ohne unsere (interne) ERP Software läuft so gut wie nichts mehr in der Firma.
Wenn unsere Software heute ausfallen würde, dann gehen wir einfach auf den Stand von vor dem Update zurück.
Software fällt nicht ohne Grund aus.
Es sei denn die Infrastruktur zickt rum aber dann liegt es nicht an der Software.
Du solltest Refactoring nicht mit einem Rebuild in einen Topf werfen. Refactoring dauert üblicherweise 30 Sekunden, 30 Minuten oder auch mal 3 Stunden und sollte fortwährend von Entwicklern durchgeführt werden. Wenn man ein Jahr lang daran herumdoktort, die Software zurück in einen erweiterbaren Zustand zu bringen, ist Refactoring nicht der beste Begriff dafür.
Das hört sich an wie unser Zeiterfassungssystem in SAP xd
Da haben wir mehr oder weniger den Vorteil, dass unsere Software sowohl intern als auch extern genutzt wird. Dadurch kam bei uns keiner auf die Ausrede "Ist doch nur intern.."
Was ist ein typischer Aufwand in Prozent bzgl. Erledigung von tech. Schulden? Wenn man diese laufend wieder mindern möchte?
Das ist doch unmöglich pauschal zu sagen, sondern kommt auf das System an.
Bei mir ist Refactoring ein Teil der täglichen Arbeit. Wenn dann eine Anforderung kommt, die so nicht "elegant" zügig umgesetzt werden kann, sondern wenn dann grob zusammengehackt und übergestülpt werden müsste, nehme ich mir lieber die Zeit, das System so umzustrukturieren, dass es zügig geht.
Frei nach Kent Beck: "To make a hard change, first make the change easy, and then make the easy change"
@@DagarCoH Refactoring bringt nur etwas, wenn du die Fehler siehst.
Meist aber funktioniert alles am Anfang extrem gut. Erst mit der Zeit entstehen dann Probleme. Manche sind einfache Bugs. Das ist aber nicht immer so. Zwei Entwickler haben eine gemeinsame Vorgabe unterschiedlich umgesetzt. Schnittstellen werden nicht verstanden. Oder, Oder...
Es gibt unzählige Möglichkeiten technische Schulden zu produzieren.
Einmal wurde ich ich in Projekt als Externer eingestellt, weil das Team Probleme mit den Code hatte.
Im Endeffekt hatten alle Schnittstellen durch ein Architekturfehler ein Memory Leak. Der Bug war so schwerwiegend, dass eine Neuentwicklung einfacher war.
Im Endeffekt sollte man sich nie zu sicher in einen Projekt fehlen. Bugs können immer passieren.
Warum baut man überhaupt so große technische Schulden auf? "Ist das umsatzrelevant? Nein?! Also nicht wichtig! Nächstes Thema!"
Möglicherweise weil häufig Leute Softwareprojekte "steuern", die sich nicht für Softwareentwicklung interessieren und unter agiler Entwicklung Planlosigkeit verstehen.
Aus Unerfahrenheit, Teamfluktuation, Desinteresse oder äußerem Druck schätze ich mal.
@@lukasbacker5263 musste richtig lachen (und weinen), weil sich das nach meinem AG anhört :D aber hey, man macht das Beste draus, aber ich stehe als neuer Mitarbeiter (dem der Zustand nicht transparent kommuniziert wurde) ganz bestimmt nicht dafür gerade.
@@communityyoumustseekyoungp5630 Ungefähr so ging's mir vor paar Jahren aus, ich hab nach ca. einem 3/4 Jahr gekündigt, Kündigung zum Quartal hat mich aber noch 1/4 Jahr dort gehalten.
Dort war es genauso, nur dass ein leitender Entwickler (nicht Mal ein Laie) mir einmal erklären wollte, was agile Entwicklung wirklich sei und dass diese Firma es richtig macht - bis auf die Tatsache, dass es weder SCRUM (wie behauptet wurde) noch Agil ist, sondern einfach nur Planlosigkeit mit fancy Namen :D
Solche Projekte scheitern einfach immer.
Wir haben aktuell noch immer Software am laufen, die so alt ist, dass Hollerith Konstanten da noch eine technische Neuerung war. Die wurde über 60 Jahre weiterentwickelt, meistens von Mitarbeitern, die sich selbst zuhause im Keller per Zeitschrift Fortran beigebracht haben - denn Programmierer wurden und werden von der Managerebene selten als echte Berufsgruppe wahrgenommen und da lässt sich dann ja ganz gut laufende Kosten sparen; Einfach irgendwen machen lassen, den man ohnehin schon bezahlt.
Schließlich war nur noch einer der Mitarbeiter im Unternehmen. Da dieser ja weiß, wie die Software ungefähr funktioniert, brauchte es auch nie eine Dokumentation. Auch hat es ja meistens funktioniert, also brauchte es auch keine automatischen Tests. Die abgebildete Business-Logik wurde auch niemals genauer definiert als der Code selbst; "Wir wissen ja, was wir hier machen".
Das gesamte Herangehen an diese Sofware war über ihre gesamte Lebensdauer also von jeder Seite her nachvollziehbar - ist jetzt allerdings in einem Zustand, der uns immer lachen lässt, wenn ein JavaScript-Entwickler sich über "Legacy" beschwert :)
So baut man technische Schulden auf.
Das Hauptproblem sind Manager, die nach drei Jahren immer noch derselben Tätigkeit nachgehen und daher keine guten Manager sind. Und Entwickler, die nicht in der Lage sind, Entwurfmuster zu verwenden. Und POs, die keinen Plan von dokumentationsgetriebener Entwicklung haben. Das betrifft leider alle Firmen in Deutschland. 🤷♂️
Ja und das beste ist noch bei spielen bei ganzen das was nicht geht wo das spiel gut toll
Das Video ist in weiten Teilen anekdotisch und nutzt Beispiele aus realen Projekten, um eine Argumentation für die Wichtigkeit von Architektur und Design aufzubauen.
Die Kernbotschaft lautet: Unternehmen sollten Experten wie ihn engagieren, um von Anfang an hochwertige Softwarearchitektur zu gewährleisten.
Ein typisch deutsches TH-cam "Ratgeber"-Video eben, wo der Ersteller sich primär als Problemlöser und Experte positionieren möchte.
Englisch KI
Der Architekt, der Architekt, der plant bis er verreckt... In 5 Jahren kommt der nächste und macht genau das gleiche Video. Nur dann mit AI...
@@michaelschramm4315 Dann hast du die Rolle des Architekten missverstanden. 😉
Erster ;D