Attending SoCraTes UK over the weekend got me thinking about Software Craftsmanship in general, and the different perspectives within the movement was one of those things, particularly the differences, as I perceive them, between the North American* and the European schools.
Software Craftsmanship started off in the US about 5-6 years ago, as something of a reaction against the sea change in the agile movement away from technical practices. I first came across it myself in 2010, and it looked right up my street, so I promptly booked myself onto that year’s Software Craftsmanship UK conference at Bletchley Park. I liked the technical focus of the conference, particularly the hands-on nature of it, and I’ve been every year since (hopefully see you there in October!). Reading more about the movement, I saw a great deal of focus on practices, particularly those inherited from XP like pair programming and Test-Driven Development.
A couple of years later, I started attending the London Software Craftsmanship Community meet-ups. Initially, I went along to their workshops to learn something new about the act of developing software, a new technique to try out, practice my TDD, etc. A few months later, I started attending their Round Table discussions as well, and found the opportunity to talk to other craftsmen invaluable. Discussions around Domain-Driven Design, corporate cultures, motivation, and hiring good developers, were just some of the highlights of the conversations there.
Clearly on display at SoCraTes UK this weekend was a plurality of ideas, and people willing to reflect on their craft and develop their understanding through the challenging of their principles, practices, ideas, and beliefs. I saw this across the group of 70 people attending from at least 5 countries in Europe. It could easily have been an exercise in navel-gazing, but what we had instead were productive discussions that helped us form a clearer collective picture of the concept of Software Craftsmanship.
Something we discussed in the fish bowl at the start of the conference was whether Software Craftsmanship was becoming a religion, particularly in the way we share our values with other people. @sleepyfox made the point that we shouldn’t be trying to bring our values to other people, because it’s too much like a religious war, or a crusade. That way lies dogmatism, the antithesis of what lies at the heart of Software Craftsmanship. I fear there are some elements of Software Craftsmanship that are becoming religious and dogmatic, and that as a result the movement as a whole is starting to lose some of its pragmatism.
What I have thought for a long time now is that Software Craftsmanship is really about more than just the technical practices. The manifesto talks about “a community of professionals” and “productive partnerships”, for example, as well as “well-crafted software”. The further reading page on the Software Craftsmanship website includes links to blog posts, including one asking “Is Craftsmanship all about code?”
Unfortunately, it seems to me that the North American school of Software Craftsmanship is all about code. Corey Haines brought the world the Code Retreat, and JB Rainsberger the Legacy Code Retreat. Uncle Bob travels the world talking about Clean Code, TDD, the SOLID principles, and more. I’m enormously grateful to these people for providing such important and valuable formats for learning, and for sharing their knowledge with the world to better the technical state of the industry. When I look at the North American Software Craftsmanship movement, however, it feels to me like there’s something missing.
Practices come and go, and those that tie themselves to their practices risk irrelevance. I firmly believe that Craftsmanship practices (or XP practices), such as pair programming and Test-Driven Development, have inherent value to the extent that everyone should learn them. Learning them is different from using them all the time, however: there situations where TDD is a difficult practice to apply, such as when working with a large body of legacy code. While you can use TDD in some cases in this context (e.g. when adding new classes and functionality), in the main you have to adopt a test-last approach for the simple reason that the code has already been written, the design has already been decided. Other techniques, such as the Golden Master and incremental refactoring, will keep you more productive than TDD in this context.
The North American school’s focus on technical practices opens us up to criticism along the lines that we have seen: “you’re TDD Nazis”, “you’re too focussed on code”, and “you’re elitist”. This last one stings the most for me: yes, we are actively trying to improve our craft, and yes we want to improve the industry, but we want to do that in as an inclusive way as possible. It’s not a case of converting people to the Software Craftsmanship religion, it’s a case of inspiring people of all abilities to seek to better themselves through our ethos of mentoring and peer learning.
What I see in the European school of Software Craftsmanship is a superset of the North American school: not just technical practices, but discussion, collaboration, learning and mentoring. It feels more fully-formed to me as a result, more holistic, more inclusive and welcoming. Perhaps it’s a difference between European and North American cultures being expressed in the equivalent parts of our community, or maybe it’s that the European school is an evolution of the North American school; I don’t know. What I do know is that, while I see value in the technical focus of the North American school, the European school is the idea of Software Craftsmanship I identify with the most, and the one I will continue to promote.
* It might be unfair to generalise the North American movement as such. It’s entirely possible it would be more accurate for my comments on the “North American school” to instead be addressed to the “Chicago school”. I would be interested in hearing from someone with more knowledge of the movement that side of the Atlantic. Return to article