Warum Feature-Creeping deine Software-Projekte zerstört! 

Mein erster Mentor, in meinem ersten Job nach dem Studium sagte mir am ersten Tag: ‘Merke dir, a refactor a day keeps the mad manager away, du wirst es mir Danken.” Wie recht er hatte. Seit dem beinhalten meine Featureschätzungen immer auch refactoring und ich komme gut damit zurecht.

Uns wurde als Entwicklern beim verhindern von technischen Schulden vorgeworfen, dass wir nur aus technischer Verliebtheit länger für die Feature-Entwicklung brauchen. Das ist nicht nur schwach, sondern macht auch müde 😒

Jedes einzelne Wort in diesem Video trifft so unglaublich präzise auf die momentane Arbeitssituation von mir zu...

In meiner Company gibt es keine nicht-funktionalen Anforderungen. Und jeder Entwickler weiß ja schon, was zu tun ist. Deshalb kümmert sich niemand um das Entwicklungsumfeld. Das Video spricht mir aus der Seele 👍

Dieses Video kann das wichtigste Video sein das du bisher produziert hast.. danke dafür!

17:36 : Da Du so nett gefragt hasst.🤗 Bei uns in der Firma ist es weniger "nicht gehört werden" und mehr mutwillige Ignoranz. Unser Management weiß, dass unser Projekt Grütze ist. jeder neue Entwickler hat das ausnahmslos in seinen ersten Tagen bei uns festgestellt und angemerkt. Mittlerweile bekommen wird vor dem Einweisen neuer Entwickler sogar gesagt "Wir wollen nicht hören, dass es Grütze ist. Das wissen wir, wir können es aber nicht ändern". Zur Erklärung des Projektes Der originale Entwickler (eine person) des Projektes hat sich irgendwann von unserem Management getrennt (k.A. warum). Management hat das Projekt bekommen und so haben, 10 Jahre lang, rund ein Duzend anderer Entwickler versucht das Ding am leben zu halten und weiter zu entwickeln. Stat aber zeit zu bekommen irgendwas zu fixen hören wir immer nur "Wir müssen neue Features push", "Wir sind nur ein kleines Startup" (und das nach 10 Jahren mit rund 200 Kunden die eine nicht zu verachtende, monatliche Lizenz zahlen. 🙄) Ein einziger armer Hans Wurst in unserer Firma hat jetzt den kompletten Neubau diese Mamut-Projektes aufgedrückt bekommen. Natürlich neben all den "neuen features", die er mit entwickeln muss. Dazu kommt, dass unser (Projekt)Management halt nur die Kunden-Anforderungen schätzt. Sobald es um technische Umsetzung geht, schalten sie auf Durchzug. Getreu dem Motto "Die Programmierer machen das schon". Umsetzungszeit ist daher leider auch immer "Verhandlungssache". Oft werden detaillierte Zeiteinschätzungen gefordert ohne überhaupt den vollen Umfang der Aufgabe zu kennen. (Weil sich besagter Umfang leider während der Umsetzung ständig ändert). Da wird halt einen Tag vor der Fertigstellung noch schnell mal ein neues Feature gefordert, ohne das "man es nicht verkaufen kann" Und natürlich der obligatorische "Das hat alles viel zu lang gedauert" Anschiss an die Entwickler wenn es dann doch endlich erfolgreich vorbei ist.

Danke David, mit diesem Video hast du mir aus der Seele gesprochen.

Ich musste mal an einem Projekt mitarbeiten, bei dem die Klassen und Methoden endlose deutsche Namen hatten, unnötige Logik überall verteilt war und der Code absolut unlesbar war. Tests? Fehlanzeige. Die Firma bestand nur aus neuen Mitarbeitern, weil die alten alle gekündigt hatten. Als wir neben der Feature-Entwicklung etwas Zeit in Testabdeckung investierten, hieß es, wir verschwenden Zeit, weil der Kunde schnell Ergebnisse wollte. Das Prod Deployment war deswegen wie russisches Roulette mit sechs Kugeln.

Kenn ich leider nur zu gut. Hab mit mittlerweile angewöhnt den Abbau von technischen Schulden innerhalb von Feature-Issues zu "verstecken". Das geht gut bei Greenfield-Projekten und wenn jedes Team-Mitglied mitzieht. Ziehen nicht alle Entwickler im Team mit: Management: "warum brauchst jeweils 25% länger als die anderen?". Bei 10+-jährigen Projekten geht das mit dem "Verstecken" eher schlecht 🙂

