Warum Softwareentwickler immer schuld sind

In diesem aufschlussreichen Video tauche ich tief in die komplexe Welt der Softwareentwicklung ein und untersuche, warum Softwareentwickler oft ungerechterweise die Schuld für Probleme tragen, die weit über ihren Kontrollbereich hinausgehen. Durch eine detaillierte Analyse beleuchte ich die systematischen Mängel im Entwicklungsprozess, die zu dieser ungerechtfertigten Schuldzuweisung führen.

Ich beginne mit einem Blick auf die oft übersehenen Aktivitäten im Entwicklungsprozess und wie deren Vernachlässigung zu kritischen Fehlern führen kann, die letztendlich auf die Entwickler zurückfallen. Anschließend diskutiere ich die Problematik der Ausbildung und der Rollenverteilung innerhalb von Projektteams, die dazu führt, dass Erwartungen und Realitäten nicht übereinstimmen.

Ein weiterer Schwerpunkt liegt auf der Qualität der Artefakte, wie Anforderungsdokumente und Architekturpläne. Ich diskutiere, wie die mangelhafte Qualität dieser Elemente den Entwicklungsprozess beeinträchtigt und warum es unfair ist, Entwickler für Mängel verantwortlich zu machen, die ihre Wurzeln in früheren Phasen des Projekts haben.

Durch detaillierte Fallstudien und eine kritische Betrachtung der Industriestandards biete ich Einblicke, die sowohl für Softwareentwickler als auch für Nicht-Techniker von Interesse sind. Mein Ziel ist es, Verständnis und Empathie für die Herausforderungen zu fördern, mit denen Entwickler konfrontiert sind, und Wege aufzuzeigen, wie Teams effektiver zusammenarbeiten können, um diese Herausforderungen zu überwinden.

Begleite mich auf dieser Erkundungsreise, um zu verstehen, warum Softwareentwickler oft zu Unrecht beschuldigt werden, und entdecke, was wir alle tun können, um eine positivere und produktivere Softwareentwicklungsumgebung zu schaffen.

## Kapitel
[00:00] Das Problem
[01:22] Das große Ganze verstehen: Ein Blick auf die Softwareentwicklung von oben
[05:06] Häufiger Fehler #1: Fehlerhafte Softwareentwicklungsprozesse
[07:03] Häufiger Fehler #2: Fehlendes Wissen in Schlüsselpositionen
[09:15] Häufiger Fehler #3: Nicht ausreichende Qualität von Artefakten
[11:03] Die Schuldfrage: Warum Softwareentwickler immer im Kreuzfeuer stehen
[12:22] Ein Stück Wahrheit: Warum wir als Entwickler doch nicht ganz unschuldig sind

▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬

Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)

▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

[gzoechi]

Schuld sind immer die, die gearbeitet haben. Diejenigen die nur reden und sabotieren waren noch nie Schuld. Das ist nicht auf Softwareentwicklung beschränkt

[derRobert-dytw]

Ich arbeite seit 24 Jahren als Softwareentwickler. Aber selbst ich könnte nicht genau sagen, wie man ein Projekt ohne Probleme fertigstellt. Was ich aber sicher weiß, ist, wie man ein Projekt zum Scheitern bringt: Man fängt damit an, jemanden einzustellen, der die Arbeit überwacht und die Leitung verwirrt. Dann mischen sich die Chefs direkt ein, bringen ständig neue Ideen, ändern die Pläne und setzen unrealistische Fristen. Das Ergebnis? SCRUM - unser Arbeitsplan - wird nur noch auf dem Papier existieren, der JIRA-Account verwaist. Am Ende haben wir ein gescheitertes Projekt oder ein Produkt, das niemand mag. Kunden sind unglücklich, Entwickler sind gestresst, manche sind so frustriert, dass sie innerlich kündigen.

Wie macht man es besser? Nicht alles zu ernst nehmen, als Entwickler auch mal Nein sagen und aufpassen, nicht alles selbst machen zu müssen.

[sVIIDragonfly]

Wie immer hochwertiger Content - ein Genuss zu konsumieren, danke für deine Zeit und das Video!

[sperl]

Manchmal hat es auch Vorteile, in einer kleinen Firma zu arbeiten, in der man alleine für das Projekt verantwortlich ist und man im Zweifel noch einmal beim Kunden nachfragen kann, was wirklich gewünscht wird.

[RickTheClipper]

Ich arbeite nie ohne Pflichtenheft, und habe gelernt das Schätzungen bestenfalls Wunschlisten sind.
Agile scheitert sehr oft, und wer Visionen hat gehört in Fachärztliche Behandlung

[B.Büch]

Immer wenn ich diese Videos sehe, freue ich mich, dass es nicht nur mir so geht. Und dass es doch an meinem Chef und nicht nur an mir lag, dass ich in der Reha gelandet bin.

