Software Crafter Typologie

Versuch einer Typologie. Von Silas Graffy

   Software Development

Ob ich Software Crafter bin? Ja klar. Du etwa nicht? Jetzt mal ehrlich: Wir sehen uns doch alle irgendwie als Software Craftspeople. Aber es ist wie immer mit diesen Begriffen, mit denen wir uns schmücken: Frag elf Entwicklerinnen und Entwickler, was Software Craft ist, und du bekommst zwölf Antworten. Mindestens. Missverständnisse auf der ganzen Linie. Sind quasi programmiert – wenn das Wortspiel erlaubt ist. 

Silas Graffy ist Software Crafter

Ich wage mal eine Art Typologie der Extreme. So ganz subjektiv und natürlich satirisch überspitzt. Ähnlichkeiten mit tatsächlichen Begebenheiten und Personen sind bei solchen Personifizierungen rein zufällig, könnten aber vorkommen – oft genug auch bei mir selbst. Zur Sache:

— Die Engineers. Du kennst sie. Sie bezeichnen sich selbst nicht als Crafter, weil sie Software Craft nicht als Bewegung verstehen, zu der man sich zugehörig fühlen kann. Für sie sind Software Craftspeople Leute, die sich mit Softwareentwicklungspraktiken beschäftigen und auf deren Wissen sie dann gern auch mal zurückgreifen. Mit diesen Praktiken wollen Engineers ihre althergebrachten Entwicklungsansätze verbessern. Das fühlt sich gut an. Jedenfalls für sie. Es bestärkt sie. „Sich selbst grundsätzlich hinterfragen“ klingt dagegen esoterisch in ihren Ohren. Die Rollen sind klar auf ihrem Planeten: Sie teilen die Aufgaben auf zwischen gut und weniger gut ausgebildeten Leuten im Team. So wie anno Tobak ihre Lehrmeister. Auf der einen Seite also sitzen sie, oft stolze Architekten, und am anderen Ende die Entwicklerinnen und Entwickler, gern auch mal in Osteuropa oder Indien.  

„Collaborative Ownership“ haben Engineers sicher auch schon mal gehört – und zügig wieder verworfen. Denn Architektur, Code, Projektmanagement, Zeitpläne, Budgets und Gesamterfolg, ach, das alles gehört zu ihrem persönlichen Besitzstand. Sie sind sich sicher: 15 Prozent zusätzliche Zeit für Code Reviews reichen und machen einen Qualitätsunterschied. XP-Praktiken wie TDD und Pair Programming scheinen ihnen höchst fragwürdig. Scrum führen sie ein, weil man heute halt agil entwickelt. Man geht ja mit der Zeit. Ich versteh euch wirklich gut, Engineers. Und ihr seid mir echt sympathisch. Aber, hey, bessere Software entsteht anders.

 — Die Dogmatiker sind davon überzeugt, dass Software Craftspeople nichts ausliefern, was nicht perfekt ist. „Well Crafted Code“, das ist ihre Maxime. Sie lieben diesen Begriff, lassen ihn sich gerne auf der Zunge zergehen. Einhundert Prozent. Tausend Promille. Darunter geht nix. Soviel steht fest. Eine Sache vergessen sie leider völlig: dass nämlich Code, der nicht in Production ist, nix nutzt. Null Customer Value. Und schon gar kein valides Feedback. Dogmatiker beenden ihre Mob Programming Session, sobald die Entwickler-Kollegin sich kurz einen Kaffee holt. „Getting things done“ klingt für sie ähnlich verrucht wie „quick and dirty“.

Die meisten Dogmatiker, die dir begegnen, leiden am „Shiny New Framework Syndrome“. Manche sind aber auch anfällig für „Not Invented Here“. Beiden gemein ist der Mangel an Fähigkeit, einen Mittelweg einzuschlagen, situativ und pragmatisch. Dogmatiker sind in fast allen Teams der Welt vertreten. Und im Herzen haben wir längst einen großen Platz für sie reserviert. Denn die Wahrheit ist: Das geht dir selbst manchmal so. Mir übrigens auch. Und hoffentlich immer seltener.

Weeks of coding can save you hours of planning — Und dann ist da noch die Agil-kaida. Ihre Mitglieder tun nichts, was nicht im Scrum Guide steht. Das Agile Manifest ist für sie die Heilige Schrift der Software Crafters. Yes, endlich können all die ach so bürokratischen Pläne und Entwürfe verbrannt werden! Auf ihren Stirnbändern steht: „Weeks of coding can save you hours of planning“. Festpreis-Projekte lehnen sie grundsätzlich ab: nicht agil! Wasserfall gar! Gegebene Rahmenbedingungen? Was soll das sein? Partnerschaftlich das bestmögliche Projekt-Konstrukt anstreben? Nicht für Software Crafter der Agil-kaida!

