2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Du kannst nein sagen so oft du willst - da kommen dann von den vorgesetzten Meldungen wie "du siehst immer nur Probleme, ich will Lösungen" - wenn du dann die Lösung "wir brauchen mehr Zeit und müssen mehr Geld dafür verlangen oder wir müssen die Features reduzieren" kommt, hast du eine Endlosschleife (oft genug erlebt).

Insbesondere muss er NEIN sagen, NEIN meinen, und dann diese Aussage auch durchhalten. Wenn er NEIN sagt, es dann aber dennoch versucht, und dann scheitert, ist er der Doofe.

Das funktioniert in der Praxis nicht - du kannst nicht "NEIN" sagen und dich zurücklehnen und nichts mehr tun, weil du ja nein gesagt hast - da brauchst du schon einen sehr gutmütigen Chef der das Mitmacht.

Wenn er NEIN sagt, trotz hohem Drucks, und sein Chef glaubt ihm nicht, dann ist der Chef der Doofe, weil er trotz gegenteiliger Aussage nach außen kommuniziert hat, es ginge doch.

Auch wenn sich der Chef die Schläge beim Kunden abholt, das wird immer nach unten durchgereicht.

Und der Chef hat in diesem Fall auch die Chance verspielt, die wahren Interessen hinter dem Termindruck zu ermitteln und zu erforschen, was zu dem Termin tatsächlich geliefert werden soll - und warum.

Ich stimme dir voll und ganz zu - aber du bist hier einfach realitätsfremd.

Wenn ein Entwickler unter Zeitdruck, weil er nicht NEIN sagen konnte, irgendwas zusammengecodet hat, dürfte die beste initiale Struktur durch diese Aktion recht untrennbar zu einem unansehnlichen Codemüll zusammengebacken worden sein. Das wieder sauber aufzutrennen ist eine sehr schwierige und aufwendige Aufgabe.

Ja - darum ist in vielen Fällen ja nicht der $Vorgänger ein Trottel der nicht programmieren kann, sondern der unter Zeitdruck Mist gebaut hat und dann gagangen wurde, weil er zu oft NEIN gesagt hat - auch schon oft genug erlebt.

Wenn es die Struktur der Software in ihren Grundfesten erschüttern kann, weil ein Feature nicht so wie anfänglich geplant umgesetzt werden soll, war vermutlich mit der Struktur was falsch.

Nein - du lebst in einer idealen Welt in der es genug Zeit und Geld gibt immer alle möglichen Erweiterungen vorzusehen und entsprechende Erweiterungsmöglichkeiten zu schaffen. In der Geiz-ist-Geil-Welt sieht das aber leider anders aus - und es kommt nicht selten vor.

Ein einfaches Beispiel: Kunde will eine Youtube-API-Anbindung - programmierst du da jetzt gleich einen Abstraktionsschicht um später mal andere Video-Dienstleister-APIs verwenden zu können oder eben doch direkt?

Finanziell wird sich die "wir sehen mal in die Zukunft vor" idR. nicht spielen.

Und wenn die neue Anforderung nicht problemlos in den Code hineingetan werden kann, war vielleicht auch mit der Software-Entwicklungs-Methodik was falsch.

Die Methodik leidet fast immer unter Zeitdruck - meistens gibts nichtmal Zeit eine Software ordentlich zu dokumentieren Geschweige denn zu testen. Ich hab' auch schon erlebt, dass ein komplexe Software ohne Pflichtenheft zu einem völlig irren, auch nach Daumen-Mal-Pi-Schätzung, Preis verkauft wurde. Bauchgefühlschätzung war "irgendwo 2 Monate" und verkauft wurde es um gute 2 Wochen - das hat dann zu unbezahlen Extraschichten über Weihnachten und Neujahr geführt - weil der Online-Termin auf kurz vor Weihnachten zugesagt wurde.

Und wenn ein nicht mehr benötigtes Feature nicht ohne Angst, dass man zuviel entfernt und deshalb Dinge kaputt macht, wieder herausgenommen werden kann, dann hat man vielleicht keine funktionierenden Tests.

Nein, nicht "kaputt machen" sondern ein Feature risikofrei für den Rest entfernen, aber mit dem Risiko, dass der Kunde genau dieses Feature gleich mal wieder zurückhaben möchte.

Ja, sowas lässt sich mit einem Repository gut Regeln - aber es ist trotzdem keine Geschichte die man dann "mal schnell eben" zurückbaut.

[...] aber in der Regel ist es doch so:

Entwickler hat eine gut begründete Position, wie eine Anforderung in Software umzusetzen ist.

Chef hat die Argumente gehört und sich anders entschieden.

Und der Lauf der Dinge hat bewiesen, dass der Entwickler richtig lag und der Chef falsch.

Ja, das ist die Regel - trotzdem wird dem Entwickler dann ständig vorgehalten, dass er ja prinzipiell "immer dagegen" ist. Dass später mal eingestanden wird, dass es tatsächlich war, kommt selten vor - und wenn doch, sind es nur Worthülsen, die 3 Tage später wieder vergessen sind.

Und weil er Chef ist und vermutlich die Macht dazu hat, kann er den Entwickler bei ausreichender Anzahl solcher Vorfälle dann auch mal rauswerfen. Oder zumindest sanktionieren.

Und genau aus dem Grund wird idR. gekuscht und einfach mal an unhaltbaren Terminen gearbeitet - das ist leider üblich.

Software zu entwickeln ist Teamwork.

Die Kluft besteht idR. auch eher zwischen "Management" und "Technik" oder "Design" und "Technik" - wenn die Techniker untereinander schon nicht richtig zusammenarbeiten ist sowieso Hopfen und Malz verloren

Vermutlich sind in solchem Umfeld die Entwickler auch lieber Einzelkämpfer und Herrscher über "ihren" Code, den niemand anderes anfassen darf

Sowas ist ganz besonders Traurig - aber das kommt denke ich im Projektgeschäft weniger vor.

"die können micht nicht rauswerfen, ohne selbst unterzugehen",

Was aber letzlich dazu führt, dass derjenige so schnell wie möglich bei bester Gelegenheit abgesägt wird

Keine dieser Verhaltensweisen würde ich als sonderlich professionell bezeichnen.

Du hast ja keine Ahnung wie weit man das noch unterbieten kann - ich hab noch viel schlimmeres gesehen.