[AdriaticSun]

David, vielen Dank für das Video. 
Da ich ähnliche Erfahrungen hatte, kann ich nur bestätigen: Projekte scheitern in vielen Fällen, weil die Vorbereitung für die Entwicklung nicht gut genug ist. Zwischen Produkt Vision und DoR User Stories ist ein sehr langer Weg. Diese Rollen sind sehr oft nur von einer Person besetzt (Stichwort: Bottleneck). Entwicklerteam hat 2 bis 4 Entwickler, 1-2 QA. Auch wenn 2 oder 3 Entwickler Junior sind (bzw. 1-2 Mid / Senior Developers), wir haben noch immer Möglichkeiten zur Korrektur, die nicht so viel Zeit kostet. 
Wenn ein PM/PO seine Artefakte (User Stories, Features, Epics) in schlechter Qualität liefert, dann übernimmt das Team die Aufgaben von PO (schon mehrmals gesehen). Am Ende haben wir unzählige Probleme und Lieferverspätungen.

[MrMocren]

Als angehender Software-Entwickler (bereits FAE Ausbildung hinter mir und jetzt im dualen Studium) bin ich immer super Dankbar für dein Videos!
Du sensibilisierst für Themen, über die man sich sonst nie Gedanken machen würde. Ich habe das Gefühl, dass den Mitarbeitern, auch Software-Entwicklern, oft der Blick über "das große Ganze" fehlt und die Ursache für die Probleme noch lange vor der ersten Zeile Code liegt. Und ich bin ein Freund davon das Problem "an der Wurzel zu packen", anstatt die darausfolgenden Symptome zu behandeln. Oft ist man zu sehr im Arbeitsalltag gefangen, sodass man mit den Gedanken bei einem Task ist. Ist das abgearbeitet, kommt der nächste. Dabei hilft es (mir zumindest) ab und zu mal einen Schritt von allem zurück zu gehen und sich nochmal ein Überblick zu verschaffen. Mal kritisch zu hinterfragen, ob das der richtige Weg ist. Die richtige Architektur etc.
Aber ja. Es steckt immer der wirtschaftliche Gedanke dahinter. Und wie du schon erwähnt hast, wird leider an den falschen Enden gespart.
Aber wäre Software nicht viel zu teuer, wenn man all diese benötigten Stellen besetzen würde? Würden das die Kunden noch kaufen?
Im Mittelstand zum Beispiel. Ich bekomme oft mit, dass diese mittleren bis "großen" Kunden einfach nicht bereit sind solche Summen für eine "einfache" Software auf den Tisch zu legen.

[askat]

Ein sehr gutes Video, dem ich vollständig zustimme!

Was mir aber bei vielen Kollegen in der Softwareentwicklung aufgefallen ist, dass nie hinterfragt wird, ob eine Entscheidung so richtig ist.
Ich habe vor 5-6 Jahren als Junior in einer großen Firma mit wenig IT Personal angefangen. Da mir immer wichtig ist zu verstehen warum ich an etwas arbeite, wurden die Termine mit dem Product Owner manchmal etwas hitzig, denn diese vehementen Rückfragen waren neu. Aber ich hatte das Gefühl (und auch Feedback) dass sich das Team nach einer Weile daran gewöhnt hat und es auch gut fand, dass diese Fragen gestellt wurden. Manche Tasks wurden dadurch auch zurückgestellt oder umgeschrieben, weil sie nicht ganz passten.
Man kann damit in der falschen Firma auf die Nase fliegen, aber für mich ist es extrem wichtig das Ziel zu verstehen. Zumindest aus meiner Erfahrung heraus, können nur die Entwickler (wenn man keinen guten und übers gesamte Projekt eingebunden Architekt hat) teilweise Projekt-/Programmabschnitte gedanklich schon so miteinander verknüpfen, dass eigentlich identische Aufgaben mit unterschiedlichen Datensätzen als solche erkannt werden.

[bastianwestphal]

Tolle Erklärung. Danke!
Und die Waschmaschiene ist auch oft Schuld an vielen Klamotten-Bugs, wie z.B. fehlende Kapuzenbänder. 🫢

[andreasschurz]

Der UAT wurde vergessen zu erwähnen. Beispiel aus meinem Umfeld: die Entwicklung hat länger gedauert als geplant und mit Beginn der Abnahme knallen immer wieder neue Tickets hoch. Das geht so weit, bis man feststellt, dass die Architektur falsch gewählt wurde. Und das Projekt verzögert sich und verzögert sich. Jeder Bug, der gefixt wurde deckt neue Nachfolge-Bugs auf, die weitere bisher nicht gesehene Bugs nach sich ziehen. Hölle

[AScribblingTurtle]

7:00 : Das hab ich grad sowas von gefühlt. Autsch.