Ich musste sehr lachen, weil mir vieles sehr bekannt vorkam. Ich habe Monate vor den ersten Kündigungen angekündigt, dass wir nach Lehrbuch in die Phase übergehen, wo die Codequalität die kompetenten Entwickler vertreibt. In dem Gespräch erklärte mein Chef, dass er mehr Features erwarte. Ich hab Praktische Informatik studiert, dafür wurde ich vor 16 Jahren eingestellt, aber dann drehte sich plötzlich das Positionskarusell in einer Form, die ich erst 10 Jahre später verstand bzw. geglaubt habe, weil sich wer im Management verplappert hat. Hätte ich das vorher geglaubt, wäre ich am gleichen Tag gegangen. Und so wurde ich der Typ, der jahrelang immer nur rumgenervt hat, weil er Bedenken und Warnungen auszusprechen als Teil seines Jobs verstand, dessen Prophezeiungen aber nicht immer exakt so eingetreten sind. Manchmal wiederum auch sehr genau, aber wenn ich dann fragte, warum wir es jetzt so machen, wie ich es vor drei Jahren machen wollte, dann wurde mir erklärt, dass meine Überlegung vor drei Jahren halt falsch war. Jetzt ist sie richtig. Warum das, was wir vor drei Jahren gemacht haben, jetzt wieder verworfen wird (also offenbar falsch war), weil der Entwicklungsleiter jetzt eine bessere Idee hat (also so, wie ich es vor drei Jahren wollte), wurde mir nicht erklärt. Irgendwann fragt man aber auch nicht mehr nach. Was mein Chef leider nie unterschieden hat ist, dass ein Risiko zu benennen keine Prophezeiung ist. Die Firma hat wirklich bemerkenswert viel Glück in den letzten Jahren gehabt. Also wirklich unglaublich viel Glück, dessen sich die meisten gar nicht bewusst sind. Und dann setzte das Glück dann letztes Jahr mal aus. Ich habe Deine Videos kennengelernt, da ein Kollege im Teamchat Dein Video erwähnte, in dem ein ganzes Entwicklerteam gekündigt hatte. Ich fragte den Kollegen damals, ob er uns damit was sagen wollte. Das hätte er so nicht gesagt, kam zurück. Aber er widersprach aber eben auch nicht oder lieferte eine andere Erklärung, warum wir uns das Video ansehen sollen. Er arbeitet weiterhin da, aber zufrieden wirkte das nicht. Und ähnlich bekam ich es von Kollegen mit. Inzwischen haben alleine von unserem Team mehr als die Hälfte gekündigt und auch in anderen Teams sind Leute gegangen. So groß ist die Firma aber gar nicht, das ist eine sehr bemerkenswerte Fluktuation, vor allem in so kurzer Zeit. Mit den ersten Kündigungen erklärte ich, dass ich die Firma und damit meinen Job gefährdet sehe, weil mir obwohl oder trotz meiner Ausbildung die Fantasie fehlt, wie das mit den Programmieranfängern, die wir einstellen und oftmals noch in den Basics der Programmierung ausbilden, noch sinnvoll zu retten wäre. Zumal ich nicht der Position des Entwicklungsleiters bin und eine benötigte 180 Grad Kehrtwende wohl nicht mehr zu erwarten sei. Feedback: Wann gehst Du? Das war's, kein Bedarf das zu besprechen. Kurz drauf kam ein anderer Entwickler zu mir und erklärte, dass er sich über die gleichen Sachen beschwert und er damit heute vermutlich der zweitunbeliebteste Mitarbeiter nach mir ist. Er erkärte, was er machen würde und ich kam aus dem Nicken nicht raus. Aber er steht heute halt genauso im Abseits. Und jetzt gehe ich und vererbe meinen Titel des unbeliebtesten Kollegen. Zumindest aus der Perspektive des Managements, denn mit den Kollegen komme weiterhin ich gut klar. Auch mit denen, die bereits gegangen sind, bleibt der Kontakt bestehen. Teilweise überlegen wir privat Projekte aufzuziehen. Heute noch mit einem ehemaligen Kollegen telefoniert, ehemalige Kollegen holen sich heute noch Rat. Das Team plant sich privat zu treffen, außerhalb der Arbeit und vor allem außerhalb eines Anstellungsverhältnisses bei der Firma, wo das Team gegründet wurde. Ich nehme damit 16 Jahre Erfahrung in dieser Firma, mit diesem Quelltext und damit zumindest einer grobe Ahnung, wo man in diesen Monolithen hätte was anpacken könnte. Plural. Nachdem ich ein Jahr da war, stellten wir fest, dass die Software ein Monolith ist (bzw. ich sprach es an) und dass das ein Problem ist. Ich schlug ein Rewrite und plante drei bis fünf Jahre dafür ein, in denen die alte Software gepflegt und die alten Entwickler umgeschult werden müssten, während man sich auf die neue Software konzentrierte. Das ist 15 Jahre her. Damals erklärten mir langjährige Entwickler, dass sie 80% ihrer Zeit dafür benötigen, herauszufinden, wie sie ein Feature da reingedrückt bekommen. Statt des Rewrites wurde sie parallel als Anbau zum vorhandenen Monolithen neu entwickelt, an dem weiterhin gearbeitet wird. Nun sind es zwei Monolithe, die miteinander verklebt sind. Und ich hab da keinen Bock mehr drauf, mir den Mund fuselig zu reden und dann der Arsch zu sein. Der Entwicklungsleiter geht bald in Rente und viele fähigere Entwickler haben schon gekündigt. Weitere Leute planen zu gehen, bevor der Entwicklungsleiter in Rente geht. Aus Angst das zu erben. Warum gehen die Leute nicht früher? Die meisten wurden als Anfänger eingestellt. Es ist ihr erster Job. Sie können nicht einschätzen, ob sie nochmal jemand nimmt. Mit denjenigen mit denen der Kontakt geblieben ist - die sind bisher happy gewechselt zu haben. Warum ging ich nicht früher? Nette Kollegen, von denen viele inzwischen woanders arbeiten. Ich hätte viel früher gehen sollen, aber ich hätte auch nicht gedacht, dass man das scheinbar Offensichtliche tatsächlich 15 Jahre lang ausblenden kann. Die Firma ist aktuell sehr erfolgreich und ich wünsche ihr von Herzen Glück für die Kollegen, die noch bis zur Rente durchhalten müssen. Aber ich suche mein Glück jetzt mal woanders, denn bis zur meiner Rente dauert es mir noch ein bisschen zu lang. :-)

