Durch etliche Diskussionen auf Konferenzen bekomme ich immer mehr die Frage nach einer Definition von Software Craftsmanship mit. Auch wenn ich für UserGroups glaube, dass es mehr Sinn macht, sein eigenes Verständnis über die Handwerskkunst der Softwareentwicklung selbst zu definieren, glaube ich, dass uns eine Definition des Begriffes fehlt. In der Tat gab es früh schon Diskussionen zu dem Therm, aber darüber hinaus auch unterschiedliche Verständnisse unserer Mission. Beides zusammen für mich noch ein weiterer Grund, meine Gedanken zu dem Thema einmal nieder zu schreiben.
Clean Code
Ein Riesenmißverständnis um Software Craftsmanship ist, dass es sich einzig und allein darum dreht, dass wir wunderschönen Code schreiben wollen. Ja, wir wollen guten Code schreiben, wir wollen dafür SOLID, Common-Closure, Common-Reuse, Azyklische und stabile Abhängigkeiten, test-FIRST und vor allem guten Code produzieren. Und wir wollen auch ein professionelles Bild an unsere Kunden geben. Was bedeutet das? Das bedeutet, dass uns als Softwareentwicklern am Herzen liegt, unsere Tätigkeit als etwas Herausforderndes und Kreatives zu verkaufen. Wir wollen vor allem stolz auf das Produkt und unsere Arbeit sein. Und das schaffen wir, indem wir unsere Kunden davon überzeugen, dass sie den richtigen Experten für die Softwareentwicklung gefunden haben und wir ihnen mit voller Aufmerksamkeit ein hervorragendes Produkt zukommen lassen.
Das schaffen wir, indem wir die Probleme unserer Kunden so ernst wie unsere eigenen nennen. Das beinhaltet, dass wir deren Problem verstehen, dass wir deren tägliche Arbeit durchdringen und dass wir durch ständigen Austausch ein Vertrauensverhältnis zu uns aufbauen. Letzten Endes können wir auf unsere geleisteten Projekte zurückblicken und unsere Reputation darauf aufbauen.
Ja, das bedeutet, dass wir nicht nur guten Code produzieren, sondern dass wir vorab das Problem des Kunden verstanden haben, dass wir unser Verständnis mit dem des Kunden abgleichen und im kontinuierlichen Austausch miteinander Kurskorrekturen vornehmen können. Das bedeutet aber auch, dass wir unseren Kunden über Verzögerungen so schnell wie möglich informieren können. Nichts-desto-trotz bedeutet es, dass wir bei der Lösung der Probleme unserer Kunden Lösungen finden, die diesen begeistern können.
Ein Friseur, der mir nur die Haare schneidet, wird bei mir eher wenig Begeisterung hervorrufen können. Ein Friseur, der mir die Haare schneidet, und mich fragt, ob er meine Augenbrauen kürzen soll, begeistert mich nachhaltig. Bei so einem Service komme ich gerne wieder. Wie? Das hat nichts zusätzlich gekostet? Lassen Sie uns gleich einen Nachfolgetermin vereinbaren!
We care!
Übung, Übung, Übung
Zugegeben, dieses Ziel ist schnell formuliert, aber schwer zu erreichen. Wenn das so einfach wäre, würden das schließlich auch alle machen. Dazu gehört nicht nur die Kenntnis der Methoden und Prinzipien, sondern auch, dass wir uns mit unseren Werkzeugen auskennen. Ein Zimmermann, der nicht weiß, dass er seinen Hammer am Schafft halten muss, wird schnell ohne Arbeit sein.
Dafür braucht es aber auch Übung mit unseren Werkzeugen. Um fehlerfreien Code zu schreiben, der lesbar, verständlich und zugänglich ist, brauchen wir nicht nur Wissen über unsere Tools, sondern auch über unsere Programmiersprache. Dafür brauchen wir Übung. Auch unsere Methoden und Techniken müssen wohl eingeprobt werden. Dafür brauchen wir Zeit, um damit zu üben.
Mein Großvater war Tischler. Er hatte viele Projekte in seiner Werkstatt laufen. Oft drehte sich viel darum, dass er kleine Verzierungen für seinen Garten oder seine Terrasse gebaut hat. Einmal baute er ein Osterrad, denen aus der Stadt Lüdge nachempfunden. Dieses tat er, um seine Werkzeuge kennenzulernen und seine Techniken einzustudieren. Für uns Softwareentwickler bedeutet das, dass wir uns in OpenSource Projekten engagieren, uns in Code Katas üben und Tastaturkürzel für unsere IDEs beherrschen müssen. Durch viele Stunden wird so langsam aber sicher aus dem Lehrling ein Meister.
We practice!
Lebenslanges Lernen
Bereits in frühen Jahren war mir klar, dass ich lebenslang lernen werde. Mein Vater war Automechaniker. Er erzählte mir einmal, dass er mit jeder neuen Autoserie wieder etwas neues zu lernen hatte. Auch einem Mechaniker war das Konzept von lebenslangem Lernen klar. Wieso tun wir uns in der Softwareentwicklung so schwer damit?
Auf unserem Weg zum Experten müssen wir uns kontinuierlich mit neuen Technologien beschäftigen. Das kann beinhalten, dass wir eine neue Sprache erlernen, die funktional statt objekt-orientiert vorgeht. Oder wir arbeiten eine Zeit mit dem neusten HTML5-Framework. Oder wir schreiben ein xUnit-Testframework für die neuste Sprache von Google.
Lebenslanges Lernen beinhaltet aber auch, dass wir die Arbeit anderer Softwareentwickler ansehen. Wo liegt der revolutionäre Ansatz bei Node.js? Wieso gibt es bei TDD Prioritäten um von rot nach grün zu kommen? Was passiert, wenn ich diese ändere? Wie kann ich meine bekannte Kata neu gestalten, so dass ich aus meiner Komfortzone komme? (Stichwort: TDD as if you meant it.) An all diesen Aufgaben werden wir letzten Endes auf dem Weg zur Meisterung wachsen.
We learn!
Communities
Aber wir arbeiten auch mit anderen Softwareentwicklern zusammen. Meistens kann man das ohnehin nicht vermeiden, wenn man etwas lernen will. Aber wir bilden auch neue Lehrlinge in unserem Beruf aus. Wir teilen unser Wissen mit anderen, indem wir es ihnen beibringen. Das kann in der Form von Mentorenschaften geschehen, oder in der Form von echter Ausbildung. Je mehr unsere Lehrlinge dabei ihr Wissen weitergeben, umso besser für unser gesamtes Berufswesen! Zwei hervorragende Beispiele dafür sind die Blogs von Colin Jones und Justin Martin während ihres Apprenticeships bei 8thLight.
Aber wir sind auch in der Lage, auf diejenigen zu verweisen, die uns unser Wissen beigebracht haben. Wir können auf unsere alten Meister verweisen, von denen wir gelernt haben, die uns manchmal geärgert haben, aber die uns letzten Endes dabei geholfen haben, dass wir unser Berufsfeld der Softwareentwicklung weiter gebracht haben. Vielleicht waren wir aber auch in der Lage, unseren Meistern etwas beizubringen, wie in der Geschichte des Apprentices auf Wanderschaft, der nach etlichen Jahren wieder heimkehrte, um dem Meister etwas neues beizubringen.
We share!
Diese vier Prinzipien drücken aus, was Software Craftsmanship ausmacht. Wir kümmern uns um unseren Code. Deshalb lernen und üben wir. Aber wir teilen auch unser Wissen, damit die Softwareentwicklung im Allgemeinen einen Mehrweit und ein besseres Ansehen davon tragen kann. Das ist es, was Software Craftsmanship ausmacht.
Hallo, bin seit 1974 Softwareentwickler (Ausbildung Elektroingenieur), seit 1995 Freeleancer. Alles was Ihr schreibt stimmt, kann das mit meinem langen Berufsleben 100% bestätigen.
Schön, daß das mal jemand so formuliert hat.
Viele Grüße