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 😒
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.
Sehr löblich, ist aber leider auch Projekt abhängig. Oft steht nicht ein Feature sondern 10 im Raum und dann sind 8 davon kritisch... Letztlich ist es so das man das Einplant um am ende 6 neue kritische Dinge fixen zu müssen usw. Letztlich ist dann am ende evtl. Refactoring für 2 oder 3 Features möglich und das wars....
@@kreativmonky einfach nicht stressen lassen. Dinge brauchen so lange wie sie nunmal brauchen. Ich kann auch nicht mit dem Flugzeug in Einer Stunde von London nach New York fliegen. Wenn du selbst schätzt und dann wegen dem Zeitdruck kleiner abschätzt, dann musst du Dir selbst die Frage stellen, ob das sinnvoll ist. Wenn dich niemand fragt und du nur machen sollst… dann läuft da etwas gewaltiges schief…
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 👍
Hier ein kurzes Update zur Lage. Aufgrund von diesem Video habe ich noch mal versucht, mit meiner Management Ebene Kontakt auf zu nehmen, um das Thema SW Qualität anzusprechen. Dabei habe ich erwähnt, dass ich mir selbst einen eigenen Anspruch gesetzt habe, was SW Qualität betrifft. Die Antwort von meinen Chef hat mich umgehauen. So ein eigener Anspruch existiert nicht. Wenn die Firma entschieden hat, SW in dieser Form bzw. Qualität als Produkt auszuliefern, habe ich mich dem zu fügen, weil ich letztens dann genau dafür bezahlt werde. Tja dann ist es für mich wohl entschieden.
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.
ohje, das hört sich genauso an wie bei uns. Ich hab mich leider mittlerweile auch damit abgefunden das wir einfach beschissene Software bauen. Ist echt traurig und demotiviert sehr stark. Hab dadurch auch irgendwo den Spass am Entwickeln verloren.
@@horstkampfgarten5768 Und wie sollen die wissen, was der Kunde will, wenn der Kunde das selbst nicht 100% sagen kann. Man müsste an solche Sachen wahrscheinlich iterativ rangehen. Lieber 60% die funktionieren, sinnvoll umsetzen und die benutzt werden, wie 100% schlecht programmiert und es werden eh nur 70% benutzt und nach n Jahren kommt ein anderer Kunde auf die Idee von den 30% ungenutzter Funktionalität nur einen Bruchteil zu nutzen und plötzlich schepperts. Wir, die Kunden und alle anderen überblicken doch meist die gesamte Funktionalität nicht. Selbst alte Hasen vom Kunden haben nicht alles im Blick, vor allem bei Sonderfällen, Ausnahmen und weiss der Geier für Sonderlocken. Vor allen wenn man hunderte Kunden hat und es die wenigen gibt, die sich an keine Standards halten. Das ist utopisch.
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.
@@christianibendorf9086So schlimm sehen die wenigsten Projekte aus. Wenn alle alten Entwickler weg sind, solltest du dir einfach überlegen, sofort das Projekt zu wechseln. Das ist normalerweise kurz vor dem kompletten Ende des Projekt.
@@MarvinDuck Du würdest staunen, wie lange man tote Pferde reiten kann. ;-) Und: Nö, nach meiner Erfahrung sieht ein signifikanter Teil der Systeme und Teams so aus. :-(
@@christianibendorf9086 Ich weiß, wie lange man tote Pferde reiten kann. Ewig. 😉 Aber ein Projekt, wo alle alten Entwickler weg sind, sollte man sich nicht antun. Meist hat es ein Grund, warum alle weg sind. Und den will man meist nicht selber heraus gekommen.
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. :-)
Es ist immer das gleiche. Egal wo man hin kommt, passiert immer das selbe. Mal schneller mal etwas langsamer. Ich habe mittlerweile aufgegeben mich darüber aufzugeben und lasse sie einfach ins Verderben rennen. Solange ich dafür bezahlt werde, ist es mor egal. Schont meine Nerven.
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.
@@cdoubleplusgood Leider wahr, wir rennen als produzierendes Unternehmen am Monatsende nochmal richtig, "damit der Umsatz gut aussieht". Dass der Umsatz vom Vormonat den vom Folgemonat auch betrifft...shitegal...Kann ich nicht verstehen. Einfach blind und sinnlos Druck machen, dann gehen die Zahlen schon nach oben oder so. Dass das am Ende am Auftragsbuch liegt, geschenkt. Hauptsache das middle Management hat Stress, das geben die dann weiter und dann arbeiten alle irgendwie effizienter und durch automagie werden die Umsätze besser.
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.
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 beantrage hiermit, dieses Video zur Prime Time im TV laufen zu lassen! Jedes Wort so wahr. Und als Entwickler, selbst als Team Lead rennst Du Dir die Hacken wund beim Management, welches nur auf ROI und Gewinn schaut 😡
Super video, dass selbe was ich bereits angesprochen habe. Es wurde auf mich gehört. Wir haben uns hilfe gesucht, es ist aber zu viel um es mit der externen hilfe in kurzer zeit zu schaffen.
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.
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.
Im Prinzip ist es das gleiche. Das Projekt verändert sich bei jedem Feature. Äußerlich bleibt es erst einmal gleich, aber innerhalb des Projektes verschlechtert sich immer mehr die Codebasis. Und irgendwann nehmen die Probleme zu. Durch die immer neuen Features, verschwimmt auch das Ziel. Das Projekt entwickelt sich zu einem Schweizer Taschenmesser. Es kann alles, aber nichts richtig.
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.
Also ich arbeite in der IT Beratung schon seit Jahren und habe auch schon viele Softwareprojekte erlebt. Die meisten ignorieren das Problem nach meiner Erfahrung nicht, ich glaube da gibt es inzwischen genug Sensibilität für in der Wirtschaft. War sicherlich damals anders, aber ja ich kenne auch wirkliche Vollkatastrophen Projekte. Das schrecklichste war bei einer Behörde, wo 10 Entwickler beteiligt waren und ein Katastrophales Management plus schreckliche Schulden die Entwicklung extrem lähmt. Einarbeitung von drei/vier Jahren sind noch normal. Ich hatte nach ein paar Monaten kein Bock mehr darauf…
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.
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 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.
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?"
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.
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.
Was hier helfen kann, ist ein Faktor, mit dem die Schätzungen multipliziert werden. Dieser Faktor wird gebildet aus tatsächlicher Zeit / geschätzte Zeit. Beispiel: - Schätzung 5 Tage - Tatsächliche Umsetzung 7,5 Tage - Faktor 7,5 / 5 = 1,5 - nächstes Projekt, Schätzung 10 Tage * 1,5 = 15 Tage - tatsächliche Umsetzung 17 Tage - neuer Faktor 17 / 15 = 1,13 - nächstes Projekt, Schätzung 8 Tage * 1,13 = 9 Tage Ziel ist es, den Faktor mit der Zeit auf 1,0 zu bekommen. Dann ist die Schätzung perfekt.
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.
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".
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.
Alter Schwede…. beim Lesen des Comments schrillen mir die Alarmglocken aus den Ohren raus. Es geht dabei um Einschätzungen! Das sind keine Predictions! Das sind Schätzungen! Bitte nicht verwechseln! Einschätzungen werden sooo oft als Predictions betrachtet und als Deadlines oder Milestonetimestamps herangezogen. Man orientiert sich NIE nach Schätzungen sondern an Taten welche bereits passiert sind! Zur Verständnishilfe: Wenn ein fix und fertiges Ding einmal produziert wurde kann man beim 2ten mal genau das Gleiche produzieren und eine Prediction dafür abgeben, denn man ist den EXAKTEN Weg bereite einmal gegangen! Wenn man eine Entwicklung hat und somit etwas erzeugt was es so EXAKT noch nie erzeugt wurde ist es eine Einschätzung. Es geht dabei darum dass der Weg erst beim Gehen erkundet wird ob man ihn wirklich geht. Eine Zeit lang geht und dann von einem Zwischenpunkt wieder retour geht und einen neuen Weg zu einem anderen Zwischenpunkt geht (refactoring).
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
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
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.
Ich sehe deutliche Ähnlichkeiten zur Hardware Entwicklung. Fast schon beängstigend wie nah die Prozesse sind. Die Taubheit bei Kritik und das fehlende Bewusstsein für Prozesse mit vielen Stakeholdern ist bei uns genauso und fühlt sich erdrückend an. Es geht immer wieder um die zeitnahe, eierlegende, modulare, hoch-ästhetische Wollmilchsau für den einen Kunden oder die nächste Messe. Anstatt die Zeit für eine gut konzipierte Basis zu nutzen werden mittelmäßige Produkte - die bereits schlecht laufen mit unsinnigen Features versehen, weil ein Kunde das gern hätte (der dann aber wundersam wieder abspringt 😅). Egal wie oft Bedenken angemeldet werden wird bei uns immer wieder gerne Entwicklung ausgelagert, damit wir schneller vorwärts kommen. Dass dadurch in 100% der Fälle mehr Arbeit entsteht brauche ich in dieser Runde sicher nicht erklären. Wie soll ein Externer das Framework verstehen wenn er nicht mal weiß wer der User ist, oder wie die Stammdaten aussehen sollen, oder welche Verfahren zum Einsatz kommen oder das Lager nicht kennt oder oder... Die nicht-funktionalen Richtlinien sind halt unfassbar wichtig und ich bin sehr dankbar, dass es von nun an einen Begriff dafür gibt 🎉. So habe ich ein Handwerk zum Meister gelernt, einen Master im Studium erreicht und denke regelmäßig Gedanken unmotivierter, externer Entwickler neu, damit sie systemkompatibel sind und kein Kollaps stattfindet. Geschaftsführung denkt wir Entwickler arbeiten zu langsam und verbreiten miese Stimmung wenn wir ehrliche und belastbare Aussagen zu Entwicklungszeiten treffen. So werden wir oft nicht mehr gefragt, ob es Kapazitäten für neue Produkte gibt. Das erfahre ich als leitender Entwickler ganz nebenbei aus dem Marketing. Hoppla 🎉 eine Shitshow ohne Lernkurve 😂😂 Grüße und Dank gehen raus 😂😂
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.
Hallo David... ich kann das so nur Unterschreiben. Ich bin Selber im Management und C-Level und ich bin erschrocken, wie viele "Entscheider" absolut keine Ahnung von Softwareentwicklung haben. Klar ich hab den Vorteil, dass ich selber IT Ingenieur studiert habe und selber Gross Systeme Entwickelt habe. Hauptsache Funktionalität und "Please the Customer" anstatt langfristig eine Strategie entwickeln... es ist leider in sehr vielen Unternehmen so.
Unter dem Begriff Feature Creep verstehe ich eher, dass Kunden im Rahmen der Entwicklung immer mehr zusätzliche, ursprünglich nicht vereinbarte Features durchzudrücken versuchen, vor allem bei agiler Entwicklung. Die übermäßige Beschränkung auf unmittelbarem Business Value, und dabei Vernachlässigung von Softwarequalität und Pflege, ist ein anderes, großes Problem. Vor allem Scrum kann hier anfällig sein, wenn das Management damit eine Art von oben vorgegebene Fließbandarbeit durchdrücken und die Entwickler an vermeintlich unproduktiven Codeänderungen und "Vergoldungen" hindern will.
Wenn man selbst kein Software-Architekt ist und vom Management auch nicht als solchen gesehen wird, hat man schlechte Karten. Zudem hat der Begriff "technische Schulden" immer auch eine abstrakte Dimension. Für die einen sind es technische Schulden, für die anderen eine geile pragmatische Art die momentanen Kundenbedürnisse zufrieden zu stellen. Ich habe aber auch erlebt, dass kaum ein Kunde sich wünscht, dass man technische Schulden im Sinne von Fehlerhaftigkeit, Unwartbarkeit oder Unerweiterbarkeit anhäuft. Es waren immer Faktoren wie falscher Ehrgeiz oder Überforderung auf allen Seiten im Spiel. Gegen die man als Entwickler eh kaum etwas machen kann. Daher meine Erfahrung: Besser frühzeitig erkennen wann sich die Kollegen und das Management dazu verschwören technische Schulden zu machen. Gerne den konstruktiven Ausstieg suchen und die eigenen Befürchtungen thematisieren. Dann aber die Reissleine ziehen. Bevor man anfängt aufgrund dieser Schulden selber Dinge in den Sand zu setzen und die eigene Performance oder gar die eigene Gesundheit leidet.
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.
Ich habe festgestellt, dass bei Refactorings oder neu Implementierungen/Umstellungen oft und gerne Nebeneffekte übersehen werden. Schlimm ist es wenn es Showstopper werden 😀
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.
In einem Unternehmen, bei dem das Management für solche Aufgaben Zeit abstellt, sollte das Problem gar nicht erst entstehen. Das ist zumindest meine Erfahrung. Als Entwickler arbeite ich lieber an gut funktionierendem und leicht zu pflegendem Code. Es ist für mich schwer vorstellbar, dass ein Entwickler technische Schulden ansammelt, obwohl er die Möglichkeit hat, dort gegen zu steuern. In meinem Berufsleben war ich bei einem Arbeitgeber beschäftigt der dafür keine Zeit bereitgestellt hat. Die Entwickler hätten sich auch selbst organisiert um die Probleme anzugehen doch das hätten sie in ihrer Freizeit tun müssen und dazu war wirklich niemand zu motivieren.
@@AtomicKnights Mein Punkt war, daß es auch an Entwicklern liegen kann, aber nicht muß. Ich habe es leider erlebt, daß Entwickler lieber manuell SQLs erstellen als dies geeigneten Klassen zu überlassen. Man möchte da einfach seine Arbeitsweise nicht ändern. Da hilft es auch nichts, wenn für diejenigen Fälle, in denen die Abstraktion nicht oder noch nicht greift, jederzeit auf handgeformte SQLs zurückgegriffen werden kann.
@@LarsPW So eine Blockade gegen den Fortschritt habe ich glücklicherweise erst selten erlebt. Spontan fallen mir zwei Gründe dafür ein: - Rock-Star-Entwickler: Statt auf einer Technologie aufzubauen die von vielen im Team beherrscht wird bleibt man bei einer Technologie die nur von wenigen oder einer Person beherrscht wird. So verschafft man sich Status und Prestige. Zumindest in den Köpfen einiger Leute. - Die Angst, sich selber abzuschaffen. Erledigt man in manueller Arbeit eine Aufgabe, die eigentlich automatisiert werden könnte, liegt das unter Umständen ander Angst um den eigenen Arbeitsplatz. Ist der Prozess ist automatisiert wird man persönlich ja nicht mehr benötigt.
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.
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.
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.
Product owner und Projektleiter seh ich in der Verantwortung dieses komplexe Thema dem Management näher zu bringen. Oft werden nicht die besten Leute für diesen Job nominiert, sondern Leute die für Software-Entwicklung schon nicht die Besten sind.
@@olafschermann1592 Ja, und den Kunden. Denn die Kunden sind auch verantwortlich sinnvolle Requirements mit Product Owner zu gestalten. Was aber wenn der Kunde nicht genau weiss, was erwünscht ist. Viele Projekte sind derart komplex, da werden auch Details vergessen. Der Prozeß muss viel agiler werden. Die Software kann auch mit 60% der Features zu Beginn laufen. Dann wird zum Großteil auch klar, was man wirklich benötigt. Diese Big Bang Prozeß erschließen, ist selbst bei kleinen Anforderungen zum Teil schlicht überfordert und selbst bei Anwendern, die man zu alten Hasen zählen würde.
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.
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
Ist übrigens fast auf alle anderen Bereichen in der IT auch anwendbar. War Systemintegrator & Support Lvl2 und stand letztendlich vor den selben Problemen. hauptsache schnell schnell aber letzendlich ist die qualität miserabel
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!
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.
Yeah,... Ich schätze deine Situation natürlich falsch ein, leider klingt die Beschreibung sehr nach Hero-Einzelentwickler: Alle sind doof im anderen Team, die kriegen das sowieso nicht hin, also lieber selbst neu machen. Wenn meine Wahrnehmung stimmt, würde ich als Teammitglied in diesem Team künftig vermeiden, dass du meinen Code siehst oder auch nur gefragt wirst.
@@hb-man keineswegs. Gibt durch aus viele andere Entwickler die sehr gut sind. Ändert nichts daran das jeder (auch ich) mal absoluten Blödsinn zusammen coden kann. Ich bin bei Leuten, die mich schon etwas kennen, auch direkter. Diese Leute suche ich mir dann auch bewusst raus wenn ich mich über einen Code ärgere. Das ist aber eher die absolute Ausnahme. In über 5 Jahren in dem aktuellen Unternehmen, kam das zwei Mal vor. Zum einen wissen die Leute, dass auch ich umgekehrt es ebenfalls begrüße, wenn die Leute direkter mit mir reden und zum anderen soll das ganze Lösungsorientiert sein. Selbst wenn ich Leute als "inkompetent" betrachten würde (was nicht der Fall ist), dann wäre meine Schlussfolgerung, dass sie dann noch etwas lernen müssen. So wie mMn jeder andere Entwickler bzw. jede Entwicklerin ebenfalls. Mich ganz genauso mit eingeschlossen! Das andere Team kam z. B. auf die Idee die Codes vor allen Entwicklern im Unternehmen vorzustellen und zu vergleichen (Geschwindigkeit, Speicherkapazität, Erweiterbarkeit usw.) um positive als auch negative Beispiele zu präsentieren. Wobei es eher darum gehen soll, aus Dingen zu lernen und nicht jemanden bloß zu stellen. Deswegen werden die Codes auch ohne Namen präsentiert. Ich hatte eher die Anfrage an das Team ob man sich gegenseitig nicht häufiger die Codes reviewen sollte. Wobei es mir darum ging, dass auch andere Entwickler meinen Code sich anschauen, da ich ganz genauso Fehler mache. Wenn auf einer Webseite "n" verschiedene Filter existieren und die Datenquelle, welche untersucht werden soll, insgesamt "n+1" mal vollständig gespeichert wird und beim filtern auch "n+1" Mal durchlaufen wird, dann ist das alles andere als effizient und sollte dringend überarbeitet werden. Dann ist das extrem ineffizient und frustriert auch den User, welcher unnötig lange warten muss und das wirft dann ein schlechtes Licht auf das Unternehmen. Erst recht wenn dieser Code von der Chefetage als "besonders Robust und effizient" beim User angepriesen wird. Mit dem Entwickler, der das implementiert hat, habe ich bewusst nicht direkt gesprochen. Dafür kenne ich ihn und er mich zu wenig. Ich wollte also Missverständnisse vermeiden und ihn nicht angreifen. Sein Senior kennt ihn dafür besser. Zusätzlich kenne ich seinen Senior weiß , dass dieser mich einschätzen kann und weiß wie ich das meine. Und ja, wenn ich das Gefühl habe, dass jemand nimmt eine Aussage von mir als Angriff auf, habe ich kein Problem damit die Leute nochmal zu kontaktieren und die Sache richtig zu stellen bzw. mich auch notfalls zu entschuldigen und im weiteren Verlauf auch vorsichtiger mit diesen Leuten umzugehen. Letztlich arbeiten jetzt unsere Teams stärker zusammen und tauschen sich auch stärker aus. Ohne "böses Blut" zwischen uns.
@@hb-man Ist auch schwer ohne Mimik, Gestik usw. das richtig rüber zu bringen. Mir fällt es schwer solche Dinge auf dem Punkt zu bringen, sodass alle wichtigen Infos rüber kommen. Daran muss ich definitiv noch arbeiten. 🙂
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.
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.
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?
Es gibt unendliche Wege zum Ziel. Egal welche Architektur ihr nimmt, dokumentiert die Planung. Und wenn jemand der andere Entwickler Probleme mit dem Verständnis hat, sollte ihr vielleicht den betreffenden Code/Architektur nochmals anschauen. Gerade die Architektur muss jeder Entwickler verstehen.
4 หลายเดือนก่อน
gut gesprochen. Vielleicht liegt es ja nicht daran, dass die Führungskräfte das Problem nicht erkennen können (wegen Unerfahrenheit, mangelnder Kenntnis, oder gar nur der Idee, dass IT nicht anders sein müsste als Brötchen backen) sondern daran, dass es in den Köpfen von allen (!!!) Beteiligten immer noch die Vorstellung gibt, dass IT ja ganz einfach ist, weil man sogar Schüler zum Programmieren bringen kann. Komisch dass Mathematik da einen ganz anderen Ruf hat. Da werden viele gleich ganz still. Für mich ist Mathe und Informatik sehr nah beieinander aber da stehe ich auch nicht mit der Mehrheit. Mit IT kann man aber wie es scheint, auch schnell Kohle machen und es läuft lange ganz gut. Da merkt man den schleichenden Verfall zu spät (Frosch im Boiler).
Oh, es gibt dazu noch so viel mehr zu sagen ... Ich bin selbst als Software-Architekt unterwegs, habe schon so manches Großprojekt von innen gesehen und kann alle Aussagen in dem Video so unterschreiben. Insbesondere mit den 20% für technische Aufarbeitung hat bei meinem letzten Projekt wahre Wunder bewirkt - wenn auch über einen langen Zeitraum. Zwei Aspekte möchte ich jedoch nochmal herausgreifen: 1. Ich sage den Entwicklern immer wieder, dass sie ein Stück weit selbst dafür verantwortlich sind, die 20% für Refactorings mit in ihre Kapazitätsplanung mit einzupreisen. Zur Not auch versteckt von dem Management. Habe ich selbst immer gemacht und kein Manager hat mich auch nur danach gefragt - weil die meisten es nichtmal geblickt haben. Aber egal wie oft ich das sage, die meisten Entwickler machen das einfach nicht! Warum nicht?! 2. Wie kann ich das alles den Managern auch wirklich so begreiflich machen? Wenn ich diesen Vortrag vor meinem aktuellen versammelten Entwicklungsmanagement halten würde, würden die meisten nur mit den Schultern zucken und sagen, dass sie das Problem nicht hätten, obwohl wir Architekten schon kilometerlang schriftlich festgehalten haben, wo die Probleme liegen. Da werden wir aber nur als Schwarzmaler, Wichtigtuer und Perfektionisten abgetan. Wie soll man da das Management noch erreichen bzw. zur Raison bringen?
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ß.
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.
glaube ich nicht. Das Produkt und Business besteht aus allem was die Firma ist und hat. Und ohne dem benötigt man auch keine Software. Es ist ein Ökosystem welches sich gegenseitig untereinander beeinflusst.
@@EducateReality Mag ja sein, aber wenn das Team kein Bock hat, brauchst du die Software auch nicht. Und wenn die Situation nicht zufriedenstellend ist kannst du nur an dir selber etwas drehen. "Toll ein anderer Machts" hat noch nie Funktioniert. Mann kann technische Schuld zum Beispiel einpreisen. Aber das funktioniert nur wenn das Team zusammen steht.
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...
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.
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?
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.
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.
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!)
Hey, ich habe vergessen den Titel zu ändern (dann wir standardmäßig der Name der Videodatei genommen), das hier war nur der Arbeitstitel und - da stimme ich Dir vollkommen zu - ist für die Intention des Videos absolut falsch. Ich habe ihn jetzt korrigiert, vielen Dank dafür! Gruß David
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.
Leider ist es so. Wir haben nicht mal Projektmanagement bei uns, alles komplett fehl-gemanaged. Da wird gebastelt und der Chef macht Versprechungen, die alle komplett ohne belastbare Grundlage sind. Mir ist das mittlerweile aber egal, ich tue was ich kann, nicht mehr. Versuche meine Rolle möglichst pragmatsich und professionell auszufüllen. Darüber hinaus schaue ich das ich mich weiterbilde um im Falle der Fälle den sinkenden Kahn gut und schnell verlassen zu können. Mal wieder sieht man wie schlechte Führung und Mismanagement einfach jede Firma kaputt machen können. Egal wie gut das Produkt, die Entwickler etc.
Unser Management hat keine Ahnung von der Software... Technische Schulden von 5 Jahren, keiner der verantwortlichen Softwareentwickler ist mehr angestellt. Die Software ist nicht getestet und von Anfang an ein MVP-Monster ohne anständige Architektur oder Dokumentation. Aufwand wurde für ein Upgrade auf neue LTS Komponenten mit Refactoring auf 40 Personentage geschätzt. Einarbeitung eines Teams ins Projekt natürlich schon inbegriffen, einfach nur lächerlich! Ich und das Team haben von Tag 1 an gesagt, dass die Schätzung jenseits von Gut und Böse ist und es ein vielfaches davon sein wird. Es ist nicht mit einem "composer update" erledigt nach 5 Jahren Stillstand verdammt! Hat keinen interessiert, das Ding fährt voll gegen die Wand. Eigentlich ist es schon gegen die Wand gefahren, aber das Management will es nicht wahrhaben und bald geht die Hexenjagd los...
th-cam.com/video/cyAwCe5XAIM/w-d-xo.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
Es ist schon sehr traurig dass wahrscheinlich nur die betroffenen Software Entwickler sich dieses Video anschauen, das Video verstehen und dir zustimmen. 😂😆
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.
Das erlebe ich gerade ganz anders: Ich arbeite an einem Projekt, dass kurz vor Veröffentlichung steht und die meisten Features in der letzten Zeit waren deutlich schneller entwickelt, weil sie an bestehenden Code anknüpfen konnten.
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.
Da hast du teilweise Recht. Aber die Planung eines Projektes liegt meist nicht in den Händen der Entwickler. Habe vor länger Zeit erlebt, wie der Projektleiter gleich 3 Projekte an die Wand gefahren hat. Das alte Projekt (ein Molch). Das neue Projekt mit Code aus dem alten Projekt (ein Molch). Ein drittes Produkt einer anderen Abteilung, das mit Hilfe unserer Entwickler angepasst wurde. Ziel war die vorherige Projekte überflüssig zu machen (mit Entlassung unser Abteilung). Das Ende vom Lied, dass alle in der Abteilung vorher das Weite gesucht haben, und alle drei Projekte um die Ohren geflogen sind.
Also sie erfüllen eine Funktion aber stellen keine Funktionalität bereit. Das ist bei nicht-funktionalen Anforderungen gemeint und ja, dieser Begriff ist irreführend, aber inzwischen etabliert.
Erfassen und planen kannst du so viel du willst. Wenn das Management Nein sagt, oder in der Planung die Tilgung dann über Monate/Jahre hinweg nach hinten schiebt, weil die neuen Features "wichtiger" sind, was willst du dann machen?
@@RCL89 Und warum ist das so? Weil das Management fast immer fachfremd ist. Wenn du keine Ahnung von Softwareentwicklung hast, kannst du als Produktmanager keine sinnvollen Entscheidungen. Das erzeugt Angst, und Angst ist kein guter Ratgeber. Und Feature lassen sich am besten Kontrollieren. So hat der Projektleiter immer noch das Gefühl das Projekt zu kontrollieren, aber stattdessen fährt das Projekt an die Wand
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...
Wäre ein interessantes Experiment. Es gibt Entwickler denen ich das zutraue. Leider gibt es aber auch solche die Fehlentscheidungen treffen. “Lass uns hier investieren, das können wir sicher öfters verkaufen”. Hier haben wir das selbe Dilemma zwischen Entwickler und Vertrieb, wie zwischen Management/Kunde und Entwickler.
@@olafschermann1592 Aber wenn das Management kein Wissen über Programmierung hat, wie soll es das Projekt leiten? Insbesondere kann er nicht vernünftig mit sein Entwickler reden kann, weil er schon die Begrifflichkeiten nicht versteht. Im Endeffekt bist du dann deinen Entwickler Hilflos ausgeliefert. Das erzeugt Angst, und Angst ist der schlechteste Ratgeber. Du gibst sinnlose Anweisungen, und Entwickler entwickeln schlechten Code.
… 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 … 😢😆
Ich kann Deine Meinung nicht ganz einordnen, vermutlich liegt deine Rolle außerhalb der Entwicklung. Natürlich müssen die Entwickler die technischen Schulden tracken und Strategien für die Umsetzung ausarbeiten - der PO hat da wenig Aktien dran, gib Deinen Leuten einfach die nötige Zeit dafür und die entsprechenden Tools, dann wird das ganz sicher klappen. Dein letzter Satz zeigt einfach nur das Du ohne jegliche Reflektion das Video geschaut hast, mit einer bereits vorher festgelegten Meinung. In keinem einzigen Satz wird behauptet das Entwickler frei von jeder Schuld sind. Aber vielen Dank für Deinen Post, der zeigt genau was das Problem ist: egal wer Mist baut, egal wie offensichtlich der gemachte Fehler ist, irgendwie bekommen wir den Entwicklern noch eine Teilschuld reingedrückt - notfalls werden Aussagen so umgebogen, dass Sie in den eigenen Kontext passen. Mega, Danke!
Jedes einzelne Wort in diesem Video trifft so unglaublich präzise auf die momentane Arbeitssituation von mir zu...
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 😒
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.
Sehr löblich, ist aber leider auch Projekt abhängig. Oft steht nicht ein Feature sondern 10 im Raum und dann sind 8 davon kritisch... Letztlich ist es so das man das Einplant um am ende 6 neue kritische Dinge fixen zu müssen usw. Letztlich ist dann am ende evtl. Refactoring für 2 oder 3 Features möglich und das wars....
@@kreativmonky einfach nicht stressen lassen. Dinge brauchen so lange wie sie nunmal brauchen. Ich kann auch nicht mit dem Flugzeug in Einer Stunde von London nach New York fliegen. Wenn du selbst schätzt und dann wegen dem Zeitdruck kleiner abschätzt, dann musst du Dir selbst die Frage stellen, ob das sinnvoll ist. Wenn dich niemand fragt und du nur machen sollst… dann läuft da etwas gewaltiges schief…
Dieses Video kann das wichtigste Video sein das du bisher produziert hast.. danke dafür!
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 👍
In der Forschung das gleiche 😢 Man muss abliefern, abliefern, abliefern.
Hier ein kurzes Update zur Lage. Aufgrund von diesem Video habe ich noch mal versucht, mit meiner Management Ebene Kontakt auf zu nehmen, um das Thema SW Qualität anzusprechen. Dabei habe ich erwähnt, dass ich mir selbst einen eigenen Anspruch gesetzt habe, was SW Qualität betrifft. Die Antwort von meinen Chef hat mich umgehauen. So ein eigener Anspruch existiert nicht. Wenn die Firma entschieden hat, SW in dieser Form bzw. Qualität als Produkt auszuliefern, habe ich mich dem zu fügen, weil ich letztens dann genau dafür bezahlt werde. Tja dann ist es für mich wohl entschieden.
Nichts einfacher als Features en masse zu implementieren, die nicht richtig funktionieren müssen 😉
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.
Ja, das treibt mich auch regelmäßig zur Weißglut.
ohje, das hört sich genauso an wie bei uns.
Ich hab mich leider mittlerweile auch damit abgefunden das wir einfach beschissene Software bauen. Ist echt traurig und demotiviert sehr stark. Hab dadurch auch irgendwo den Spass am Entwickeln verloren.
Da braucht ihr wohl gute Requirements Engineers und Scrum Master die Sprints vor spontanen Änderungswünsche schützen
@@horstkampfgarten5768 Und wie sollen die wissen, was der Kunde will, wenn der Kunde das selbst nicht 100% sagen kann.
Man müsste an solche Sachen wahrscheinlich iterativ rangehen. Lieber 60% die funktionieren, sinnvoll umsetzen und die benutzt werden, wie 100% schlecht programmiert und es werden eh nur 70% benutzt und nach n Jahren kommt ein anderer Kunde auf die Idee von den 30% ungenutzter Funktionalität nur einen Bruchteil zu nutzen und plötzlich schepperts.
Wir, die Kunden und alle anderen überblicken doch meist die gesamte Funktionalität nicht. Selbst alte Hasen vom Kunden haben nicht alles im Blick, vor allem bei Sonderfällen, Ausnahmen und weiss der Geier für Sonderlocken. Vor allen wenn man hunderte Kunden hat und es die wenigen gibt, die sich an keine Standards halten.
Das ist utopisch.
@@horstkampfgarten5768 Wenn es so etwas gibt, kannst sie gerne bei allen Projekten vorbei schicken.
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.
Wie jetzt: „in einem Projekt“? Mir scheinen wenigstens 80% der Projekte/Produkte so auszusehen.
@@christianibendorf9086Hatte ich tatsächlich nur 1 mal gesehen
@@christianibendorf9086So schlimm sehen die wenigsten Projekte aus.
Wenn alle alten Entwickler weg sind, solltest du dir einfach überlegen, sofort das Projekt zu wechseln.
Das ist normalerweise kurz vor dem kompletten Ende des Projekt.
@@MarvinDuck Du würdest staunen, wie lange man tote Pferde reiten kann. ;-)
Und: Nö, nach meiner Erfahrung sieht ein signifikanter Teil der Systeme und Teams so aus. :-(
@@christianibendorf9086 Ich weiß, wie lange man tote Pferde reiten kann. Ewig. 😉
Aber ein Projekt, wo alle alten Entwickler weg sind, sollte man sich nicht antun.
Meist hat es ein Grund, warum alle weg sind. Und den will man meist nicht selber heraus gekommen.
Danke David, mit diesem Video hast du mir aus der Seele gesprochen.
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. :-)
Es ist immer das gleiche. Egal wo man hin kommt, passiert immer das selbe. Mal schneller mal etwas langsamer. Ich habe mittlerweile aufgegeben mich darüber aufzugeben und lasse sie einfach ins Verderben rennen. Solange ich dafür bezahlt werde, ist es mor egal. Schont meine Nerven.
Ich würde sagen ein wertvolles video welches viral gehen müsste. Auch für die Zufriedenheit der Entwickler. Noch bevor sie an eine Kündigung denken
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.
Das hast du falsch verstanden. "Unternehmerisches Denken" ist doch genau das Denken bis zum nächsten Quartalsbericht.
@@cdoubleplusgood Leider wahr, wir rennen als produzierendes Unternehmen am Monatsende nochmal richtig, "damit der Umsatz gut aussieht". Dass der Umsatz vom Vormonat den vom Folgemonat auch betrifft...shitegal...Kann ich nicht verstehen. Einfach blind und sinnlos Druck machen, dann gehen die Zahlen schon nach oben oder so. Dass das am Ende am Auftragsbuch liegt, geschenkt. Hauptsache das middle Management hat Stress, das geben die dann weiter und dann arbeiten alle irgendwie effizienter und durch automagie werden die Umsätze besser.
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.
Frigger?!?
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 beantrage hiermit, dieses Video zur Prime Time im TV laufen zu lassen!
Jedes Wort so wahr. Und als Entwickler, selbst als Team Lead rennst Du Dir die Hacken wund beim Management, welches nur auf ROI und Gewinn schaut 😡
Super video, dass selbe was ich bereits angesprochen habe. Es wurde auf mich gehört. Wir haben uns hilfe gesucht, es ist aber zu viel um es mit der externen hilfe in kurzer zeit zu schaffen.
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.
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.
Im Prinzip ist es das gleiche.
Das Projekt verändert sich bei jedem Feature. Äußerlich bleibt es erst einmal gleich, aber innerhalb des Projektes verschlechtert sich immer mehr die Codebasis. Und irgendwann nehmen die Probleme zu.
Durch die immer neuen Features, verschwimmt auch das Ziel. Das Projekt entwickelt sich zu einem Schweizer Taschenmesser. Es kann alles, aber nichts richtig.
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.
Also ich arbeite in der IT Beratung schon seit Jahren und habe auch schon viele Softwareprojekte erlebt. Die meisten ignorieren das Problem nach meiner Erfahrung nicht, ich glaube da gibt es inzwischen genug Sensibilität für in der Wirtschaft. War sicherlich damals anders, aber ja ich kenne auch wirkliche Vollkatastrophen Projekte. Das schrecklichste war bei einer Behörde, wo 10 Entwickler beteiligt waren und ein Katastrophales Management plus schreckliche Schulden die Entwicklung extrem lähmt. Einarbeitung von drei/vier Jahren sind noch normal. Ich hatte nach ein paar Monaten kein Bock mehr darauf…
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.
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 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.
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?"
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.
Das beschreibt genau unser Projekt. Bin gespannt ob sich das mal ändert. 😢
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.
Was hier helfen kann, ist ein Faktor, mit dem die Schätzungen multipliziert werden. Dieser Faktor wird gebildet aus tatsächlicher Zeit / geschätzte Zeit.
Beispiel:
- Schätzung 5 Tage
- Tatsächliche Umsetzung 7,5 Tage
- Faktor 7,5 / 5 = 1,5
- nächstes Projekt, Schätzung 10 Tage * 1,5 = 15 Tage
- tatsächliche Umsetzung 17 Tage
- neuer Faktor 17 / 15 = 1,13
- nächstes Projekt, Schätzung 8 Tage * 1,13 = 9 Tage
Ziel ist es, den Faktor mit der Zeit auf 1,0 zu bekommen. Dann ist die Schätzung perfekt.
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.
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".
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.
Alter Schwede…. beim Lesen des Comments schrillen mir die Alarmglocken aus den Ohren raus.
Es geht dabei um Einschätzungen! Das sind keine Predictions! Das sind Schätzungen! Bitte nicht verwechseln! Einschätzungen werden sooo oft als Predictions betrachtet und als Deadlines oder Milestonetimestamps herangezogen.
Man orientiert sich NIE nach Schätzungen sondern an Taten welche bereits passiert sind!
Zur Verständnishilfe: Wenn ein fix und fertiges Ding einmal produziert wurde kann man beim 2ten mal genau das Gleiche produzieren und eine Prediction dafür abgeben, denn man ist den EXAKTEN Weg bereite einmal gegangen!
Wenn man eine Entwicklung hat und somit etwas erzeugt was es so EXAKT noch nie erzeugt wurde ist es eine Einschätzung. Es geht dabei darum dass der Weg erst beim Gehen erkundet wird ob man ihn wirklich geht. Eine Zeit lang geht und dann von einem Zwischenpunkt wieder retour geht und einen neuen Weg zu einem anderen Zwischenpunkt geht (refactoring).
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
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
Das ist allgemein das Problem, wenn es nur um kurzfristige Erfolge geht und Langfristige vernachlässigt werden
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.
Ich sehe deutliche Ähnlichkeiten zur Hardware Entwicklung. Fast schon beängstigend wie nah die Prozesse sind. Die Taubheit bei Kritik und das fehlende Bewusstsein für Prozesse mit vielen Stakeholdern ist bei uns genauso und fühlt sich erdrückend an. Es geht immer wieder um die zeitnahe, eierlegende, modulare, hoch-ästhetische Wollmilchsau für den einen Kunden oder die nächste Messe. Anstatt die Zeit für eine gut konzipierte Basis zu nutzen werden mittelmäßige Produkte - die bereits schlecht laufen mit unsinnigen Features versehen, weil ein Kunde das gern hätte (der dann aber wundersam wieder abspringt 😅).
Egal wie oft Bedenken angemeldet werden wird bei uns immer wieder gerne Entwicklung ausgelagert, damit wir schneller vorwärts kommen. Dass dadurch in 100% der Fälle mehr Arbeit entsteht brauche ich in dieser Runde sicher nicht erklären. Wie soll ein Externer das Framework verstehen wenn er nicht mal weiß wer der User ist, oder wie die Stammdaten aussehen sollen, oder welche Verfahren zum Einsatz kommen oder das Lager nicht kennt oder oder... Die nicht-funktionalen Richtlinien sind halt unfassbar wichtig und ich bin sehr dankbar, dass es von nun an einen Begriff dafür gibt 🎉.
So habe ich ein Handwerk zum Meister gelernt, einen Master im Studium erreicht und denke regelmäßig Gedanken unmotivierter, externer Entwickler neu, damit sie systemkompatibel sind und kein Kollaps stattfindet.
Geschaftsführung denkt wir Entwickler arbeiten zu langsam und verbreiten miese Stimmung wenn wir ehrliche und belastbare Aussagen zu Entwicklungszeiten treffen.
So werden wir oft nicht mehr gefragt, ob es Kapazitäten für neue Produkte gibt. Das erfahre ich als leitender Entwickler ganz nebenbei aus dem Marketing. Hoppla 🎉 eine Shitshow ohne Lernkurve
😂😂 Grüße und Dank gehen raus 😂😂
Könntest du vielleicht mal ein Video über Hexagonale Architektur (Core, Adapter) machen?
Vielleicht auch mit einem Projekt Beispiel?
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.
Hallo David... ich kann das so nur Unterschreiben. Ich bin Selber im Management und C-Level und ich bin erschrocken, wie viele "Entscheider" absolut keine Ahnung von Softwareentwicklung haben. Klar ich hab den Vorteil, dass ich selber IT Ingenieur studiert habe und selber Gross Systeme Entwickelt habe. Hauptsache Funktionalität und "Please the Customer" anstatt langfristig eine Strategie entwickeln... es ist leider in sehr vielen Unternehmen so.
Unter dem Begriff Feature Creep verstehe ich eher, dass Kunden im Rahmen der Entwicklung immer mehr zusätzliche, ursprünglich nicht vereinbarte Features durchzudrücken versuchen, vor allem bei agiler Entwicklung. Die übermäßige Beschränkung auf unmittelbarem Business Value, und dabei Vernachlässigung von Softwarequalität und Pflege, ist ein anderes, großes Problem. Vor allem Scrum kann hier anfällig sein, wenn das Management damit eine Art von oben vorgegebene Fließbandarbeit durchdrücken und die Entwickler an vermeintlich unproduktiven Codeänderungen und "Vergoldungen" hindern will.
Wenn man selbst kein Software-Architekt ist und vom Management auch nicht als solchen gesehen wird, hat man schlechte Karten. Zudem hat der Begriff "technische Schulden" immer auch eine abstrakte Dimension. Für die einen sind es technische Schulden, für die anderen eine geile pragmatische Art die momentanen Kundenbedürnisse zufrieden zu stellen.
Ich habe aber auch erlebt, dass kaum ein Kunde sich wünscht, dass man technische Schulden im Sinne von Fehlerhaftigkeit, Unwartbarkeit oder Unerweiterbarkeit anhäuft. Es waren immer Faktoren wie falscher Ehrgeiz oder Überforderung auf allen Seiten im Spiel. Gegen die man als Entwickler eh kaum etwas machen kann. Daher meine Erfahrung: Besser frühzeitig erkennen wann sich die Kollegen und das Management dazu verschwören technische Schulden zu machen. Gerne den konstruktiven Ausstieg suchen und die eigenen Befürchtungen thematisieren. Dann aber die Reissleine ziehen. Bevor man anfängt aufgrund dieser Schulden selber Dinge in den Sand zu setzen und die eigene Performance oder gar die eigene Gesundheit leidet.
Bei uns ist der Schlitten kurz vorm zusammenbrechen. Unwartbarer Code, aber es wird immer weiter dran gestrickt
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.
Ich habe festgestellt, dass bei Refactorings oder neu Implementierungen/Umstellungen oft und gerne Nebeneffekte übersehen werden. Schlimm ist es wenn es Showstopper werden
😀
Danke, einfach nur Danke. 🙂
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.
In einem Unternehmen, bei dem das Management für solche Aufgaben Zeit abstellt, sollte das Problem gar nicht erst entstehen. Das ist zumindest meine Erfahrung. Als Entwickler arbeite ich lieber an gut funktionierendem und leicht zu pflegendem Code. Es ist für mich schwer vorstellbar, dass ein Entwickler technische Schulden ansammelt, obwohl er die Möglichkeit hat, dort gegen zu steuern.
In meinem Berufsleben war ich bei einem Arbeitgeber beschäftigt der dafür keine Zeit bereitgestellt hat. Die Entwickler hätten sich auch selbst organisiert um die Probleme anzugehen doch das hätten sie in ihrer Freizeit tun müssen und dazu war wirklich niemand zu motivieren.
@@AtomicKnights Mein Punkt war, daß es auch an Entwicklern liegen kann, aber nicht muß. Ich habe es leider erlebt, daß Entwickler lieber manuell SQLs erstellen als dies geeigneten Klassen zu überlassen. Man möchte da einfach seine Arbeitsweise nicht ändern. Da hilft es auch nichts, wenn für diejenigen Fälle, in denen die Abstraktion nicht oder noch nicht greift, jederzeit auf handgeformte SQLs zurückgegriffen werden kann.
@@LarsPW So eine Blockade gegen den Fortschritt habe ich glücklicherweise erst selten erlebt. Spontan fallen mir zwei Gründe dafür ein:
- Rock-Star-Entwickler: Statt auf einer Technologie aufzubauen die von vielen im Team beherrscht wird bleibt man bei einer Technologie die nur von wenigen oder einer Person beherrscht wird. So verschafft man sich Status und Prestige. Zumindest in den Köpfen einiger Leute.
- Die Angst, sich selber abzuschaffen. Erledigt man in manueller Arbeit eine Aufgabe, die eigentlich automatisiert werden könnte, liegt das unter Umständen ander Angst um den eigenen Arbeitsplatz. Ist der Prozess ist automatisiert wird man persönlich ja nicht mehr benötigt.
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.
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.
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.
Product owner und Projektleiter seh ich in der Verantwortung dieses komplexe Thema dem Management näher zu bringen.
Oft werden nicht die besten Leute für diesen Job nominiert, sondern Leute die für Software-Entwicklung schon nicht die Besten sind.
@@olafschermann1592 Ja, und den Kunden. Denn die Kunden sind auch verantwortlich sinnvolle Requirements mit Product Owner zu gestalten. Was aber wenn der Kunde nicht genau weiss, was erwünscht ist. Viele Projekte sind derart komplex, da werden auch Details vergessen.
Der Prozeß muss viel agiler werden. Die Software kann auch mit 60% der Features zu Beginn laufen. Dann wird zum Großteil auch klar, was man wirklich benötigt. Diese Big Bang Prozeß erschließen, ist selbst bei kleinen Anforderungen zum Teil schlicht überfordert und selbst bei Anwendern, die man zu alten Hasen zählen würde.
Technische Schulden .... hatte ich bisher noch nicht gehört aber gibt's nicht nur in der Softwareentwicklung.
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.
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
Ist übrigens fast auf alle anderen Bereichen in der IT auch anwendbar. War Systemintegrator & Support Lvl2 und stand letztendlich vor den selben Problemen. hauptsache schnell schnell aber letzendlich ist die qualität miserabel
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!
Das Problem wird mit der Erfahrung der Entwickler kleiner.
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.
Yeah,... Ich schätze deine Situation natürlich falsch ein, leider klingt die Beschreibung sehr nach Hero-Einzelentwickler: Alle sind doof im anderen Team, die kriegen das sowieso nicht hin, also lieber selbst neu machen.
Wenn meine Wahrnehmung stimmt, würde ich als Teammitglied in diesem Team künftig vermeiden, dass du meinen Code siehst oder auch nur gefragt wirst.
@@hb-man keineswegs. Gibt durch aus viele andere Entwickler die sehr gut sind. Ändert nichts daran das jeder (auch ich) mal absoluten Blödsinn zusammen coden kann.
Ich bin bei Leuten, die mich schon etwas kennen, auch direkter. Diese Leute suche ich mir dann auch bewusst raus wenn ich mich über einen Code ärgere. Das ist aber eher die absolute Ausnahme. In über 5 Jahren in dem aktuellen Unternehmen, kam das zwei Mal vor. Zum einen wissen die Leute, dass auch ich umgekehrt es ebenfalls begrüße, wenn die Leute direkter mit mir reden und zum anderen soll das ganze Lösungsorientiert sein. Selbst wenn ich Leute als "inkompetent" betrachten würde (was nicht der Fall ist), dann wäre meine Schlussfolgerung, dass sie dann noch etwas lernen müssen. So wie mMn jeder andere Entwickler bzw. jede Entwicklerin ebenfalls. Mich ganz genauso mit eingeschlossen!
Das andere Team kam z. B. auf die Idee die Codes vor allen Entwicklern im Unternehmen vorzustellen und zu vergleichen (Geschwindigkeit, Speicherkapazität, Erweiterbarkeit usw.) um positive als auch negative Beispiele zu präsentieren. Wobei es eher darum gehen soll, aus Dingen zu lernen und nicht jemanden bloß zu stellen. Deswegen werden die Codes auch ohne Namen präsentiert.
Ich hatte eher die Anfrage an das Team ob man sich gegenseitig nicht häufiger die Codes reviewen sollte. Wobei es mir darum ging, dass auch andere Entwickler meinen Code sich anschauen, da ich ganz genauso Fehler mache.
Wenn auf einer Webseite "n" verschiedene Filter existieren und die Datenquelle, welche untersucht werden soll, insgesamt "n+1" mal vollständig gespeichert wird und beim filtern auch "n+1" Mal durchlaufen wird, dann ist das alles andere als effizient und sollte dringend überarbeitet werden. Dann ist das extrem ineffizient und frustriert auch den User, welcher unnötig lange warten muss und das wirft dann ein schlechtes Licht auf das Unternehmen. Erst recht wenn dieser Code von der Chefetage als "besonders Robust und effizient" beim User angepriesen wird.
Mit dem Entwickler, der das implementiert hat, habe ich bewusst nicht direkt gesprochen. Dafür kenne ich ihn und er mich zu wenig. Ich wollte also Missverständnisse vermeiden und ihn nicht angreifen. Sein Senior kennt ihn dafür besser. Zusätzlich kenne ich seinen Senior weiß , dass dieser mich einschätzen kann und weiß wie ich das meine.
Und ja, wenn ich das Gefühl habe, dass jemand nimmt eine Aussage von mir als Angriff auf, habe ich kein Problem damit die Leute nochmal zu kontaktieren und die Sache richtig zu stellen bzw. mich auch notfalls zu entschuldigen und im weiteren Verlauf auch vorsichtiger mit diesen Leuten umzugehen.
Letztlich arbeiten jetzt unsere Teams stärker zusammen und tauschen sich auch stärker aus. Ohne "böses Blut" zwischen uns.
@@quenton90 Wow, ich lag also richtig: "Ich schätze deine Situation natürlich falsch ein." 👍
@@hb-man Ist auch schwer ohne Mimik, Gestik usw. das richtig rüber zu bringen. Mir fällt es schwer solche Dinge auf dem Punkt zu bringen, sodass alle wichtigen Infos rüber kommen.
Daran muss ich definitiv noch arbeiten. 🙂
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.
das wäre ein guter Titel David!
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.
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?
Es gibt unendliche Wege zum Ziel.
Egal welche Architektur ihr nimmt, dokumentiert die Planung.
Und wenn jemand der andere Entwickler Probleme mit dem Verständnis hat, sollte ihr vielleicht den betreffenden Code/Architektur nochmals anschauen.
Gerade die Architektur muss jeder Entwickler verstehen.
gut gesprochen. Vielleicht liegt es ja nicht daran, dass die Führungskräfte das Problem nicht erkennen können (wegen Unerfahrenheit, mangelnder Kenntnis, oder gar nur der Idee, dass IT nicht anders sein müsste als Brötchen backen) sondern daran, dass es in den Köpfen von allen (!!!) Beteiligten immer noch die Vorstellung gibt, dass IT ja ganz einfach ist, weil man sogar Schüler zum Programmieren bringen kann. Komisch dass Mathematik da einen ganz anderen Ruf hat. Da werden viele gleich ganz still. Für mich ist Mathe und Informatik sehr nah beieinander aber da stehe ich auch nicht mit der Mehrheit. Mit IT kann man aber wie es scheint, auch schnell Kohle machen und es läuft lange ganz gut. Da merkt man den schleichenden Verfall zu spät (Frosch im Boiler).
Oh, es gibt dazu noch so viel mehr zu sagen ...
Ich bin selbst als Software-Architekt unterwegs, habe schon so manches Großprojekt von innen gesehen und kann alle Aussagen in dem Video so unterschreiben. Insbesondere mit den 20% für technische Aufarbeitung hat bei meinem letzten Projekt wahre Wunder bewirkt - wenn auch über einen langen Zeitraum.
Zwei Aspekte möchte ich jedoch nochmal herausgreifen:
1. Ich sage den Entwicklern immer wieder, dass sie ein Stück weit selbst dafür verantwortlich sind, die 20% für Refactorings mit in ihre Kapazitätsplanung mit einzupreisen. Zur Not auch versteckt von dem Management. Habe ich selbst immer gemacht und kein Manager hat mich auch nur danach gefragt - weil die meisten es nichtmal geblickt haben. Aber egal wie oft ich das sage, die meisten Entwickler machen das einfach nicht! Warum nicht?!
2. Wie kann ich das alles den Managern auch wirklich so begreiflich machen? Wenn ich diesen Vortrag vor meinem aktuellen versammelten Entwicklungsmanagement halten würde, würden die meisten nur mit den Schultern zucken und sagen, dass sie das Problem nicht hätten, obwohl wir Architekten schon kilometerlang schriftlich festgehalten haben, wo die Probleme liegen. Da werden wir aber nur als Schwarzmaler, Wichtigtuer und Perfektionisten abgetan. Wie soll man da das Management noch erreichen bzw. zur Raison bringen?
Wie schaffe ich jetzt, dass die ganzen Wasserköpfe von der Konzernführung bis runter zu meinem PO/PM sich dieses Video anschauen?
Gar nicht. Die haben andere Interessen. Meistens in Euro. 👍😁
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ß.
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.
glaube ich nicht. Das Produkt und Business besteht aus allem was die Firma ist und hat. Und ohne dem benötigt man auch keine Software.
Es ist ein Ökosystem welches sich gegenseitig untereinander beeinflusst.
@@EducateReality Mag ja sein, aber wenn das Team kein Bock hat, brauchst du die Software auch nicht. Und wenn die Situation nicht zufriedenstellend ist kannst du nur an dir selber etwas drehen. "Toll ein anderer Machts" hat noch nie Funktioniert. Mann kann technische Schuld zum Beispiel einpreisen. Aber das funktioniert nur wenn das Team zusammen steht.
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...
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.
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?
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.
👍👍
Vielen Dank für das Video
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.
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!)
Hey,
ich habe vergessen den Titel zu ändern (dann wir standardmäßig der Name der Videodatei genommen), das hier war nur der Arbeitstitel und - da stimme ich Dir vollkommen zu - ist für die Intention des Videos absolut falsch. Ich habe ihn jetzt korrigiert, vielen Dank dafür!
Gruß David
@@DavidTielke Danke!
Ich hätte mal eine andere Frage, lohnt es sich mit 38 noch an Softwareentwicklung zu werden? Oder sagt ihr lass es?
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.
Dem schließe ich mich an.
Leider ist es so.
Wir haben nicht mal Projektmanagement bei uns, alles komplett fehl-gemanaged.
Da wird gebastelt und der Chef macht Versprechungen, die alle komplett ohne belastbare Grundlage sind.
Mir ist das mittlerweile aber egal, ich tue was ich kann, nicht mehr.
Versuche meine Rolle möglichst pragmatsich und professionell auszufüllen.
Darüber hinaus schaue ich das ich mich weiterbilde um im Falle der Fälle den
sinkenden Kahn gut und schnell verlassen zu können.
Mal wieder sieht man wie schlechte Führung und Mismanagement einfach jede Firma kaputt machen können.
Egal wie gut das Produkt, die Entwickler etc.
Unser Management hat keine Ahnung von der Software... Technische Schulden von 5 Jahren, keiner der verantwortlichen Softwareentwickler ist mehr angestellt. Die Software ist nicht getestet und von Anfang an ein MVP-Monster ohne anständige Architektur oder Dokumentation.
Aufwand wurde für ein Upgrade auf neue LTS Komponenten mit Refactoring auf 40 Personentage geschätzt. Einarbeitung eines Teams ins Projekt natürlich schon inbegriffen, einfach nur lächerlich!
Ich und das Team haben von Tag 1 an gesagt, dass die Schätzung jenseits von Gut und Böse ist und es ein vielfaches davon sein wird. Es ist nicht mit einem "composer update" erledigt nach 5 Jahren Stillstand verdammt!
Hat keinen interessiert, das Ding fährt voll gegen die Wand. Eigentlich ist es schon gegen die Wand gefahren, aber das Management will es nicht wahrhaben und bald geht die Hexenjagd los...
th-cam.com/video/cyAwCe5XAIM/w-d-xo.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
Es ist schon sehr traurig dass wahrscheinlich nur die betroffenen Software Entwickler sich dieses Video anschauen, das Video verstehen und dir zustimmen. 😂😆
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.
Das erlebe ich gerade ganz anders: Ich arbeite an einem Projekt, dass kurz vor Veröffentlichung steht und die meisten Features in der letzten Zeit waren deutlich schneller entwickelt, weil sie an bestehenden Code anknüpfen konnten.
Aber wir haben das doch schon immer so gemacht!
Ja, ja und ja ;)
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.
Da hast du teilweise Recht.
Aber die Planung eines Projektes liegt meist nicht in den Händen der Entwickler.
Habe vor länger Zeit erlebt, wie der Projektleiter gleich 3 Projekte an die Wand gefahren hat.
Das alte Projekt (ein Molch). Das neue Projekt mit Code aus dem alten Projekt (ein Molch). Ein drittes Produkt einer anderen Abteilung, das mit Hilfe unserer Entwickler angepasst wurde. Ziel war die vorherige Projekte überflüssig zu machen (mit Entlassung unser Abteilung).
Das Ende vom Lied, dass alle in der Abteilung vorher das Weite gesucht haben, und alle drei Projekte um die Ohren geflogen sind.
Also sie erfüllen eine Funktion aber stellen keine Funktionalität bereit. Das ist bei nicht-funktionalen Anforderungen gemeint und ja, dieser Begriff ist irreführend, aber inzwischen etabliert.
Erfassen und planen kannst du so viel du willst. Wenn das Management Nein sagt, oder in der Planung die Tilgung dann über Monate/Jahre hinweg nach hinten schiebt, weil die neuen Features "wichtiger" sind, was willst du dann machen?
@@RCL89 Und warum ist das so?
Weil das Management fast immer fachfremd ist. Wenn du keine Ahnung von Softwareentwicklung hast, kannst du als Produktmanager keine sinnvollen Entscheidungen.
Das erzeugt Angst, und Angst ist kein guter Ratgeber. Und Feature lassen sich am besten Kontrollieren. So hat der Projektleiter immer noch das Gefühl das Projekt zu kontrollieren, aber stattdessen fährt das Projekt an die Wand
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....
Robert Jackal - Moral Mazes. Nichts mehr zu lesen/sagen
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...
Wäre ein interessantes Experiment. Es gibt Entwickler denen ich das zutraue. Leider gibt es aber auch solche die Fehlentscheidungen treffen. “Lass uns hier investieren, das können wir sicher öfters verkaufen”. Hier haben wir das selbe Dilemma zwischen Entwickler und Vertrieb, wie zwischen Management/Kunde und Entwickler.
@@olafschermann1592 Aber wenn das Management kein Wissen über Programmierung hat, wie soll es das Projekt leiten?
Insbesondere kann er nicht vernünftig mit sein Entwickler reden kann, weil er schon die Begrifflichkeiten nicht versteht.
Im Endeffekt bist du dann deinen Entwickler Hilflos ausgeliefert. Das erzeugt Angst, und Angst ist der schlechteste Ratgeber.
Du gibst sinnlose Anweisungen, und Entwickler entwickeln schlechten Code.
Nichts neues. Immer das selbe Spiel mit Kunden / Management das keine Ahnung von Softwareentwicklung hat. Been there done that many times.
Does youtube think im german or something?
Use the auto translate function!?!
Just learn German. It's easy and fun🎉
… 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 … 😢😆
Ich kann Deine Meinung nicht ganz einordnen, vermutlich liegt deine Rolle außerhalb der Entwicklung. Natürlich müssen die Entwickler die technischen Schulden tracken und Strategien für die Umsetzung ausarbeiten - der PO hat da wenig Aktien dran, gib Deinen Leuten einfach die nötige Zeit dafür und die entsprechenden Tools, dann wird das ganz sicher klappen.
Dein letzter Satz zeigt einfach nur das Du ohne jegliche Reflektion das Video geschaut hast, mit einer bereits vorher festgelegten Meinung. In keinem einzigen Satz wird behauptet das Entwickler frei von jeder Schuld sind. Aber vielen Dank für Deinen Post, der zeigt genau was das Problem ist: egal wer Mist baut, egal wie offensichtlich der gemachte Fehler ist, irgendwie bekommen wir den Entwicklern noch eine Teilschuld reingedrückt - notfalls werden Aussagen so umgebogen, dass Sie in den eigenen Kontext passen.
Mega, Danke!