Ich kenne das Ganze aus mittelständischen Unternehmen und auch aus StartUps. Ich habe sehr viel reden und erklären müssen und habe oft nur gespieltes Verständnis und Hinhalten erfahren. Man verlangt so oft "unternehmerisches Denken" in Stellenanzeigen, aber hören möchte man dann doch nichts. Ein sehr wichtiges Video.

Hi David, ich hatte über die Jahre leider auch schon diverse solche Projekte. Erschwerend kommt dann noch dabei, wenn die eigenen Teamkollegen gegen ein Refactoring schießen, weil man sich mit dem Management gut stellen will. Für mich absolut unverständlich. Das muss zwangsweise irgendwann knallen. Super Video.

Sehr gutes, wichtiges und informatives Video! Ich werde die Analogie mit dem Schlitten in einem meiner nächsten Meetings verwenden. Das ist so deutlich, dass es wirklich JEDER verstehen sollte. Danke dafür! Aber "Feature-creeping" ist meines Erachtens etwas anderes. Feature-Creeping ist, wenn sich der Scope des gesamten Projektes nach und nach verschiebt, weil z.B. wichtige Features gestrichen oder geändert werden oder auch immer mehr hinzugefügt wird, so dass am Ende das vorher anvisierte Ziel gar nicht mehr erreicht werden kann, weil sich das ganze Projekt in eine andere Richtung entwickelt hat. Ist etwas ähnlich, aber m.E. nicht das Gleiche wie das, was du im Video beschrieben hast.

Vielen Dank für das Video

Hallo David. Ein sehr gutes Video. Viele haben schon Ihre Erfahrungen geschrieben und kann bei vielen nur zu stimmen. Besser gesagt, kenne ich es aus meiner Firma. Wir reden schon seit Jahren, dass nichts mehr geht und ein Cut sinnvoll wäre - aus verschiedenen Gründen. Antwort: "Geht nicht... wir müssen ..." halt das ganze "unternehmerische Denken". Hat ja einer hier schon geschrieben. Muss sagen, in der Hinsicht denkt der Entwickler mehr, als der CEO, der nur Zahlen sieht und damit mehr oder minder blind nach vorne läuft. Am Ende sind die Entwickler die Schuldigen, was sie für eine Arbeit leisten usw.. Wie dem auch sei, kann nur nochmal sagen - ein sehr gutes Video - vor allem wegen der Art und Weise, damit es auch andere Personen verstehen könnten. Manche wollen es ja nicht verstehen. :D

Vielen Dank für den Einblick. Ich bin ehr Endanwender (mit etwas Programmierkenntnissen) von Software, insbesondere von einem größeren NASDAQ geführten Unternehmen - und verstehe so manche Probleme jetzt besser, die ich mit der Software habe. Das Unternehmen hat in seiner Software vor kurzen neue Funktionalitäten eingeführt (bzw. man hat nachgezogen, weil Konkurrenten das eigentlich schon viel länger konnten). Allerdings funktioneren jetzt ein paar essentielle Funktionen nicht mehr so richtig und sorgt bei mir für unnötigen Aufwand, um die daraus resultierenden Probleme zu umschiffen.

