Video

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

Ich 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. :-)

Was für Aspekte meiner Meinung nach komplett vergessen/unterschlagen wird * Rollen und Verantwortlichkeite: Zwei Personen != 200% Leistung, da die beiden Personen ein gemeinsames Verständnis entwickeln müssen und dafür geht Zeit drauf. (nicht zu vergessen Agiles Principles: Business people and developers must work together daily throughout the project. ) * Und das Thema der prozentualen Aufteilung ist auch total unrealistisch (Ideal ist doch nicht alles mit 10%, eine Anforderung die in z.b. 2h erstellt wird, braucht vielleicht 20h fürs coden oder andersrum) * Ein Aspekt den ich oft sehe, dass Menschen sich völlig überschätzten, man nicht auf erfahrene Kollegen hört. Wenn das Kind dann in den Brunnen gefallen ist, verkrümelt man sich leise und erspart sich neben dem Lerneffekt auch das übernehmen der Verantwortung. * Und last but not least "Working software is the primary measure of progress." ob man dafür eine Build Pipeline braucht oder nicht steht da nicht drin. * Der für mich wichtigste Punkt ist "Keep it simple stupid" und zwar durch den kompletten Prozess * Und mein Lieblingskonzept ist den Entwickler zum Kunden zu schicken oder mal Abends um 22 Uhr noch die DB fixen lassen, nachdem man mit dem letzten Patch alles kaputt gemacht hat. Klar kann man mit dem Ideal am Ende erfolgreich sein, aber das kostet dann halt auch und muss erwirtschaftet werden. Der für mich spannende Bereich bewegt sich zwischendrin. Wo man mit möglichst wenig Ressourceneinsatz, langfristig möglichst viel Herausholen kann. Das ist übrigens auch das womit Scrum gestartet ist - einem Baukasten von dem man sich nur das herausnimmt was tatsächlich benötigt wird - wie halt im echten Leben ;-) Da ist mir auch noch keiner begegnet der sich die große Hilti kauft nur um ein Bild aufzuhängen... Und weil der Monolith noch erwähnt wurde, da möchte ich gerne an den Vortrag "Keep it simple? My Ass!" von Dr. Karl-Heinz Wichert erinnern. Microservices sind teuer und ein Monoltih nicht per se schlecht.

Man kann immer wtwas tun. Es steht und fallt mit dem entwickler team. Ich bleibe mal in Scrum. Das team trägt die Verantwortung, sinst niemand. Alles andere ist augenwischerei.

Danke, einfach nur Danke. 🙂

Wie gings mit der firma weiter?

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.

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...

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?"

