Brett vs. Bytes – die Betrachtung von Softwareentwicklung als Handwerkskunst erschließt sich vielleicht nicht auf den ersten Blick. Sie ist vor allem so zu verstehen, dass sie die Entwicklungstätigkeit abgrenzen möchte von einem allzu planvollen, ingenieurmäßigen Vorgehen oder gar dem Verständnis der Entwicklung als Fabrikarbeit. Im Folgenden möchte ich aus meiner Perspektive erzählen, warum der Vergleich dennoch dazu taugt, bessere Entwicklung zu fördern.

Entstehung des Begriffs "Software Crafting"

Die Handwerks-Metapher wurde schon in den 1970er Jahren von Fred Brooks in seinem Buch The Mythical Man Month benutzt, auch wenn er in diesem Fall damit noch einen leicht anderen Blickwinkel beschreibt. Den echten Grundstein für die Software-Crafting-Bewegung legten 1999 Andy Hunt und David Thomas mit ihrem Buch The Pragmatic Programmer. Sie beschrieben Best Practices und Anti-Pattern, beschränkten sich aber nicht nur auf technische Beschreibungen, sondern nahmen auch das Mindset mit hinein.

Im Anschluss gingen jedoch weitere neun Jahre ins Land, bevor das Ganze richtig in Fahrt kam. Damals sagte Robert C. Martin auf einer Konferenz, es solle seiner Meinung nach einen fünften Wert im Agilen Manifest geben: "Craftsmanship over Crap" [1]. Später formulierte er diese Aussage zum etwas familientauglicheren Leitsatz "Craftsmanship over Execution" um. Es war ein Learning aus einigen agilen Projekten, die auf Grund schlechter Qualität der Software gescheitert waren. Dies gab den Anstoß zu einer Formulierung von Werten, und ein paar Monate danach wurde schließlich das Software-Crafting-Manifest veröffentlicht.

2011 bildeten sich erste Usergroups in Deutschland, und in Anlehnung an die Handwerkskammer wurde die Softwerkskammer gegründet. Diese sollte als Dachorganisation für die Vernetzung einzelner Ortsgruppen rund um das Software Crafting dienen. Die gesamte Entwicklung wurde 2014 von Sandro Mancuso im Buch The Software Craftsman spannend zusammengefasst – Leseempfehlung!

Das Manifest

Ich interpretiere das Manifest als Kompass für einen Weg ohne definiertes Ziel. Vielmehr wird eine Reise auf der Suche nach Exzellenz dargestellt, ohne dass diese endgültig  erreichbar und der Prozess somit abgeschlossen wäre. Darüber hinaus definiert das Manifest mit vier Leitsätzen die Kernwerte des Software Crafting.

• Im ersten Satz geht es darum, dass eine lediglich funktionierende Software nicht ausreicht. Vielmehr soll sie gut gefertigt sein und gleichzeitig verständlich genug, um sie beispielsweise leicht erweitern oder Fehler einfacher finden zu können.
• Der zweite Satz ruft dazu auf, nicht nur auf Veränderungen zu reagieren, sondern durch die eigene Arbeit ständig einen Mehrwert zu schaffen. Damit sind nicht nur Werte in Form neuer Features oder behobener Fehler gemeint, sondern auch die kontinuierliche Verbesserung der Codebasis als Fundament der Software. Das schließt eine funktionierende Infrastruktur und automatisierte Tests mit ein.
• Nicht nur Individuen und Interaktionen, sondern eine echte Gemeinschaft von Profis fordert der dritte Leitsatz ein. Dazu gehört der Austausch mit Kolleginnen und Kollegen innerhalb des Unternehmens genauso wie der mit Menschen von außerhalb, also beispielsweise auf Konferenzen oder in Usergroups. Nur im Diskurs kann der Begriff von “gut gefertigter Software” mit Leben und Bedeutung gefüllt werden.
• Im vierten Satz wird die Zusammenarbeit mit Kunden schließlich um den Begriff “produktive Partnerschaft” erweitert. Es geht also nicht bloß um die Umsetzung der Kundenwünsche – Ziel ist, in einen echten Dialog zu kommen, um das dahinterliegende Bedürfnis zu verstehen und ggf. geeignete Alternativen oder Änderungen vorschlagen zu können.

Wer das Agile Manifest und das Software-Crafting-Manifest vergleicht, wird hier Gemeinsamkeiten in Form und Inhalt feststellen. Dabei stehen Software Crafting und Agile nicht in Konkurrenz, eher im Gegenteil: Die gemeinsamen Wurzeln sowie der Fokus auf Werte anstatt auf konkrete Handlungsanweisungen verbindet die beiden Ansätze. Man könnte sagen, Software Crafting schneidet die agilen Werte auf Devs zu.