Das macht vielleicht einsam, dafür aber ist man stolz. Konsequent umgesetzt braucht man sich früher oder später auch nicht mehr mit Kunden zu ärgern. Die sind dann nämlich weg. Gut so, denn: Was verstehen die schon von Agilität? Was wissen die von echter Software Craft? Auch die Agil-kaida läuft uns täglich über den Weg, auch ihr Stirnband haben wir alle an dem einen oder anderen regnerischen Tag schon mal getragen.

Für mich steht Software Craft für einen hohen Anspruch an mich selbst. Es geht um die Qualität der eigenen Arbeit. Das beginnt bei technischen Praktiken, geht über den Austausch mit Gleichgesinnten – ob sie sich nun Software Craftpeople nennen oder nicht – bis hin zu lebenslangem Lernen aus eigenem Antrieb. Software Crafter werden immer den Menschen in den Mittelpunkt stellen. Deshalb passen sie so gut zu uns. Sie beschäftigen sich mindestens so intensiv mit den Teams wie mit der Technik. Sie erkennen, was Teamwork großartig macht: Vertrauen, angstfreie Räume, Wertschätzung, Feedbackkultur, gemeinsame Ziele, intrinsische Motivation.

Für Software Crafter gehören Begriffe wie Konkurrenz und Wettbewerb nicht zum Wortschatz. Produktive Partnerschaften mit Kundinnen und mit den Anwendern ihrer Software sind das Ziel. Craftmanship bedeutet konstruktives Hinterfragen [1] auf Augenhöhe – zum Beispiel von bürokratischen, nicht-agilen Entwicklungsprozessen. Software Craftspeople überzeugen durch eigene positive Beispiele vom Typ „einfach mal machen!“ Sie bestärken und coachen statt sich in Fundamentalopposition zu verschanzen. Gesunder Menschenverstand eben. Und das passt auch zu uns.

Die Probleme des Kunden lösen Software Craftsmen und Craftswomen auch über das ursprüngliche Mandant hinaus: Denn was nützt die angefragte IT-Sanierung, wenn beispielsweise die Qualitätskultur fehlt? Das betrifft den Projektauftrag im Großen und jedes einzelne Feature im Kleinen. Warum fragt mich die Nutzeinr nach diesem oder jenem? Was ist ihr Ziel damit? Was hilft ihr wirklich?

Software Crafter übernehmen Verantwortung für ihr Handeln, statt Unbequemes „dem Management“ zuzuschieben. Das beginnt bei der Qualität des eigenen Codes und reicht über den Projekterfolg bis hin zu ethischen und gesellschaftlichen Auswirkungen der eigenen Arbeit. Diese Auffassung teilen einige, aber leider längst nicht alle Softwareentwickler.

Ob ich Software Crafter bin? Ja und nein. Denn diese Kunst fängt mit Erkenntnis an. Viel zu oft behält der Engineer in mir die Oberhand oder ich bin dogmatisch. Software Craft hört nie auf, uns zu fordern. Du bist nie da, sondern immer auf dem Weg. Doch mit Einsicht und Offenheit kommst du der Sache oft ziemlich nah. Das sind die Momente, an denen meine Arbeit mich so richtig zufrieden macht.

[1] So war in einer älteren Version dieser Seite – zugegebenermaßen auch aus Gründen der Auffindbarkeit in Suchmaschinen – fast ausschließlich vom „Software Craftsman“ die Rede. Auch hier gab Feedback Anlass zum Hinterfragen und Verbessern der eigenen Formulierungen.

Höchste Zeit, dass wir uns kennenlernen!

Hast du Lob, Anregung oder Kritik zu dieser kleinen Typologie des Software Craftsman? Sag mir, was du denkst. Mehr über mich und alle meine Blogbeiträge findest du hier. Ich bin zu diesem Thema auch schon mal interviewt worden. Mehr zur Ethik von Software Craftsman und Craftswoman findest du in diesem Beitrag.

Übrigens suchen wir Software Craftsmen und Craftswomen in München, Augsburg, Frankfurt, Berlin und Hamburg. Vielleicht schaust du ja bald mal bei uns vorbei – ich würde mich freuen!