Craftsmanship vs. Apprenticeship

Are apprenticeships scalable?

Back at the beginning of the year I had lunch with a university professor interested in the notion of software craftsmanship. This is an extract from an email he sent me at the time:

I wonder about how scalable the apprenticeship model is. It seems to be predicated upon mentorship, where each apprentice has a mentor. This means you need a large number of mentors if you have a large number of apprentices. They will have to be found and paid. This will cause difficulties... If you want 1 teacher per 10 students you'd have to find an pay 10 times as many as now. How does the Software Craftsmanship movement intend to deal with this?

Buried in this problem is an inherent assumption about the way programming is taught. It assumes the current university model of teaching undergraduates: employing researchers who spend most of their time away from their students doing what they’d really like to be doing, whilst having to teach classes to pay the bills.

If you try and use an apprenticeship model in this context, you run into severe funding issues: who will pay for all the extra researchers?

A different way

Why don’t universities do real software projects? Why can’t we have master practitioners being paid by real clients to do real work, and have the students along for a ride, learning as they go?

The funding issues will be cleared up as business will be paying. Students work for free, or perhaps room and board. Either way they won’t be saddled by exhorbitant fees.

If this makes sitting in a lecture hall listening to information difficult to fund, then great. That’s one of the most inefficient ways to learn: why do we persist in trying to sustain it? There is value in book learning, and the industry does currently rely on students to achieve that through university education. But the best way to pick up those principles is through real-world examples on real projects, supported by appropriate exercises designed to drive home specific points. It is certainly not through sitting in a lecture hall.

Maybe this model is a step too far for a traditional university. Perhaps they’re not be the best place to learn our craft. Our current university system is designed to create great professors, not great practitioners. Perhaps it’s time for a change.

Are coding katas really worth it?

Last year I took up Wado-ryu Karate. It’s something that I’ve always wanted to do, and yet never quite got around to. I briefly took it up at university about 15 years ago, and put it down rather too quickly. About a year ago I decided it was time for me to stop saying “I wished I’d learnt it”, and got down to actually learning it.

Karate as a discpline is ancient compared to that of my other discipline, writing software. There are many lessons that we can take from it, and I’m sure I’ll be blogging more about this as I gain more insight. However, one big lesson I’ve learned so far is the value of a Kata.

What is a Kata?

Admittedly, I’d not heard of the term until finding out about the Software Craftsmanship movement a couple of years back. It’s the process of coding a solution to a fixed problem over and over again, trying new things and attempting to gain insight. On first hearing, I liked the concept, but in honesty I thought: “yet another bunch of coders who want to be Samurai!”

On reflection however, and especially after hearing Micah’s viewpoint, I could see the potential value of practicing a certain number of steps over and over. Therefore I decided to give it a go. When trying the technique in 2009, before I started karate, I admit I couldn’t connect katas to better programming performance. I published a checkout kata late last year, and enjoyed working on it. However the jury was out on how much I learnt from it.

That changed when I started Karate.

Katas in Karate

In my particular school, katas are commonplace and begin after your third belt. They are specifically designed to teach certain techniques, and to ensure that your basics are correct (and remain correct over time). So far, I have learnt Pinan Nidan, the first kata in Wado-ryu. It’s designed as a mock fight, where you take on eight imaginary opponents and dispatch them one by one using various techniques.

Technically, this kata contains three types of blocks, two types of stances, one type of punch and a spearhand attack. It’s very simple, and designed to ensure that your body can perform the basics in sequence easily. Once you’ve got the basic moves in the correct order, you then move on to ensuring that your position and strength is good when performing the Kata.

When in a real sparring situation, you then instinctively use parts of the kata to help you. If all you’ve been doing is ‘block, punch, block, punch’ for several hours, then when someone actually comes to hit you, you block correctly and find you’ve thrown a punch without thinking. Watching black belts spar is fascinating: most of what they do is totolly instinctive.

How can we learn from this?

Rolling code without thinking is valuable. I would love to be able to roll code automatically, in the same way that martial artists combine moves in sequence effortlessly. Wouldn’t it be fantastic to be have thoughts and concepts appear on the screen without really even trying? Granted, our tools and methods do change over time, but we need to learn them inside out. Stick to one editor, for example (preferably a decent one). Get to know a framework really well, so that you can make things happen without exercising your brain, leaving maximum energy to think about your problem.