Danke, einfach nur Danke. 🙂

Ich finde das ist ein klasse Video. ich will trotzdem was bemerken- meiner Meinung nach wird Refactoring nur nötig wenn die Features „hingeklascht“ werden nur damit sie da sind. Ich persönlich bevorzuge den gleichzeitigen Ansatz, bei dem ich Datenmodell, Datenintegrität, Skalierbarkeit, Lesbarkeit von Vorneherein beachte. Es ist ja auch was das man „lernt“ irgendwann ist man gut genug dass Refactoring immer weniger nötig ist. Ich denke deshalb der eigentliche Hasenfuß ist der nicht-ganzheitliche Entwickungsansatz. Für Nicht Entwickler perfektes Schulungsvideo!

Wir sind mit einer anderen Firma zusammengelegt worden und hatten über "Wie wir entwickeln" eine Art "Retrospektive". Die beste Antwort, die meine Kollege auf die Frage hatte "Wann ist der richtige Zeitpunkt für ein Refactoring?" war damals "Jetzt!"👍 Bedeutet, wann immer man sich fragt, sollte man sich Zeit dafür nehmen bzw. einplanen.

Das war sehr interessant. Ich arbeite an einem kleinen Projekt, das auf die SQL Datenbank eines Warenwirtschaftssystems zugreift und die Arbeitsprozesse maßgeschneidert für uns darstellt. Und obwohl ich der einzige Entwickler bin habe ich das Problem "Was hast Du Dir dabei vor einem Jahr gedacht, warum hast Du nicht 1-4 Stunden mehr investiert um das anständig zu machen?"

Das beschreibt genau unser Projekt. Bin gespannt ob sich das mal ändert. 😢

Sehr tolles Video. In meiner Erfahrung ist es, dass leider der PO ist vielen Unternehmen kein echter PO ist und daher viel zu wenig Hoheit über die Priorisierung hat, sondern die Prios schlicht "durchreicht".

Ich habe gerade vor einem Quartal die Software-Bude gewechselt, da mein Chef es dort überhaupt nicht gesehen hat, dass er in einer starken technologischen Sackgasse steckt. Jetzt muss ich endlich nicht mehr mit meinem (Ex)-Chef um eine vernünftige Implementation schachern, sondern kann in meinem neuen Betrieb alles "akademisch korrekt (tm)" umsetzen. Es war eine regelrechte Befreieung. Die alte Bude wird sich zwar zwecks Kundenwachstum finanziell über Wasser halten können oder sogar weiter wachsen, aber technologisch wird es still stehen. Dort geht definitiv kein neues Feature mehr rein ohne rewrite.

Gute Zusammenfassung und schöne Analogie mit dem Schlitten. Für mich ist das sowas wie der Kern um den sich alles dreht: ohne Architekturbesetzung, klare Guidelines, Reviews etc ist jedes Projekt gefährdet. Es ist eine Kunst, ein Produkt effizient zu entwickeln, und dann zu warten und dennoch die Aufwände vertretbar gestalten. Wenn das in ein Video passt, wär ich überrascht. Zum Thema das sei keine Holschuld, sich Zeitbudget für Abbau von TechDebt zu erbitten: man kann das auch als Bringschuld des Software Teams definieren und das muss in den Schätzungen des Teams einbegriffen sein. Manche der Beobachtungen scheinen in einer Struktur vorzukommen, in denen der Architekt und der PO sich nicht als Teil des (der) Software Teams verstehen. Ich sehe den Architekt eindeutig als Teil des Software Teams (und oft auch den PO), und er muss sich in der Gesamtschätzung einbringen und Tech Debt Aspekte berücksichtigen. Das fordere ich als Manager (ich oute mich ;) ) ein, sonst führen ja meine Zusagen ja nach dem Projekt nur zu irren Maintenance Aufwänden. In der Realität ist das oft ein Tauziehen zwischen Projektleiter und den Abteilungsleitern. Gerne wird auch derjenige zum Held im Project, der die niedrigste Schätzung abliefert. Das gefällt dem Projektleiter, verursacht aber sehr schnell Probleme weil nix passt (man muss sich ja an der niedrigen Schätzung orientieren und abliefern ...). Am Ende habe ich als Manager ein starkes Interesse daran, dass die Schätzungen des Teams alle Aspekte berücksichtigen, und mische mich auch ein bevor ein Projektleiter oder PO die Geschicke in den Abgrund führt. Der Schaden fürs Team, für die Motivation, für die Arbeitsumgebung und damit für den Unternehmenserfolg sind viel zu hoch, als dass man sich es sparen könnte die Entwickler hier zu schützen.