Zuerst mal Respekt! Ein Video zu einem der größten Probleme der Softwareentwicklung zu machen, dass sich explizit an die "Nicht-Entwickler" richtet und direkt im Einstieg zu teasern "Jup... Ihr seid meistens Schuld." Mutiger Einstieg. Polemik beiseite. Im ersten Teil gehst du stark auf sogenannte "nichtfunktionale Anforderungen" ein. Ich würde gerne auf einen 8 Jahre alten Post von Jutta Eckstein verweisen "Nichtfunktionale Anforderungen - was soll das sein?" (Link spare ich mir, CZcams mag die nicht so, aber man findet das recht schnell bei heise). Kurzzusammenfassung: In den meisten Fällen sind "nichtfunktionale" Anforderung einfach nur falsch kategorisiert und für irgendwen erfüllt es eine Funktion. Das klingt nach jetzt erst mal nach Haarspalterei, aber wenn es weiter denkt, würde es bedeuten, dass statt sich 3 Dinge zu sparen, auf einmal nur noch 2 Dinge fehlen (Zeit & Wissen). Leider sind diese beiden Dinge nicht minder wichtig. Für Wissensaufbau sind wir zu einem guten Stück selbst verantwortlich und es liegt in unserem ureigenstem Interesse (so als Wissensarbeiter). Die Zeit dafür zu haben, ist Aufgabe des Arbeitgebers. Wer selbstständig ist, muss das halt mit sich selbst ausmachen 😉 Was heißt das in der Konsequenz für mich als Entwickler? Nun... Um das zu beantworten, möchte ich meinen Fahrlehrer zitieren. Klingt komisch, ergibt aber gleich Sinn. Er stellte in einer Theoriestunde die Frage, was die Grundvoraussetzung dafür sei ein KfZ durch den Straßenverkehr zu manövrieren? Die Antwort: Man muss "Nein" sagen können. "Nein, ich kann es nicht in 30 Minuten zum Ziel schaffen. Wenn ich das versuche, spiele ich mit dem Leben aller Verkehrsteilnehmer, die mir so begeben" (als Beispiel). Diese Maxime begleitet mich seit dem und das sind jetzt auch bald 20 Jahre. Wenn ich will, dass irgendetwas ordentlich läuft, muss ich in der Position sein "Nein" zu sagen. Bin ich das nicht, bin ich dort falsch. Ich habe auch schon als Softwareentwickler "Nein" gesagt. Mal war das Ergebnis, dass ich es besser erklärt bekommen habe, mal das wirklich Dinge nicht gemacht wurden. Ein Mal habe ich wider besseren Wissens und nachdem ich durch 3 Instanzen Produktmanagement (CPO als letzte Instanz) gegangen bin, eine Anforderung umgesetzt, die keinen Sinn ergeben hat und den Code komplexer und schwerer zu verstehen. Mein Fazit an Entwickler: Traut euch, auf euer Bauchgefühl zu hören und artikuliert das (entwickelt dabei Feingefühl!!!) Mein Fazit für Produktmenschen und Manager*innen: Hört Entwicklern zu die "Stunk" machen. Ihr findet schnell raus, ob da jemand Bock auf Krawall hat oder ob ihr jemanden habt, der ernsthaft daran interessiert ist Dinge besser zu machen (letzteres ist eh viel wahrscheinlicher).

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.

czcams.com/video/cyAwCe5XAIM/video.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

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.

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

220 Zeilen Code pro Klasse? Lächerlich. Das haben bei uns die meisten Funktionen schon, wenn das überhaupt reicht. Und eine Ebenentiefe >10 ist normal

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

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.

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.

Bei den ganzen Patterns muss ich immer an ein Video von Scott Wlaschin denken. "Functional design patterns"

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.

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

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.

