Folge 48: Software Crafting Revisited

[hameister]

Zum Thema Empathie lernen findet ihr hier vielleicht ein paar Anregungen: https://youtu.be/SIl5rTOZUOg?t=53m10s Wobei der gesamte Vortrag sehr sehenswert ist.

[fonzerelly]

Liebes autoweired fm team,

Danke für das aufgreifen meines resignierenden Kommentars. Ich konnte mich in euren ausführungen sehr gut wieder finden. Ich habe ganz sicher auch das Problem meine Positionen gut verkaufen zu können. Und durch meine harte Haltung habe ich mir keine Freunde gemacht.

Aber ihr habt in der Folge wieder viel Wert auf den menschlichen Aspekt gelegt. Software Crafting allerdings scheint mir aber doch Anspruch auf gewisse absolute Wahrheiten zu legen:

1. Wir müssen code von zeit zu zeit refactoren
2. Jeder sollte sich in kürzester Zeit in eine Codebasis einarbeiten können
3. Um beides sicher zu stellen brauchen wir ein Mindestmaß an Unittests die sich schnell ausführen lassen
4. Am leichtesten erreicht man dieses Mindestmaß an Tests wenn man TDD anwendet
5. Nachträglich läßt sich das oft nur schwer bewerkstelligen

Seht ihr das auch so? Falls nein würde mich interessieren welche alternative Wahrheiten es gibt und vielleicht lässt sich durch einen Vergleich das optimale Modell ermitteln.

Sind diese Ansichten aber nicht angreifbar, dann müßtet ihr doch nachvollziehen können das man alles dafür tun muß um diesen Zustand zu erreichen, völlig egal in welcher Technologie, Team, oder Business man ist. Wenn das Team diese Überzeugung nicht hat, dann muss man als SoftwareCrafter doch zwangsläufig Angst haben, dass die Kollegen Fehlermeldungen vom ContiniousBuildServer nicht ernst nehmen und bewust oder unbewust alle notwendigen Qualitätsmaßnahmen kaputt machen. Ich hab mal als Integrator gearbeitet. Damals waren solche builds noch hip und neu. Viele haben noch bezweifelt, dass ein BuildServer was bringt. Daher wurden die aussagen dieses systems nie ernst genommen, sondern sich lieber darum gestritten wer an dem buildbreak schuld hat. Gleiches befürchte ich eben auch, wenn man die oben erwähnten Wahrheiten missachtet. Wenn Zweifel an der Testsuit bestehen, dann nimmt man Fehlermeldungen nicht ernst und ignoriert sie, bis man vor lauter spaghetti code gar nix mehr maintainen kann.

Bin ich mit dieser Vorstellung tatsächlich so plem plem wie die meisten Kollegen ob meines schlechten Verkaufstalents mich sehen, oder haben wir SoftwareCrafter recht und wir sollten uns über bessere Verkaufsargumente austauschen, was sicher auch ein gutes Thema für eine neue Sendung wäre.

[holgergp]

Moin Fonzerelly,

Danke für dein Feedback! Ich habe dazu mal ein paar Gedanken gesammelt:

Aus meiner Sicht hat die Thematik mehrere Aspekte und ist sehr vielschichtig. Die menschliche Seite ist eine davon, wenn du mich fragst die wichtigste. Aber das ist etwas was von uns Techies notorisch unterschätzt wird.

Die technische Seite ist natürlich auch sehr wichtig. Das ist aber etwas was wir gut können, und ist leider auch etwas über das wir uns unendlich streiten können.

Aber zu deinen Punkten:

Refactoring: Ich glaube in der Tat nicht, dass es Refactoring etwas inhärentes ist. Also etwas was in jeder Software immer gemacht werden muss. Wenn es eine Software ist, die hinreichend lange lebt, dann ist die Wahrscheinlichkeit dafür aber recht groß.

Einarbeitung: Hmmm kommt drauf an, mit wem du redest. Für Emil Entwickler, der seit 20 Jahren auf seiner Software sitzt, ist es wahrscheinlich nicht sinnvoll, dass jemand fix in der Software arbeiten kann. Das sichert seinen Job. Ein Gespräch mit ihm über SOLID, wäre wahrscheinlich sehr einseitig. Ich habe leider in vielen Kontexten den Hang dazu erlebt, dass sich Entwickler ihre Silos bauen. Das Problem ist wahrscheinlich nicht auf der Ebene von Softwareentwicklern lösbar.