Das ist allgemein das Problem, wenn es nur um kurzfristige Erfolge geht und Langfristige vernachlässigt werden

Danke, dein Video spricht mir aus der Seele. Hinzufügen kann ich, dass Kundenerziehung ein wichtiger Bestandteil ist, um technische Schulden zu vermeiden. Wenn das nicht der Fall, dann kann ein Projekt auch zu einer organisatorischen Abwärtsspirale kommen. Ich bin einer Agentur tätig, die E-Commerce Plattformen für andere Unternehmen entwickelt. Abgerechnet wird nach verbrachter Entwicklerzeit in Stunden. Das Einschätzen der Ticketaufwände in den BRs hat den Painpoint, dass sich Kunden direkt gegen die Aufgaben sträuben, die keinen sichtbaren Mehrwert für sie hat. Oft wird auch diskutiert, ob unsere Zeiteinschätzung nicht zu hoch wäre. Und leider gibt es nicht gerade selten nach der Umsetzung auch die Diskussion, wieso was länger lief als Initial eingeschätzt. So kommt es dazu, dass über die Zeit Refactoring Themen gar nicht mehr reinkommen. Und auch bei der Entwicklung wird öfters von unserer Führung hingewiesen, dass die Einhaltung der selbsteingeschätzten Zeit wichtiger ist, als ein Ticket sauber umzusetzen. Und gleichzeitig wird in den BRs meist die vom Senior vorgeschlagene Zeit angenommen, die selbstverständlich kürzer ist als die von den mehrheitlich im Team vorhandenen Junioren. So ist bei zwei unseren Projekten schon aufgekommen, dass immer häufiger Zeiten nicht eingehalten werden können, wenn ein Ticket nicht im Best Case umgesetzt werden können, weil nicht vorhergesehene Dinge eintrafen. Führt zu Diskussionen mit den Kunden, die ironischerweise auch Entwicklerzeit kosten. Und nicht selten kommen auch kritische Bugs zustande, die gelöst werden müssen, aber auch dann schon mehr als ne Woche Analysezeit verschlingen können. Im Endeffekt ist mir aufgefallen, dass wir zu weich mit den Kunden umgegangen sind. Es war mMn ein zu starker Fokus auf die Zufriedenstellen der Kunden in Form von Features etc gesetzt. Und als der Bedarf von Refactoring da war, hat man sich nicht getraut, da ja das "als eigener Fehler der vorherigen Ticketumsetzung" verstanden werden könnte.

Das ist nicht nur bei der Softwareentwicklung der Fall sondern allgemein bei Entwicklung von Bedeutung. Und da spielt die Architektur eine ganz zentrale Rolle … leider ist das Bewusstsein, dass manchmal neue Produkte mit neuer anderer Architektur notwendig ist, nicht immer den Entscheidungsträgern klar da Wissen fehlt.

Bei uns ist der Schlitten kurz vorm zusammenbrechen. Unwartbarer Code, aber es wird immer weiter dran gestrickt

Also ich muss wirklich sagen das es bei uns 1:1 genau so war wie du es beschrieben hast. Die Software ist nach und nach in sich zusammengefallen, das Management hat dies jedoch bis zum Ende nicht gesehen / nicht sehen wollen. Am Ende ist bei uns dann genau das passiert, was du in deinem Folgevideo thematisierst: Alle haben gekündigt

Geiler ist nur noch wenn die Entwickler dazu noch ins Büro gezwungen werden um dort dann während der Entwicklung kräftig vom PO/Manager micro gemanagt zu werden. Ist ja alles seit The Mythical Man Month (1975) bekannt.

Komme gerade aus einem Projekt bei einem großen IT Dienstleister für eine Bundesbehörde. Bei denen spielt Geld quasi keine Rolle weil der Staat immer nachschießt, weil ja Digitalisierung und so. Da findet also nicht mal mehr eine Korrektur durch Insolvenz statt. Die denkbar schlechteste Kombination.

Gutes Video! Aber technische Schulden in Geld zu quantifizieren, finde ich, gerade wenn es um so große Beträge geht, sehr mutig. Oft kann man das ja gar nicht realistisch abschätzen, was an einem refactoring wirklich alles dran hängt.

Nicht-funktionale Anforderungen wie immer weiter ausufernde Dependency-Trees? Wie die Nutzung von undurchsichtigen Stored Procedures? Wie kam der Schrott in die Applikation? Berater, die nicht für KISS empfänglich waren. "Bester" Ratschlag? Machen Sie ein feature freeze für Kunde X, dann können sie dem nix zerschießen. Das macht man ,zwei, dreimal, und schon war es das.