Katas need to be designed well, and operate best as a set. Perhaps what we need on our university courses and apprenticeship schemes is a list of basics (“learn the syntax of Ruby/Haskell/Clojure”), and then a simple problem (kata) to practice a solution for. Rather than have them complete the project and hand it in, they have to perform it in front of an instructor. They might have to repeat this every two weeks. They should be able to perform old projects on demand. These will need to be designed well, so that they offer the maximum learning. A poorly designed Kata is fairly useless.

Please can we get over the ‘coders who want to be samurai’ thing? There are a bunch of starry-eyed coders who would desperately love to be ninjas, and another group who quietly laugh at them. Both are missing the point. In Karate, katas aren’t glamourous; they’re difficult, frustrating and really hard work. But let’s not discard them out of hand! There’s ancient teaching and learning methods here that have proven effectiveness. Let’s learn from them.

I need to think more on this. Perhaps there’s a specific set of katas that is tailored to a particular language that can be designed to really encourage speed of learning and growth. I do believe that a lot of the way we teach programming is inefficient and more about information than practice. Is there a better way?

BBC Talk on A Philosophy of Software

Video of a talk I gave recently at the BBC about the nature of software development. We discuss craftsmanship, apprenticeship and the limitations of university education, amongst other topics.

Watch the video here:

Driving out feature ambiguity

Cucumber features are very useful. The ability to spec out what the customer wants in detail in a format they can read and understand really helps to communicatate what needs to be done. This combined with the ability to execute the feature to ensure that it is completed correctly catches many bugs and incorrect assumptions.

However there is one area of bugs that features don’t catch so well, and even cause to some extent. These bugs are built right into the text in the form of ambiguity, sometimes through the constraint of features being executable.

This came up recently in a conversation with James and Enrique at Eden Development about James’ apprentice task, the Snakes and Ladders Kata. It turns out that the text of one of the features runs against the commonly understood way that Snakes and Ladders works:

Scenario: Win the game
    Given player 1 is on position 97
    And player 1 rolls 3
    Then player 1 has won the game

Question: is that a valid scenario? Given the commonly understand rules of Snakes and Ladders, you cannot just start on position 97. Implementing it as written complicates the domain model.

How do you implement the first step? Do you go for a simple:

Given /^player (.*?) is on position (.*?)$/ do |player, position|
  @game.set_player_position(player, position)
end

The potential issue with this is that you are exposing a method that in real life won’t get called, just to set up a test. It’s also tying your model down to a particular structure, by implying that the game stores an arbitraty position variable for a player. This might not be the best way to model the problem.

The other option is to change the scenario such that the “Win the game” is tested in a similar way to the following:

Scenario: Win the game
    Given a game is started with two players
    And the following dice are rolled:
      |3|
      |4|
      |5|
      |5|
      (etc.)
    Then player 1 has won the game

That satisfies our understand of Snakes and Ladders, and gives us more freedom in our domain model. In this case, we simply modify the agreed scenario in the code and sidestep the problem.

Right? Wrong.

The important thing to remember is that the customer is always right about how the software should behave, even when it violates our commonly understood assumptions about the world. The software they want you to build might require a different implementation of Snakes and Ladders. They might have a 3 year-old daughter they’re planning to play the game with, who always wants to be given a headstart. In this case, we’ve not delivered what they want, simply because it makes life easier for us. We’ve let our assumptions and our concerns for good design drive out the features, rather than letting the features drive our design.

There’s another possibility: when the customer wrote this scenario, they simply used “starts on position X” as a shortcut and don’t really care if it’s possible to do this in real life. In this case, we can work with them to write the scenario so as not to cheapen our design for the sake of easier feature writing.

The key insight: there’s no way that we can know which it is from reading the scenario. We have to ask the customer and drive out the ambiguity in the feature.

We mustn’t let the necessary constraints of executable features build ambiguity into your conversations about what the customer really wants. And we must be constantly talking to the customer all the way through the iteration, especially if they’re not on site.

You might think “It’s only Snakes and Ladders, what does it matter?” It matters a great deal: situations like this come up regularly in real life projects. Practising how to deal with these issues and the conversations that result is one of the many powerful things you gain by doing katas.

What’s your take on the above problem? Have you come across it in real life?