Folge 48: Software Crafting (Pt. 2)

Wir haben es uns vorgenommen, und wir ziehen es durch. Wir greifen wieder mal das große Thema Software Crafting auf.
Steht ja auch in unserer Tagline.

Wir hangeln uns an Benes Kommentaren im Github und an einem Blogpost von Johannes Brodwall entlang.
Heute beleuchten wir eine etwas andere Seite. Warum ist nicht jeder ein Software Crafter?
Sind die Themen nicht (mehr) relevant? Oder hapert es vielleicht noch an anderen Dingen?

Werden die Werte des Software Craftings vielleicht nicht angemessen kommuniziert?
Fehlt es den Software Craftern an Empathie?
Ist das in der Open Source Community anders? Ist der leidige Projektstress schuld?

Was denkt ihr? Schreibt es uns in unserem Github Issue.

Links:

Bier:

Datum der Aufnahme: 13.08.2018

6 Gedanken zu „Folge 48: Software Crafting (Pt. 2)

  1. fonzerelly kommentierte am 22.08.2018:

    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.

  2. holgergp kommentierte am 28.08.2018:

    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.

  3. weltraumpirat kommentierte am 28.08.2018:

    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.
    Ich habe am SoCraTes-Wochenende gefühlt ganze 3 Mal das Wort “Craftsmanship” vernommen.
    3. 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

  4. fonzerelly kommentierte am 04.09.2018:

    @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…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.