👍👍

Genau aus dem Grund mussten wir unsere ersten Apps "wegwerfen" und bauen inzwischen die meisten wieder neu auf. Zum Glück kam eine Umstrukturierung der Abteilung und jetzt entwickelt unser neuer Teamleiter unsere Entwicklungsprozesse immer mehr in die im Video genannte Empfehlung um. Das Wichtigste für uns ist: der Code muss wartbar bleiben, wir mussten vor allem wegen des nicht mehr zu leisteten Mehraufwand beim Bugfixing die alten Apps aufgeben. Das tat weh. Zum Glück konnten wir das aber noch rechtzeitig angehen, und unser Management zeigt dafür auch Verständnis.

Deswegen habe ich der Entwicklung komplett den Rücken gekehrt und bin inzwischen administrativ unterwegs. Eine andere Art von Stress,nicht ganz so gut bezahlt,aber mehr Anerkennung und besserer Umgang.

Summary: Titel: Bedeutung der funktionsgetriebenen Softwareentwicklung in der Projektarbeit EINLEITUNG: In der Softwareentwicklung können Fehler große Probleme verursachen, insbesondere die rein funktionsgetriebene Entwicklung. Dieser Text beleuchtet die Konsequenzen und betont die Bedeutung einer ausgewogenen Herangehensweise. ZUSAMMENFASSUNG: Funktionsgetriebene Softwareentwicklung kann zu schwerwiegenden Problemen führen Bedeutung von funktionalen und nichtfunktionalen Anforderungen in Softwareprojekten Stakeholder und deren Einfluss auf die Softwareentwicklung Konsequenzen eines einseitigen Fokus auf Funktionen Visualisierung der Auswirkungen in einem einfachen Beispiel SCHLUSSFOLGERUNG: Die funktionsgetriebene Softwareentwicklung birgt Risiken, die langfristige Folgen für Projekte haben können. Ein ausgewogenes Verhältnis von funktionalen und nichtfunktionalen Anforderungen ist entscheidend für den Erfolg und die Nachhaltigkeit von Softwareprojekten.

Ich habe festgestellt, dass bei Refactorings oder neu Implementierungen/Umstellungen oft und gerne Nebeneffekte übersehen werden. Schlimm ist es wenn es Showstopper werden 😀

Ach hier, der Thumbnail kommt mir aber bekannt vor. Da hast du aber ganz schön lange für's Video gebraucht 😉Wann war das? Februar? Ich plane bei der Implementation eines Features auch oft Refactoringzeiten mit ein. Dazu muss man aber die technischen Schulden im Projekt auch erstmal kennen, was ein ganz eigenes Problem sein kann...

Kann ich alles nachvollziehen aber ich habe keine Kraft mehr. Selbst an den freien Tagen spuken mir die Todolisten der Projekte durch den Kopf. Wie fange ich ein Kündigungsgespräch an wenn ich im nachhinein die Vorgesetzten in einem anderem Kontext immer wieder mal treffen und mit ihnen weiterhin zurecht kommen muss?

Hi David, wie würdest du ein größeres Spieleprojekt angehen? Bspw. AAA Games oder ne Stufe drunter. Welche Modelle kommen in Frage? Spiral, V, whatever? Kannst du allgemeine Aussagen aufgrund deiner Erfahrung treffen, was man auf keinen machen sollte oder was besonders geeignet ist wenn kaum spezifische Randbedingungen bekannt sind?

Wenn du Prügel beziehen willst, dann sprich auf deinen Projekten und in deiner Tätigkeit diese GAPS an. Entscheidungsbefugnis und Entscheidungskompetenz gehen nur in den seltensten Fällen Hand in Hand.

Was mir bei dem ganzen Thema noch Fehlt ist das Thema "Tools". Denn es sollten den Entwicklern auch die benötigten Tools zur Verfügung gestelllt werden, z.B. SonarQube oder sonstige Code Analyse Tools, die einem zumindest grob auf technischen Schulden hinweisen.

Wir haben leider nicht nur 1 Produkt sondern etwa 25 Produkte mit einigen Millionen Endnutzern (öffentlicher Bereich, größtenteils Landeslösungen) und keine 50 Entwickler, sondern 2,5-3 FTE, Leben überm Limit sag ich nur :D Wir sind auch gerade dabei ordentliche Prozesse aufzubauen, damit wir das Team vergrößern können, aber Zeit um Schulden aufzuräumen bleibt mir aktuell nur am Wochenende. Wir versuchen aber gerade mit kleinen Schritten in eine bessere Richtung zu kommen, z.B. haben wir eine Weekly Sentry Session, in der wir uns die relevantesten Fehler anschauen und dann überlegen wie wir diese nachhaltig beheben können mit dem Ziel eine möglichst fehlerfreie Software zu schaffen. Wirkliches Refactoring können wir leider nur im kleinen Rahmen machen, eine ganze Woche Zeit nehmen ist da aktuell noch nicht drin.

