Was ist der Unterschied zwischen Software Craftsman und Software Engineer? Darüber kann man natürlich lang und trefflich debattieren. Doch mit den von mir vorgestellten Arbeitsweisen, ist die Unterscheidung einfach und augenfällig, glaube ich.
Wie beschrieben, arbeiten wir als Softwareentwickler sowohl als Handwerker (H) wie als Ingenieure (I) und auch als Forscher (F).
Arbeitsweisenverhältnisse
Allerdings sind die Anteile der drei Arbeitsweisen nicht gleich. Für mich dominieren I und F; H macht den kleinsten Teil aus.
Der tapfere Software Engineer wird das aber noch etwas anders sehen. Für ihn wird der Entwurf eine größere Rolle spielen als Forschung oder Codierung. Codieren kann man lassen und Forschung, z.B. beim Bug Fixing, ist mit guter Entwurfsvorarbeit nicht so häufig nötig, oder?
Das steht im Gegensatz zur Sicht der eher haptisch veranlagten Software Craftsmen, denke ich. Den Löwenanteil der Arbeit hält man dort für handwerklich. Warum sollte man sich sonst “Craftsman” nennen?
Forschung wird man auch noch groß schreiben (müssen), weil Anforderungsanalyse und Code-Analyse nicht zu läugnen sind. Doch der Entwurf, allemal der explizite, steht im Hintergrund. Am Ende spricht ohnehin nur der Code die Wahrheit, oder?
Eine unterschiedliche Einschätzung des Mischungsverhältnisses scheint mir eine erste augenfällige Differenz zwischen den Lagern der Engineers und der Craftsmen.
Ein anderer die bevorzugte Bewegungsrichtung durch die Arbeitsweisen.
Arbeitsweisenreihenfolge
Software Craftsmen favorisieren TDD, um nicht in die BDUF-Falle zu geraten. Das scheint handwerklicher als ein ingenieursmäßiger Entwurf vorab. Doch damit entkommen sie dem Thema Planung nicht. Sie verschieben es nur. Für mich bewegt sich der Software Craftsman bevorzug gegen den Uhrzeigersinn durch die Arbeitsweisen:
Am Anfang steht Forschung. Anforderungen müssen analysiert werden. Daraus ergeben sich Tests in rot (F). Die werden im nächsten Schritt handwerklich möglichst einfach (KISS) auf Grün gebracht (H). Und daran schließlich sich dann eine Refaktorisierung. Für die muss man jedoch einen Entwurf haben (I). Denn so handwerklich Refaktorisieren in einer IDE aussehen mag, ohne Vorstellung von einer Zielstruktur geht es nicht. Die aber ist Ingenieursarbeit.
Der Software Engineer denkt da anders. Er bewegt sich mit dem Uhrzeigersinn durch die Arbeitsweisen:
Auch bei ihm steht die Forschung am Anfang. Anforderungen in Form eines Lastenheftes müssen analysiert werden. Das Ergebnis ist ein Pflichtenheft (F). Dafür wird im nächsten Schritt ein Lösungsentwurf erarbeitet (I); UML ist dafür als Werkzeug gedacht. Und erst am Ende steht eine Implementierung des Entwurfs (H).
Arbeitsweisenfrequenz
Ein weiteres Unterscheidungskriterium im Hinblick auf das “Arbeitsweisenrad” scheint mir die Geschwindigkeit, mit der Software Engineers und Software Craftsmen es drehen. Die Engineers drehen es langsamer als Craftsmen.
Nicht, dass Engineers keine Iterationen kennen würden. Aber Sie glauben daran, dass man durch Forschung und Entwurf ein größeres Rad drehen kann. Craftsmen hingegen sind erpicht auf Feedback vom Kunden. Deshalb favorisieren sie schnellere Drehungen.
Zusammenfassung
Kein Wunder, wenn sich Software Engineers und Software Craftsmen immer wieder sprachlos gegenüberstehen, oder? Das wussten Sie natürlich schon vorher ;-) Aber ich hoffe, durch die Brille der Arbeitsweisen HIF sehen Sie nun deutlicher, woran das liegt. So lassen sich die unterschiedlichen Positionen besser kommunizieren, finde ich. Der Blick ist differenzierter.
Die genauen Prozentzahlen der Arbeitsweisen, sind dabei nicht so wichtig. Es geht um die groben Verhältnisse. Ohnehin verschieben die sich nach Projekt und Anforderungen auch immer wieder etwas. Deshalb zählt die Tendenz.
Durch diese Aufschlüsselung habe ich für mich z.B. realisiert, dass ich weder Software Engineer noch Software Craftsman bin. Ich hänge irgendwo dazwischen:
- Für mich dominiert weder I noch F, aber H hat definitiv den kleinsten Anteil.
- Für mich dreht sich die Softwareentwicklung im Uhrzeigersinn.
- Für mich dreht sich das Rad im wesentlichen alle 4 bis 16 Stunden. Das ist der wichtigste Zyklus, um ein Inkrement herzustellen (d.h. einen feedbackfähigen Codezuwachs). Innerhalb dessen kann es kürzere TDD-Iterationen geben - muss es aber nicht. Oberhalb dessen kann es längere Release-Iterationen geben - muss es aber nicht.
Und wenn der nächste Selbstverständnis-Hype aufkommt… dann haben Sie nun ein kleines System, mit dem sie ihn analysieren können.