Unit Tests: Ja klar. Ein okaye Testabdeckung hilft beim Refactoren, und kann auch beim Verstehen der Software gute Dienste leisten. Allerdings helfen schlecht geschnittene Tests, möglicherweise selber 100 Zeilen lang, nicht unbedingt bei der Einarbeitung

TDD: Ich fand den Punkt aus dem Blog Artikel bzgl. Compassionate Code hierzu hilfreich. TDD ist ein Mittel was für einige funktioniert. Ich kenne Entwickler, die ähnlich gut im Nachgang Tests schreiben.

Die von dir beschriebenen Punkte sind ein guter Weg, um gut wartbare Software zu erreichen. Allerdings nicht in jedem Kontext. Emil Entwickler wirst du mit TDD wahrscheinlich arg verstören. Da hilft wahrscheinlich, nur penetrantes Social Engineering. :)

Letztendlich können die Beweggründe weswegen wir uns mit Software befassen auch unterschiedliche sein. Für Crafter mag das Thema Software fast schon den Charakter eines Hobbies haben, für viele, vielleicht auch für Emil Entwickler, ist es “nur” Arbeit. Die Motivation es zu verbessern fehlt womöglich.

(Intrinsische) Motivation in die Verbesserung der Softwareerstellung ist etwas was in einigen Kontexten klappt (vielleicht besonders in Startups) in einigen aber quasi schon etwas negatives ist (vielleicht im Konzern von nebenan). Diese Motivation in die Entwickler zu bekommen, ist für mich ein hartes menschliches Problem, was ich für mich leider aber auch noch nicht wirklich beantworten kann.

[weltraumpirat]

Mahlzeit, Kollegen,

hier ein paar kurze Anmerkungen zur Folge 48:

1. Der Veröffentlichung des Buchs https://www.amazon.de/Java-Comparison-Become-Craftsman-Examples/dp/1680502875/ref=asap_bc?ie=UTF8 folgte keine “Feminismus-Debatte”, sondern eine über inklusive Sprache: Eine Frau besaß die Frechheit, dem Autor zu tweeten, dass er sich bei dem Titel nicht wundern müsse, dass sie das Buch nicht kaufen mag.
2. Simon Harrer (der Autor) war Gast der SoCraTes (inzwischen “International Conference for Software Craft und Testing”) und hat sich sichtlich wohl gefühlt.
3. Ich habe am SoCraTes-Wochenende gefühlt ganze 3 Mal das Wort “Craftsmanship” vernommen. Vielleicht wird nicht alles so heiß gegessen, wie das Bier gebraut wird.

Das hier fand ich dann aber doch Grund genug für die erste (1-Minuten-) Keynote der SoCraTes: https://twitter.com/unclebobmartin/status/1029350638709338112 Meine Antwort: https://twitter.com/w3ltraumpirat/status/1029485283937533953

[ReneCode]

Zitat von Holger: ".... Diese Motivation in die Entwickler zu bekommen, ist für mich ein hartes menschliches Problem, was ich für mich leider aber auch noch nicht wirklich beantworten kann."

Volle Zustimmung !. Wie weit kann da ein Scrum-Master helfen ? Wie sähe das dann aus ?

[fonzerelly]

@ReneCode Peitsche raus :)

Aber im ernst: Auch wenn das von manchen als "undemokratisch" aufgefasst wird, ich hielte es für Gut wenn man versucht die menschliche Motivation mit nudging anzukurbeln. Ihr kennt sicherlich die Fliege im Pissoir von Herren-Toiletten. Das ist letztlich ein kleiner Ansporn für uns Männer "richtig zu ziehlen" um die Fliege zu treffen. Dahinter verbirgt sich der Wunsch des Toilettenbetreibers, dass "Mann" keine allzugroße Sauerei dort verursacht.

So ähnlich müsste man das Problem beim Testing auch angehen. Mit Gamification arbeiten. Vielleicht z.B. auf dem CI-Build mitzählen wer im letzten Monat am wenigsten Findings im MutationBasedTesting geschafft hat oder so. Ein Scrum-Master könnte a) veranlassen dass sowas eingerichtet wird b) Geld dafür auftreiben, dass der Mitarbeiter des Monats mit einer Tüte Gummibärchen belohnt wird.

Ich hab aber berreits Probleme damit, meinen direkten Vorgesetzten klar zu machen, dass TDD support (vielleicht auch mit nudging mitteln) eine gute Sache wäre...