Nun könnte zumindestens ein kleines Team von Entwicklern sich auch selbst organisieren und sozusagen freiwillig architekturelle Defizite gar nicht erst aufkommen lassen. Management erwartet das gerne implizit und stellt dafür sogar Zeit zur Verfügung. Doch Richtlinien und die Anforderung, zur Lösung bestimmter Probleme etwa auf bestimmte Klassen zurückzugreifen, schränkt die "künstlerische Freiheit" ein und dämpft dann die Motivation der Entwickler. Ich kann hier auch das Vorurteil zum faktengeschützten Urteil machen und bestätigen, daß ältere Entwickler hier besonders hinderlich sein können.

Was er sagt ist in quasi allen Projekten mehr oder weniger stark Standard. Ich arbeite seit 19 Jahren in der Branche und habe 2 Projekte ohne und 98 Projekte mit technische Schulden gesehen. Das ist der Grund weshalb ich bereits seit über 2 Jahren an einer Plattform arbeite, die erst alle nicht-funktionalen Anforderungen löst, bevor die Business-Anforderungen umgesetzt werden. Mal so als Größenordnung was man eigentlich vorab an Aufwand investieren müsste, bevor man eine moderne Webanwendung als Individualsoftwarelösung umsetzen kann, was aber keine Agentur macht. Die machen das immer im Laufe eines Projekts, sind dann überrascht, wenn der Kunde die Seite zum Beispiel mehrsprachig wünscht und schludern dann eine halb funktionierende Lösung hin.

Anpassbarkeit ist die Kerneigenschaft von "Soft"-ware, die immer erhalten bleiben muss, egal wie viele Features man einbauen will. Wenn man keine Änderungen mehr machen kann, ist das Produkt tot. Continuous Delivery (= Software ist immer releasebar) und Agilität (= wissenschaftliches Arbeiten in Experimenten) existieren nicht zum Spaß.

Ist nicht nur in der Software Entwicklung so. Auch in der Hardware Entwicklung werden von oben Vorgaben gemacht, die gar nicht einzuhalten sind und hinterer wundert man sich, warum die Produktion zu teuer ist. Ist zwar ein etwas anderes Feld, aber ähnliche Probleme

Bei uns werden die Softwareentwickler nur als irgendwelche Fuzis angesehen, die sowieso zu viele Stunden brauchen, zu viel rummeckern und sowieso keine Ahnung von wirklichen Buisinesproblemmen haben. 😅 Software muss ja nur funktionieren.

Ex Softwareentwickler und nun in Leitung einer IT-Beratung. Ich versteh dieses Thema und schaffe es teilweise sogar Kunden näher zu bringen. Oft kommt dabei Re-Engineering raus. Zusammenfassend nenne ich das alles App-Modernization.

Ich liebe diese Animationen. Bin jetzt auch schon über 20 Jahre dabei und habe schon einige Firmen durch. Aber in 90% der Firmen läuft es genauso ab. Was zu riesen Frust bei den Entwicklern führt und eine hohe Entwickler Fluktuation vorprogrammiert ist. Immer mehr Wissen geht dadurch verloren was im schlimmsten Fall sogar zu einem Scheitern des Projekts führen kann.

Wenn du die Arbeit von heute erledigst, gut. Wenn du die Arbeit von heute so erledigst, dass du die Arbeit von morgen nicht erledigen kannst, schlecht.

Man kann immer etwas tun. Es steht und fällt mit dem Entwickler team. Ich bleibe mal in Scrum. Das team trägt die Verantwortung, sonst niemand. Alles andere ist Augenwischerei.

Ich arbeite in der Lebemsmittelindustrie als SPS Software Entwickler in einem festen Unternehmen. Dort sehe ich exakt das gleiche Problem. Es wird dann manchmal gesagt, dass es ja richtig ist dass ich Refactoring angehen will. Wahrscheinlich nur um mich ruhig zu stellen. Es kommen dann aber so viele Feature Anforderungen dass das Refacturing praktisch nicht umsetzbar ist…. Ein Trauerspiel. Denn jedes neue Feature auf dem alten Scheiß aufzubauen bringt nachher nur mehr Arbeit und Probleme. Die ganzen „Manager“ Persönlichkeiten verstehen den Hintergrund auch einfach nicht. Wenn man ihnen versucht nur im Ansatz zu erklären was man machen möchte und was wichtig ist zu machen, schalten diese auf Durchzug….. Das selbe passiert auf der Verfahrenstechnischen Seite. Die Elektrische Seite hält sich zum Glück noch in Grenzen.