Das Mindset

Aus den beschriebenen Büchern und dem Manifest leiten sich für mich die folgenden vier Leitmotive ab, die mich in meiner täglichen Arbeit begleiten:

Leidenschaft

Softwareentwicklung soll mehr als ein 9-to-5-Job oder "Dienst nach Vorschrift" sein. Schließlich erschaffen wir jeden Tag etwas Neues! Was häufig übersehen wird: Bei der Entwicklung von Software handelt es sich eher um eine kreative Arbeit als um einen stoischen Ingenieurberuf. Es ist daher durchaus erlaubt und angebracht, stolz auf das eigene Tagwerk zu sein. Gleichzeitig geht damit auch einher, sich die eigene Verantwortung bewusst zu machen und ihr entsprechend zu handeln.

Exzellenz

Qualität ist nicht verhandelbar! Code sollte auf dem bestmöglichen Niveau gefertigt werden. Immer wieder werden neue Probleme auftauchen – aber auch neue Möglichkeiten, diese zu lösen. Es erfordert ständige Weiterbildung und Übung, um auch auf unbekannte Herausforderungen adäquat reagieren zu können und die Chancen als solche zu erkennen. Als Ertrag baut sich über die Zeit ein nützlicher Werkzeugkasten auf, der dank des nächsten Abschnitts auch gut "ausgeliehen" werden kann und auf diese Weise noch mehr Nutzen stiftet.

Austausch

Wer kennt es nicht: Das Bild vom Entwickler im Keller, bevorzugt ohne Tageslicht und Frischluftzufuhr, alleine vor sich hin codend, während die einzige menschliche Interaktion aus der Bezahlung des Pizza-Lieferdiensts besteht? So ein Vorgehen ist mittlerweile nicht nur überholt, sondern auch durchaus gefährlich: Es entstehen dabei nämlich Wissens-Inseln und eine gewisse Betriebsblindheit. Daher sollte oft und viel über Software und Softwareentwicklung diskutiert werden: im Team, unternehmensweit und außerhalb der Arbeit. Neue Erkenntnisse können dabei auch aus ganz unerwarteten Richtungen kommen – gebt dem Ganzen einfach eine Chance und seid offen für Impulse!

Haltung

Viele Software-Entwickelnde haben erlebt, wie Kunden oder "das Management" beziehungsweise "das Business" Anforderungen an sie herangetragen haben, die nahezu unmöglich umzusetzen waren oder sind. In diesen Fällen (genau wie bei lediglich mit drastischen Qualitätseinbußen umsetzbaren Anforderungen) ist es wichtig, klar "Nein" zu sagen. Dabei ist allerdings darauf zu achten, dass dieses “Nein” immer mit einer konstruktiven Alternative kombiniert wird, anstatt bestimmte Wünsche rigoros aus Prinzip zu blockieren. Auf diese Weise lässt sich im Dialog mit den Beteiligten meist eine Lösung finden, die alle Seiten ausreichend gut berücksichtigt.

Auch wenn während der Entwicklung Unvorhergesehenes eintritt, sollte dies frühzeitig und offen angesprochen werden. Die ehrliche Kommunikation mit Kolleginnen, Kollegen und Führungskräften genau wie mit Kunden ist ein Kernwert von Software Crafting.

Mein Fazit

Unabhängig davon, ob ihr nun die Handwerks-Metapher passend findet oder nicht: Die dahinter liegenden Werte sind nicht per se an den Begriff Software Crafting gebunden. Sie sollen dabei helfen, zufriedene Dev-Teams zu haben, besseren Code zu schreiben und erfolgreiche Projekte durchzuführen. Wer mehr darüber erfahren möchte: Schaut euch am besten diesen aufgezeichneten Vortrag in der Agile Usergroup FrankfurtRheinMain an → Software-Crafting in agilen Teams.

Noch mehr spannende Impulse gefällig?

Am 17. Juni 2021 von 17:00 bis 19:00 Uhr findet die nächste Agile Usergroup als Remote-Event statt, diesmal zum Thema "OKR's – ein Führungsinstrument?". Hier könnt ihr euch anmelden und am 17.6. dann entweder über Google Meet am Usergroup-Treffen teilnehmen oder über YouTube streamen.

---

Weitere Infos

Ein Beitrag von der Tools4Agile Teams 2020 über OKRs und erfolgreiche Führung
Zusammenfassung der Ergebnisse der letztjährigen Stack Overflow Dev Survey (Die neue Survey erscheint voraussichtlich erst im Juli/August 2021.)
Unser Podcast-Beitrag über moderne Softwareentwicklung
Qualität vs. Anforderungen in der Softwareentwicklung und warum das mitunter problematisch ist