Ich denke, 80:20 ist viel zu wenig. Meiner Erfahrung nach muss man für nicht-funktionale Anforderungen mindestens gleich viel Zeit aufwenden wie für funktionale, oft sogar mehr. Wenn man z.B. wirklich gute Unit Tests haben will, die wirklich fast alles abdecken, dann bestehen diese oft aus mindestens genauso viel Code wie der Code, den man damit testen will. Wirklich gute Unit Tests z.B. testen nicht nur jede Funktionalität, sie testen auch jeden Fehlerfall, d.h. sie stellen sicher, dass Code auch in jeder Fehlersituation den richtigen Fehler liefert (also Fehler auch richtig erkennt und korrekt meldet) bzw. den Fehler richtig behandelt (wenn die Behandlung intern erfolgt). Und sie testen auch die Performance und den Ressourcenverbrauch, denn nicht immer führt ein Refactoring zu Fehlern, manchmal führt es nur dazu, dass der Speicherverbrauch explodiert oder der Verarbeitungsdurchsatz einbricht. Um all dies zu testen, muss viel Testcode geschrieben werden. Nicht zuletzt, weil man oft viel Code braucht, um überhaupt ein Testszenario zu erstellen, das dann z.B. einen Fehler provoziert. Und dann reicht es nicht, jede Unit für sich zu testen, denn Fehler können auch im Zusammenspiel von Units auftreten. Ich brauche also auch Integrationstests, die sicherstellen, dass übergeordnete Funktionalitäten, die aus vielen einzelnen Units bestehen, korrekt funktionieren. Der Code zum Verbinden der Units kann winzig sein, der Testcode ist es aber meistens nicht, weil man hier oft extrem viele Testfälle hat, die abgedeckt werden müssen. Und Tests sind aus der Sicht von Managern und Kunden nicht-funktional, weil die bringen keine neue Funktion oder etwas, das man vermarkten könnte. Tests sichern jedoch langfristig die Integrität und Stabilität dessen, was in der Vergangenheit geschaffen wurde, und sind daher unerlässlich. Wenn also ein Feature an sich 3 Tage Entwicklung kostet, dann braucht man nicht selten 3 Tage für wirklich vernünftige Unit Tests, dann aber noch einen Tag für die Integration in den bestehenden Code und 1-2 Tage für Integrationstests. Für das Management ist das dann ein 4-Tages Feature, aber will man auf Dauer eine wartbare Anwendung, dann ist das locker ein 8-9 Tage Feature. Und dazu kommen im Laufe der Zeit noch notwendige Refactorings, die nichts direkt mit irgendeinem Feature zu tun haben, aber auch notwendig sind, um das Projekt über viele Jahre erweiterbar zu halten. Diese sind auch oft notwendig, weil neue Betriebssystemversionen oder neue Hardware Anpassungen notwendig machen, denn wer hier nicht mit der Zeit geht, dessen Software geht mit der Zeit, irgendwann verschwinden Deprecated APIs komplett und auf einmal ist die Software auf modernen Systemen nicht mehr lauffähig. Oft hatte man viele Jahre Zeit sich darauf einzustellen, aber wenn man wartet bis die API weg ist, dann hat man plötzlich einen enormen Zeitdruck, sonst können die Kunden mit dem nächsten Systemrelease die Anwendung gar nicht mehr nutzen. Also sobald ein Hersteller ankündigt, hier wird sich in den nächsten Jahren etwas massiv ändern, muss man sofort aktiv werden und die notwendigen Änderungen planen und irgendwo zeitlich unterbringen und das sind auch alles nicht-funktionale Anforderungen.

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.

Tja, die Herren Brooks und Conway hatten schon vor fast genau 50 Jahren recht… insbesondere Conway’s Gesetz beschreibt die Ursache: Wenn die Kommunikation im Unternehmen durch Ignoranz und Hilflosigkeit geprägt ist, brauch man sich am Ende nicht über eine Software zu wundern, bei der keiner weiß, wie die Fehler zu beheben sind, und man völlig hilflos vor dem riesen Scherbenhaufen steht :-/

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.

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!

Warum denn Angst als Begriff? Ich würde es als Respekt, gepaart mit Erfahrung bezeichnen. Und bei den Objektiven kann ich den Selbstfrust gut nachvollziehen. Da wirkte aber relativ früh beim Rucksack das Thema Redundanz mit - ich bin da sehr aus dem Klettersport noch geprägt. Neben dem Reißverschluss sichern eben noch Fixierungen, die über die Fächer gehen, die darin befindlichen Objektive und Kameras.

Ich habe 1997 nur einen Grundstock gelegt, dann auf meiner Homepage als alleiniger Entwickler veröffentlicht. Innerhalb einer Woche einen Partner gefunden, der zu der Zielgruppe gehört => Gastronomie in GROSS. Die ersten Kunden "eingesammelt" und konsequent auf sie gehört was sie gerne wünschen. Sobald ein Wunsch mehrmals kam, habe ich es implementiert. Immer im Blick das das vorhandene nicht dadurch beschädigt wird (Stichwort: Kommandozeilen-Parameter). Man darf auch nicht vergessen, das es gesetzliche Anforderungen gibt, diese haben sich im Laufe der Zeit verdoppelt. Diese Vorgehensweise (naßforsch?, einfach mal anfangen) ist heutzutage gar nicht mehr in dieser From möglich - schon alleine wegen Scrum! Nach über 25 Jahren sind in meinem Projekt auch die technischen Schulden abgearbeitet - es ist aus- und abgearbeitet. Nicht mal Bugfixes gibt es zu tun. Und jetzt kommts, die neue Firma (Übernahme) hat nun ein neues Projekt mit neuen Entwicklern angefangen - mit den gleichen Problemen was Du hier anspricht - obwohl ja schon eines fertiggestellt ist und erfolgreich läuft, tz P.S. Du müsstest mein PO sein :)

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.

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?

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

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

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.

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.

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