Ich hätte mal eine andere Frage, lohnt es sich mit 38 noch an Softwareentwicklung zu werden? Oder sagt ihr lass es?

Das Grundproblem ist, dass wir als Software Entwickler schon falsch kommunizieren. Das Video ist ein Paradebeispiel dafür. Es gibt keine "nicht funktionalen" Anforderungen! Natürlich erfüllen sie eine Funktion, nur keine fachliche. Es sind Qualitätsanforderungen. Die Schuld nur beim PO oder Management zu suchen, ist mir zu billig. Darüber hinaus, kann dann durchaus technische Schulden bis zu einem gewissen Maß aufbauen. Aber es liegt in der Verantwortung die Risiken zu benennen und zu dokumentieren. Der Abbau der Schuld muss zudem erfasst und geplant werden (Tilgungsplan, wenn man so will) . Und das ist ein Team Effort. Also nehmt gefälligst die Verantwortung an und schimpft nicht immer auf das Management.

Mit der Intention dieses Video auch Managern zeigen zu können, ist der Titel echt suboptimal, um es höflich auszudrücken. Da wird man NIEMALS einen Manager dazu bewegen, sich das anzusehen! (Edit: Titel wurde geändert!)

In meinem Team, wo ich im FE Bereich der Entwicklung arbeite, habe ich dort eine Senior Rolle inne. Dank dieser Situation nehme ich mir die Freiheit heraus Code zu überarbeiten. Mussten neulich den Code eines anderen Teams bearbeiten. Der Code war dort (aus meiner Sicht) so grausam, dass ich mich mit dem anderen Team zusammengesetzt habe, denen mitgeteilt habe, dass das so nicht geht. Gleich auch noch gezeigt habe, was ich so schlimm daran finde und anschließend denen mitgeteilt habe, dass die komplette Seite von mir neu implementiert wird. Dafür habe ich rund 3 Tage gebraucht, in denen ich keine neuen Features bearbeiten konnte. Mein PO und SM kennen mich zum Glück soweit und lassen mir die Freiheiten, hätte ich diese Freiheiten nicht... vielleicht hätte ich mich geweigert an diesem Code in dieser Form zu arbeiten.

Ja, ja und ja ;)

Ob der Chef weiß, wie hoch die technischen Schulden sind, weiß ich nicht. Ich habe irgendwann aufgehört darüber nachzudenken. Leider musste ich lernen, dass das ganze Gerede nichts nützt.

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-cyAwCe5XAIM.html Handelt es sich hierbei zufälligerweise um Logikal (Orgadata).. Ein riesen Monolith.. jese Update macht mehr Bugs als vorher waren, wird auch gerade neu entwickelt für die Cloud.. Würde alles sehr gut passen :D

IMHO nicht ganz richtig. Mit der Komplexität von Software fällt die Entwicklungsgeschwindigkeit auch bei "perfektem" Code langsam, aber stetig ab. Refactoring verhindert, dass dieser Abfall zu drastisch ausfällt. Richtige Erholungen bekommt man nur tiefgreifende Architekturänderungen bei gleichzeitiger Entsorgung von Funktion, die einer neuen Architektur im Wege stehen und nicht essentiell für das Produkt notwendig sind. Das ist allerdings nichts, was im Wirkungsbereich eines einzelnen Entwicklers liegt. Meist ist so was nur durch einen Wechsel der Programmiersprache möglich. Und selbst dann muss man aufpassen, dass nicht Code 1:1 übertragen wird.

Robert Jackal - Moral Mazes. Nichts mehr zu lesen/sagen

Ach Manager.... Mensch die mit einfachster Logik überfordert sind. Gerne mal nicht nur unnütz sondern gar schädlich. Wenn Führungsanspruch zum Ersatz für Führungskompetenz wird....

Man könnte spasseshalber die Rollen tauschen und SW-Entwickler:innen Management-Entscheidungen treffen lassen (inkl. Verantwortung aller Art für die Resultate). Wenn da "Management" aus "SW-Entwicklungs"-Perspektive mal kein Neuland ist...

Does youtube think im german or something?

Nichts neues. Immer das selbe Spiel mit Kunden / Management das keine Ahnung von Softwareentwicklung hat. Been there done that many times.

… dann liebe Entwickler bitte aber auch die Umsetzung des Refactorings oder der technischen Schulden proaktiv konzeptionieren, planen und mit vorantreiben und nicht nur zurücklehnen und PO und Management für alles organisatorische verantwortlich machen !!! Der arme Entwickler der ganz alleine den Schlitten zieht und frei von jeder Schuld ist … 😢😆