John Topley’s Weblog

One of the aspects of the world of software development that I find interesting is that as a group we seem to be constantly searching for the perfect metaphor or analogy to explain to non-software developers what it is we actually do. Some have said that writing software is like building a house, but others disagree and claim that it’s a more organic process akin to something like gardening. Some people like to think of themselves as software engineers, with all the rigour and discipline such a title implies. Whereas others regard themselves as artists, creating software by tastefully melding many creative disciplines.

I can’t really think of any other profession that is so self-absorbed with trying to define itself, but it is understandable because software development is still a young profession. It’s hard to think of anything else that is quite so abstract in terms of the daily materials we work with. Sure, we bash away at our keyboards, but ultimately we are manipulating fleeting pulses of electricity within the microscopic circuits of a CPU.

So it was with this background of uncertainly and introspection that I recently became aware of the Software Craftsmanship movement. At first the connotations the term brought to my mind weren’t especially positive. I thought of a carpentry shop or a blacksmiths. Skilled and detailed work undoubtedly, but far removed from what I do. A world of woodworking planes and chisels, not compilers and text editors. So I decided that I’d better look beneath the surface of the name and find it what the movement is really about. This is what the Manifesto for Software Craftsmanship has to say:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

The Software Craftsmanship movement came out of the ideas expressed in The Pragmatic Programmer book by Andy Hunt and Dave Thomas and more explicitly in Software Craftsmanship by Pete McBreen. I have read the first of those books but haven’t yet read the second. The movement is founded on the idea that software development is still largely a craft industry because most applications are specialized. In other words, no-one has yet found a way to mass produce software development. It can occur on a large scale, as it does at Microsoft, Google, Apple and Oracle et al, but there isn’t an easily transferrable and repeatable process, because there are simply too many variables within each project. This makes sense.

The notion of craftsmanship also implies that programmers go through stages in their career that are akin to the European medieval guild traditions. This means starting as an apprentice working closely with journeymen and masters and learning from them, before progressing to becoming a journeyman who is someone who moves between teams, projects and masters, spreading ideas as he or she goes. Finally, achieving mastership means having the ability to enhance the skill of others significantly, ideally until they surpass your own. This is done by training and by creating tools to make the work easier.

An important point is that becoming a master doesn’t mean reaching the end of the software craftsmanship journey because there is no end as such—you should always be learning and acquiring new skills. A master is a superset of a journeyman and an apprentice, just as a journeyman is a superset of an apprentice.

The craft model recognises that you can’t pick up a skill just by being told about it. You have to practice the skill under realistic conditions and under the watchful eye of an experienced practitioner. In software craftsmanship this is frequently accomplished by pair programming. Intrigued and in agreement with these ideas, last weekend I read Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman by Obtiva’s Dave Hoover and Google’s Adewale Oshineye.

The first thing I liked about this book is that at about 130 pages it’s an easy read. Although I read it all the way through, it’s actually intended to be dipped in and out of, because as the name implies, it’s a catalogue of patterns. It’s common for readers of patterns books such as the original Gang of Four Design Patterns book or Refactoring to realise that the book they’re holding simply gives a name to things that they were already doing anyway, and so it was for me with Apprenticeship Patterns.

For example, the Read Constantly and Study the Classics patterns encourage you to consume as much of the written word as possible, particularly by immersing yourself in the classics of the field. The Breakable Toys pattern is about building things for yourself in order to create opportunities for yourself to learn by building complete software projects on your own. The software that this blog uses is one of my breakable toys, as are UUID Waster and Truth Tables. This blog is also where I implement the Record What You Learn and Share What You Learn patterns. You may be thinking that some of these patterns sound kind of obvious and not really a big deal and that’s true to an extent, but I did find that this book contains some real insight into how to progress as a software developer by thinking more about certain situations and by practising deliberate behaviours.

The White Belt is a pattern for when “you a struggling to learn new things and it seems somehow harder than it was before to acquire new skills.” This resonated with me because I’ve been feeling like that lately whilst learning how to write my first Ruby gem and how to test it correcting using the RSpec Behaviour-Driven Development framework. The pattern talks about being prepared to sacrifice some short term productivity in whatever it is you’re trying to learn, so that you can leap forward. You have to unlearn what you know to acquire deeper and idiomatic knowledge of that new thing you’re trying to master.

The Be The Worst pattern encourages you to surround yourself with developers who are better then you are so that you have room to grow. As guitarist Pat Metheny said to some young musicians: “Be the worst guy in every band you’re in.” This pattern is all about starting at the bottom and working your way up and then repeating the process by finding a stronger team when you do become as skilled as your peers.

The patterns in the book are broken down into a context, a problem, the solution and concrete action you can take. Some of the patterns also include risks of applying the pattern to your career. For example, by being the worst you may drag the rest of your team down or even get fired!

I enjoyed reading Apprenticeship Patterns and found that it helped me to get some things I have been struggling with in my mind into perspective. Being primarily immersed in the Ruby on Rails world it can sometimes feel difficult to keep your head above water, because the pace of change is so fast and there always seems to be some supposedly wonderful new fad to learn. The book explains that if you aspire to become a software craftsman then you need to plan for the long term, for “if you’re still going to be working in 20 years' time, then you can do anything.”

It also made me realise that there’s only so far you can go programming in isolation. Doing so is great and it does give me pleasure, but you need to work closely with someone who is more experienced to get to the next level—as long as you both approach it with the right attitude and leave your egos at the door. I think this realisation is actually the logical conclusion of the value I’ve got out of watching screencasts such as Railscasts and PeepCode, where effectively you’re working along with a non-interactive mentor. Pair programming with a real person is the end game along that path.

To return to the issue of struggling to define the nature of software development raised at the start—did I come away from reading Apprenticeship Patterns with any clearer an idea of how to categorise what we do? Yes I did, actually. To quote the book: “software development is a craft precisely because we don’t understand it well enough to make it a codified discipline like science or engineering.” If you’re a developer and you find yourself agreeing with that statement, then I’d recommend reading Apprenticeship Patterns as you start walking the long road to becoming a software craftsman.