Bei uns in der Firma (5 Programmiere + 1 Designer + 1 Sekretär + 2 Chefs) sind Produkt Owner, Product Manager und Projekt Manager dieselbe Person.
Die Anforderungen ändern sich ständig, je nach dem was besagte person grad unseren Kunden verkaufen möchte.
Interesse an der technischen Umsetzung hat besagte Person auch nicht, (Von ein paar verkaufbaren Buzzwords mal abgesehen).
"Er ist ja keine Software-Entwickler sonder sieht nur die Sicht der Kunden" ~ um Ihn mal zu zitieren.

Sobald dann doch mal was fertig wird, darf man sich hinterher anhören, dass alles viel zu lange gedauert hat und das man ja weniger Umsetzungszeit versprochen hätte.
(Auch wenn alle sinnigen Umsetzungszeiten von der Chef-Etage immer mit "Das ist zu Teuer, das bekomme ich nicht verkauft" abgeschmettert werden und man gar keine andere Wahl hatte als irgendwas unsinniges / unmögliches anzugeben, weil die einen ohne Antwort nicht aus dem Büro lassen)

[gerhardq]

Die wichtigste Fähigkeit eines Software-Entwicklers wurde zum Schluß angesprochen, nämlich die Fähigkeit "Nein" zu sagen. Ich hatte vor Jahren mal einem Kunden, bei dem wir schon mehr 1 Jahr entwickelt hatten, gesagt, daß wir noch einmal von vorne anfangen müssen. Mein Kunde bekam fast von einen Schlaganfall, ließ sich aber dann doch darauf ein. Und im Nachhinein war es die beste Entscheidung. Wir haben uns hingesetzt und die ganzen Artefakte neu aufgesetzt. Der Vorteil war, daß wir alle uns schon intensiv mit der Entwicklung beschäftigt hatten. Danach waren dann die Entwickler in der Lage, zu entwickeln! Nach ca. 8 Wochen stand ein lauffähiges Produkt und nach 12 Wochen ging es vollständig in die Produktion. Das Produkt war ein Finanzsystem für eine Berufsgenossenschaft und war danach noch 21 Jahre fast unverändert in Gebrauch!
Das hatte mir damals gezeigt, wie wichtig es ist, auch schwierige Entscheidungen zu treffen und notfalls durchzusetzen.

[cowboyjo_]

Das finde ich ja interessant, wie viel ich aus dem Video auf meinen eigenen Arbeitsalltag ableiten kann.
Ich bin selbst kein Softwareentwickler im klassischen Sinn, ich bin SPS Programmierer. Zu meinem Beruf gehören also nur ein paar Teile der klassischen Softwareentwicklung. Die genannten Rollen kenne ich so direkt nicht, jedenfalls nicht unter den Namen. Aber viele Tätigkeiten (oder sogar alle) hinter den Rollen gehören zu meine Projekten auch dazu. Meine Rolle würde ich dem Diagramm hauptsächlich als Architekt und Entwickler beschreiben, bei uns sind diese Rollen praktisch nie getrennt, da dass Entwicklerteam meist zu klein ist (viele Projekte programmiere ich alleine oder zusammen mit einem Entwickler des Kunden). Product Owner mache ich oft auch noch mit, und nicht selten auch den Product Manager.
Die Probleme die dabei so entstehen sind aber oftmals genau dass, was du hier angeführt hast:
- Ich bekomme eine vage Beschreibungen, was das Ergebnis sein soll und der Fertigstellungstermin ist gestern.
- Dann stelle ich konkrete Fragen, was man sich denn genau bei Diesem und Jenen vorstellt (ich mache also selbst schon Produktvision, da der Stakeholder, der gleichzeitig das Projekt leitet, das nicht kann) und bekomme ein "keine Ahnung" als Antwort.
- also entwickle ich nach bestem wissen und Gewissen und den vorhandenen Informationen ein Softwaregerüst und ein paar Grundfunktionen und zeige sie danach dem Kunden um zu erfahren, ob er sich das ganze so vorgestellt hat
- so bekomme ich dann nach und nach während des Entwicklungsprozesses die Informationen, die ich brauche.
-> wenn ich ein gutes Näschen habe und die Kundenwünsche vorhersehen kann, dann bekomme ich eine flexible Software hin, die sich leicht an ändernde Anforderungen des Kunden anpassen lässt, ohne zu komplex zu werden
-> gelingt mir das nicht, muss unter hohem Zeiteinsatz, Änderungen durchführen und ganze Teile vom Code verwerfen

Eine vernüftige Planungsphase, die jedes Projekt eigentlich benötigt, wird meistens als unnötig empfunden. "Für dieses Projekt ist das zu aufwendig, dass kann man einfach direkt umsetzen"