Wir 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.

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

Ich 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.

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

Ich habe nun in mehrerlei Hinsicht geschmunzelt: 2017 bin ich in ein Start-Up als Eierlegendewollmilchsau, baute die gewünschte Software und alles, was das Herz begehrte. Und statt Feature-Queue gab es dann eben immer mehr Refactoring-Warnings meinerseits. Blieben aber ungehört, "Hauptsache läuft!" und jede Menge enttäuschende Floskeln. Als dann Features nicht mehr aus dem Ärmel sprudelten und es immer mehr Zeit für die Implementierung brauchte (und ich meine Wochenenden auf der dortigen Couch verbrachte), gab es die Frage, warum nicht - denn (Zitat) "Google und Amazon können das ja auch". Habe mich mit 900 Überstunden aus den allein letzten beiden Jahren abwerben lassen - absolut ungesund (Betrieb wurde an die Wand gefahren). Bei einem meiner eigenen Produkte (seit 2006 am Markt) habe ich ein komplettes Refactoring gemacht - bin ich super stolz drauf: ein Web-Projekt, welches organisch ab 2005 gewachsen ist; gerüttelt an allem, was man heute so nicht mehr macht - es wurden 2,2 GB umgeschrieben, Datenbankstruktur neu usw. Alles. Und die Bestandsdaten gehen auch mit. Dauer: knapp sechs Jahre in meiner Freizeit. Hier gab es aber parallelen Betrieb: weitere Feature für die alte Version, Refactoring neue Version ... ein Wahnsinn! Jetzt steht das Release bevor ... und ich freue mich total darauf. Danke, Herr Tielke, für dieses Video ... es kam nur zu spät (kein Vorwurf!).

Man kann nicht nur kochen, sondern muss auch mal das Geschirr spülen - und das gilt auch in der Softwareentwicklung. Teilweise fehlt dem Management diese Perspektive. Das ist die eine Seite der Medaille. Die andere Seite ist die Fähigkeit der Köche, ein Gericht an mehreren Tagen (also wiederholbar) gut zu kochen. Klar kann auch mal ein Gericht daneben gehen, aber grundsätzlich sollte der überwiegende Teil „gut“ sein. Das mag für den einen oder anderen Entwickler etwas „harsch“ klingen, aber so ist meine Erfahrung aus mehr als einem Jahrzehnt als Softwareentwickler. Jetzt kann man den Kopf in den Sand stecken oder an beiden Medaillenseiten arbeiten. Als Koch sollte man in der Lage sein, Gerichte wiederholbar gut auf den Tisch zu bringen. Hier gibt es sicher viele unterschiedliche Werkzeuge. Mein primäres Werkzeug sind automatische Tests. Wenn man sich versehentlich einen Induktionsherd in die Küche vom Management hat reinstellen lassen (obwohl der Gasherd in der Gastroküche vielleicht besser gewesen wäre), muss man als Koch einsehen, dass es für den Restaurantbetrieb unrealistisch ist, mehrere Wochen Pause zu machen, um einen Gasherd einzubauen - damit ist der „Magic Big Bang Rewrite“ gemeint. Erfahrungsgemäß gibt es auch andere und meist kleinere Schrauben, an denen man für ein „gut genug“ Ergebnis drehen kann. Und wenn es nicht gut genug ist, kann man ohne schwitzige Hände (mit den automatischen Tests) nachjustieren und hat ein schnelles Feedback, ob nichts kaputt geht. Ein guter Koch kann trotz widriger Rahmenbedingungen, an denen er nicht spontan drehen kann (in unserem Beispiel die Herdart), trotzdem überwiegend gute Gerichte kochen. Das schafft über Zeit Vertrauen beim Management. Und wenn man transparent machen kann, warum der Gasherd wichtig ist und welche positiven Konsequenzen ein Tausch trotz der Kosten hätte, ist das ein Thema, das man mit gemeinsamem Vertrauen angehen kann. Leider gibt es auch Restaurants, wo das Management völlig irrational handelt und keine Arbeitsbeziehung auf Augenhöhe anstrebt. Hier kann man sich nach einem anderen Restaurant umsehen. Falls ihr euch mit anderen Restaurants auf statistischer und globaler Ebene vergleichen wollt, kann ich die Google DORA Four Key Metrics empfehlen. Die Ergebnisse der Metriken selbst bieten zunächst nur eine Einschätzung. Wichtig finde ich die Fähigkeiten, die "High Performer" sich erarbeitet haben und nutzen, um Software gut und schnell zu produzieren.

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.

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.

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.

