… oder, wer hat welche Aufgabe. Was passiert, wenn Aufgaben nicht optimal verteilt sind oder nicht bzw. nur halbherzig wahrgenommen werden?
Mit meinem Beitrag Perfektionismus ist nicht das Problem habe ich auf einen Artikel von entwickler.de geantwortet, dessen Grundinhalt ich zwar teile, mir jedoch Ergänzungen gefehlt haben. Auf Twitter gab es dann zahlreiche Kommentare, wie z.B.
von "Weeks of coding can save hours of planing" bis "Formatierungs-Neurotiker, OOP-Puristen, Astronauten-Architekten und weitere Stereotypen https://t.co/sj5Og56tdY
— MikeBild (@mikebild) September 30, 2016
Der Tweet zeigt den Beginn, der darauf hinwies, dass es die genannten Stereotypen in der Softwareentwicklung gibt – was ja auch so ist. In weiterer Folge änderte sich aber das Thema: “Kehre vor deiner eigenen Türe”. D.h. zuerst auf sich selbst schauen und Veränderungen zuerst an sich vornehmen zu müssen, quasi als gutes Beispiel vorangehen – so nach dem Motto, dann würde schon alles gut werden.
Ein guter Einwand, der jedoch am eigentlichen Sinn meines Artikels vorbei ging. Ich wollte kein Leid mitteilen oder jemanden anprangern, sondern zusätzliche Aspekte aufbringen, die in solche Überlegungen mit einfließen sollten. Denn sonst entsteht ein Schiefstand, der ohnehin gerne dokumentiert wird: Die Generalschuld des Softwareentwicklers.
Jeder hat seine Verantwortung
Die Aufgabe des Softwareentwicklers ist in der Regel, eine Umsetzungsmöglichkeit für eine Anforderung zu finden und diese auch nach bestmöglichem Wissen und Können umzusetzen. Natürlich fällt in seine Aufgabe auch, dass Wege zur Vereinfachung oder einer besseren Variante (als die vorgeschlagene), vorgeschlagen und diskutiert werden.
Die technische Umsetzung ist natürlich alleinig seine Aufgabe (unter Berücksichtigung etwaiger gegebener Umstände/Einschränkungen). Fertig.
Die Anforderungen zu erheben und zu erfassen liegt aber nicht in der Verantwortung des Entwicklers (außer es handelt sich um eine Ich-AG oder ein ähnlich kleines Unternehmen, da geht es schlicht nicht anders). Wer hierfür zuständig ist, hat ebenfalls Sorgfalt an den Tag zu legen und die Anforderung nach bestem Wissen und Gewissen zu erfassen. Er kann sich nicht so einfach aus seiner Verantwortung stehlen. Ein Punkt “Datenaustausch SAP” ohne weitere Informationen genügt den Ansprüchen nicht. Die Entwickler sagen in der Regel ja schnell, was sie brauchen, um ihren Job machen zu können. Das sollte man beherzigen, denn dies hilft wirklich sehr viel Zeit/Kosten sparen.
Kehre vor der eigenen Türe
Nun habe ich vor mittlerweile über drei Jahren bereits über dieses Thema gebloggt: Das Geheimnis der Kommunikation. Darin ging es um das Thema Seblstreferenzialität. Besonders nachfolgender Absatz ist hierbei interessant:
Möchte ich als Person einen Vorteil aufzeigen, muss ich die Änderung bei mir selbst anwenden, zeigen dass es funktioniert und kann somit angrenzenden Systemen ein Angebot unterbreiten, dies ebenfalls einzusetzen. Diese Systeme entscheiden selbst ob sie das tun werden oder nicht. Wird der Vorteil erkannt und für gut befunden stehen die Chancen dazu natürlich gut. Weit größere Chancen sind einzuräumen, wenn dies ohne ein dargelegtes “Angebot” übernommen wird.
Eben das hat auch Mike angesprochen und das ist auch in Ordnung so.
@norberteder sorry, zuerst arbeitet man an sich selbst. Nicht an anderen. Dann an der Umgebung. Ich kenne eben auch einige der …
— MikeBild (@mikebild) 30. September 2016
Das darf aber nicht darin enden, dass der Umgebung nicht gesagt werden darf, dass es ein erhebliches Verbesserungspotential gibt. Nein, vielleicht ist sogar der Input ins eigene System so schlecht, dass daraus kein (sinnvoller) Output erzeugt werden kann. In diesem Fall ist es nicht ausreichend, zuerst an mir selbst zu arbeiten.
Die Retrospektive ist wichtig, um das eigene Tun zu hinterfragen. In Scrum ist es beispielsweise eingebettet und soll dem Team als Forum dienen, Schiefstände zu besprechen und Maßnahmen zu beschließen. Diese Maßnahmen werden versucht umzusetzen, was Verbesserung bringt. Es handelt sich um ein wichtiges und wundervolles Werkzeug. Es sollte über diese Methode hinaus eingesetzt werden. Nein, MUSS! Manche Schiefstände können jedoch nicht von einem selbst, oder dem Team behoben werden, es muss sich das Umfeld ändern – und zwar schnell, denn Zeit ist hier wirklich Geld (gerade wenn es um falsch oder ungenügend erfassten Anforderungen geht).
Fazit
Jeder hat seinen Beitrag zum Gesamtprodukt zu leisten und jeder hat seinen Part mit der notwendigen Sorgfalt und Professionalität zu erledigen. Als Entwickler benötige ich eine aussagekräftige Spezifikation mit allen relevanten Informationen. Was mir nicht weiterhilft, sind viel Text, aber kein Inhalt. Genau das sollte man aber auch bei der Implementierung berücksichtigen. Es geht darum, eine Anforderung zu erfüllen, und zwar so, dass weitere, neue Anforderungen möglichst ohne Beinbruch hinzugefügt werden können. Es geht in keinster Weise darum, sich irgendein mega-geiles Super-Konstrukt zu schaffen, das man dann auf einer Konferenz, einem Entwicklertreffen oder auch nur einem internen Dev-Tête-à-Tête als Schwanzvergleich hinknallt. Wer das nicht gerafft hat, ist falsch in der Welt der Softwareentwicklung.
“Kehre vor deiner eigenen Tür” ist doch Kindergartenlogik. Natürlich darf man anderen Dinge raten, wenn man sich selbst noch nicht optimiert hat. Der Ratschlag ist trotzdem wertvoll (angenommen er ist richtig).
Genauso darf man Kritik üben *ohne* einen besseren Vorschlag zu machen. Die Kritik an sich ist wertvoll.
Leider sind Programmierer oft von so geringer Sozialkompetenz, dass entweder der Geber oder der Nehmer es versauen. Daran ist niemand schuld, es ist einfach eine typische Eigenschaft dieses Menschenschlags.
Hey Norbert,
fehlende oder unzureichende Anforderungsanalyse und Spezifikationen, keine oder unzureichende Retrospektive, etc. Missstände im Entwicklungsprozess die, wie du treffend schreibst, Zeit und damit Geld kosten. Deine Einwände sind völlig in Ordnung für mich. Ich kenne sie ebenfalls aus eigener Erfahrung. Die selbstkritischen Meinungen vom Dennis Wilson teile ich zu einem großen Teil. Ja, vorerst “vor der eigenen Türe kehren”. Ich meinte, wir haben es doch in der Hand. Du kannst und musst Anforderungen die deine Arbeit möglich machen einfordern. Doch dabei bitte nicht dümmer oder korrekter anstellen als man ist. Anforderungen und Spezifikation auf rein abstrakter Ebene zu erarbeiten ist sehr schwierig. Etwas besser geht es mit Rückkopplung – im Team. Heißt z.B. ich schreibe unvollständige Anforderungen, du implementierst nicht perfekte Programmteile. Ich glaube es gibt keine perfekten Anforderungen (“alle relevanten Informationen”) und ich glaube es gibt keine perfekt entwickelten Anwendungen. Und genau das ist der Punkt. Diese zu fordern ergibt aus meiner Perspektive eine nicht selten erlebte “Patt” Situation. Die von dir angesprochene “Schuldfrage” zu klären kann dabei eine Rolle spielen. Ist für mich jedoch der schwierigere Kommunikationsansatz. Ich halte das so – Fragen, Fragen, Fragen – bis es für eine erste Implementierung irgendwie passt, Präsentation, neue Anforderungen, Refaktor bzw. neue Implementierung. Iteratives Vorgehen – klaro nichts Neues. Passe dich einer beschleunigten nicht perfekten Geschäftsumgebung unter Berücksichtigung deiner persönlichen Qualitätsanforderungen an, statt “perfektere” Anforderungen zu fordern. Das kann doch, so verstehe ich Dennis Beitrag, auch ein Ansatz sein, oder?
PS: Natürlich zählt letztlich das produzierte Ergebnis eines Entwicklungsprozesses. Da sind alle gefragt – ja dabei sind wir uns ganz sicher einig. Etwas mehr Selbstkritik, “perfektionierte Softwareentwicklung” mit Pattern hier und StyleCop da, wird doch IMHO möglich sein. Womöglich auch ohne “Schau mal da, der/die sind Schuld” in einem Artikel zu nennen.
Mir geht es nicht darum, selbst eine Schuldzuweisung vorzunehmen. Da es aber die Software ist, die nicht (richtig) funktioniert, sind es gerne mal “die Entwickler”, die als Problemquelle ausgemacht werden.
Für genau diesen Fall möchte ich betonen, dass die Ursache oft schon viel früher begraben liegt, nämlich in der (fehlenden) Spezifikation/Aufbereitung/Vorarbeit.
Natürlich kann auch hier der Entwickler in die Pflicht genommen werden, denn er kann die Informationen einfordern. Nein, er muss es sogar.
Problematisch wird es, wenn notwendige Schritte durch zeitlichen Druck entfallen. Spezifikationen werden mündlich “definiert” usw. Eine Nachvollziehbarkeit (auch warum Entscheidungen so getroffen wurden) ist dann nicht mehr gegeben. Das ist zwar im Moment kein Problem, im Laufe der Zeit und höherer Komplexität kann sich das schwer nachteilig entwickeln.
Die Ursachen können vielseitig sein:
– Ungenaue Spezifikationen
– Fehlende Informationen
– Spezifikationen basierend auf Annahmen
– Zu späte Kommunikation der notwendigen Anforderungen (Zeitdruck)
Ergänzend dazu gibt es dann noch Auswüchse in der Entwicklung (wie sie bereits angesprochen wurden).
Keine leichte Sache. Wichtig ist – und das wollte ich eigentlich betonen – dass wirklich jeder seinen Teil dazu beitragen muss, damit das Ergebnis stimmt. Es darf sich niemand aus der Verantwortung nehmen, genau das fällt mir aber in der Praxis gerne mal auf.
Hey Norbert,
passt alles. Ich kann das nachvollziehen. Vielen Dank für den Austausch.
PS: https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8