Bei meinem jetzigen Projekt habe ich dann Stopp! gesagt und habe eine Komponentenanalyse der Hardware und einen Prozessablaufplan erstellt, aus dem ich dann einen 6 seitigen Fragenkatalog ableiten konnte, den der Kunde ersteinmal abarbeiten muss!, bevor ich über das Schreiben der nächsten Codezeilen nachdenke. In diesem Projekt hängt einfach zu viel schief, als dass ich die ganzen Fehler und Versäumnisse gerade bügeln könnte.

Ich würde mich echt freuen, wenn im Maschinenbau auch langsam mal die Einsicht einziehen würde, dass eine vernünftige Projektplanung essentiell wichtig für eine planbare Umsetzung ist.

[ManuelBTC]

Deswegen hat es sich (wo möglich) etabliert, möglichst kurze Iterationszyklen zu haben. Wenn man alle 2 Wochen oder gar kontinuierlich einen funktionierenden Stand abliefern kann, dann fällt den Stakeholdern überhaupt erst auf, was sie selbst nicht wussten, was sie nicht kommuniziert haben, was falsch verstanden wurde, welche Anforderungen nicht bedacht wurden, oder einfach als Selbstverständlichkeit angenommen wurden usw. Es vermeidet auch das Phänomen des Wunschkonzerts, da jedem klar ist, dass man in den nächsten zwei Wochen nicht komplett fertig werden kann, wodurch eine Priorisierung stattfindet. Davon abgesehen ist der tatsächlich nötige Entwicklungsaufwand bei größeren Projekten äußert schlecht abschätzbar, was man aber durch den kontinuierlichen Prozess umgeht, da man einfach immer etwas abliefert und der Kunde zahlt nur so lange, bis er zufrieden ist (oder ihm das Geld ausgeht...).

[markusfeljofsen]

Softwareentwickler sind immer schuld, weil sie die wahren Arbeitenden und Wissenden sind. Wer wird in Rufbereitschaft angerufen, wenn Fehler in der Produktion auftauchen? Nicht die Projektleiter, nicht die Abteilungsleiter, nicht die Bereichsleiter. Aber all diese Leute wollen alles immer gleichzeitig und möglichst schnell. Den Betrieb der Systeme und die (Fehl-)Entscheidungen verantworten sie nicht. Die Software Entwickler sollten viel mehr Entscheidungskompetenz haben.

[JonDoe-uxgm]

Tolles Video! Welche beiden Stakeholdergruppen wurden bei dem Kunden im Video bei Minute 9 eigentlich noch vergessen?

[stox]

Wie oft ich schon als einfacher Softwareentwickler für Fehler durch schlechtes Management verantwortlich gemacht worden bin ist echt traurig.

[petermuller]

Ich sehe 3 Aspekte:
- Ob eine Software "läuft", ist objektiv festzustellen. Ob eine Architekturskizze, Produktvision, Projektplan, ... "laufen", ist immer sehr weich und diskutabel.
- Lustigerweise sollen die Entwickler dann die Arbeit der vorgelagerten Prozesse beurteilen - wofür sie eigentlich nicht qualifiziert sind und wofür sie dann wiederum Widerspruch ernten (weil eben "Meinung" und nicht "objektiv" UND weil sie als "Amateure" nicht die geeigneten Instrumente haben). Am Ende werden sie dann als "Bremser" (sprich: Schuldige) ausgemacht.
- Entwickler sind "das letzte Glied der Kette" = da, wo als erstes die Ursachen für Probleme gesucht werden (besonders, wenn der Eindruck entsteht, dass es bei den vorgelagerten Prozessen keine Probleme gab).

Letztlich hilft nur eine dicke Haut und klare Kommunikation: Das habt IHR im Vorfeld verbockt und nun soll ich es ausbügeln. Wird nicht funktionieren und immer wieder schieflaufen, solange ihr euch weigert, in EUREN Prozessen besser zu werden.

Allerdings bringt ein iteratives Vorgehen (immer wieder gemeinsam zusammensetzen und nachsteuern) deutliche Verbesserungen. Es wird nicht unbedingt früher fertig, aber Zeit, Umfang, Qualität "ruckeln" sich über die Iterationen zurecht.

[patrickj.]

Das hört sich ja einfach an 😅
Aus dem Maschinenbau kann ich nur sagen, dass wir auch in die Richtung Software entwickeln, aber da kommt noch hinzu
- physikalische Prozess verstehen (NC, Fluide, Chemie, etc.)
- mechanische/elektrische Konstruktion
- Sicherheitsmaßnahmen/-normen (jedes Land unterschiedlich)
- andere Normen
- etc.

Erwartungshaltung ist natürlich immer, dass man in den hinzugekommenen Bereichen auch Ahnung/Durchblick hat und "Nein" sagen kann.

Und dann gibt es ganz viele Leute im Maschinenbau, die nicht verstehen, dass es eine Architektur braucht. Das sind die besten 🤣