Wir haben zu Beginn des Projektes, dass nun schon ein paar Jahre läuft quasi lockere Leinen und fast alle Möglichkeiten bekommen. Allerdings waren die Technologien schon vor Beginn der funktionalen Entwicklung mit einer handvoll Architekten festgezurrt. Das muss jetzt so gemacht werden. Das ging eine Weile gut. Allerdings wurde die Entwicklung im 3. oder 4. Jahr immer langsamer und der Kunde immer lauter, denn dieser wollte funktionalen Fortschritt sehen. Vereinbarte Meilensteine wurden verfehlt und der Anwendung fehlten die versprochenen Funktionen. Die Entwicklung wurde während dieser Phase komplett auf das SAFE-Framework umgestellt und die SCRUM basierte Entwicklung beendet. Wir befanden uns nun im agilen Wasserfall. Es wurde uns aber bei einer fest vorausberechneten Kapazität pro viertel Jahr nun auch ein Prozentil an Innovation/Refactoring Zeit gewährt. Allerdings ist der Prozess unglaublich schwerfällig, da solche Refactoring dann in Tickets gegossen werden müssen und der Nutzen dokumentiert werden muss. Wird schwer, hier dann als Entwickler die richtigen Worte zu finden. Wir haben uns nun in unserem kleinen Team (einem von 10) dazu entschieden 2-3h pro Woche herzunehmen um im Pairprogramming eine Schuld abzubauen. Diese Merge Requests unterliegen dann aber der selben Qualitätssicherung und Review wie alle Funktionalen Sachen die wir bauen. Damit fahren wir nun besser als zuvor. In der Zeit in der wir all das gemacht haben ist uns der Hauptsponsor des Projektes abgesprungen, schade. Aber wir haben noch weitere Kundschaft und einen Konzern im Hintergrund, der uns sehr gern unterstützt.

Das Problem: Features bringen Geld und erzeugen Lob, langlaufende Refactorings kosten Geld und erzeugen Tadel. Meine Lösung: Refactoring immer "nebenher" parallel zu den Features unsetzen. Niemand vom Management will es sich leisten, 6 Monate oder länger keine neuen Features zu bekommen. Es ist die Aufgabe der DEVs, die Zeit dafür einzufordern! Es ist eure Genugtuung, und es ist euer Spaß am Job, um den es geht! 10-20% sind eine Größenordnung, die funktionieren kann. So haben wir ein Framework-Update (Laravel 4 > 9) parallel neben der Feature-Entwicklung über eine Laufzeit von 18 Monaten geschafft. Stück für Stück der Anwendung migriert, beide Systeme liefen parallel, bis das alte abgeschaltet werden konnte.

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.

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.

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.