Coding Is Like Cooking

As I mentioned in my last post I’ve recently taught a course in automated testing to a bunch of students at KYH. Before the course I spent some time looking for good course books for them. I looked at a few options and eventually decided on “The art of Unit Testing with examples in .Net” by Roy Osherove, and “The RSpec Book” by Chelimsky et al.

I chose the unit testing book because Roy does a good job of describing the basics of test driven development, including simple mocks and stubs. The book is very practical and is full of insight from experience and code examples.

I also looked at “Pragmatic Unit Testing in C# with NUnit” by Andrew Hunt and David Thomas. I’m a big fan of their book “The Pragmatic Programmer”, so I had high hopes for this one. Unfortunately I was rather disappointed with it. It talks about what good unit tests should look like, but not much about how you use Test Driven Development to create them.

I chose the RSpec Book because it has quite a bit of material about Cucumber and how it fits in to a Behaviour Driven Development process. I think the published literature on automated testing focuses too much on unit level tools, and there is not enough written about feature level tests and how to use them as part of the whole agile process.

I also looked at “Bridging the Communication Gap” by Gojko Adzic, which I think is an excellent introduction to how to use feature level tests as part of the agile process, but it is largely tool agnostic. There is a short chapter introducing some tools, including JBehave, a forerunner to Cucumber, Selenium and TextTest too. It’s a little out of date now though, and for this course I wanted something with more detail.

I hope these short book reviews are useful.

I’ve just spent 3 weeks teaching a class of 11 students about automated testing, as part of a one year course in software testing. The course is organized by the local “Kvalificerade Yrkes Högskolan”, KYH. (loosely translated: Skilled Trade University). The students come from all kinds of job backgrounds, from sitting in a supermarket checkout to driving trams to gardening, and most of them had never written a computer program before the course started.

The KYH tries to design their courses so that students will be competent enough to get a job by the end of them, so they work closely with local employers to set the curriculum and find teachers for the courses.

I was pleased to be asked to do this teaching job, since automated testing is one of my main areas of expertise, but at the same time I was quite daunted by the prospect. I’ve never taught non-programmers before, and I’ve certainly never had to set an exam or hand out grades. Before I agreed to do it, I spent some time talking to a friend of mine who has previously taught a different KYH course, and his story actually wasn’t all that encouraging. It’s hard work preparing the teaching materials, and some of the students will find it very difficult and need a lot of help and coaching. I decided it could be worth doing, anyway. I had some teaching materials prepared already, and I wanted the chance to invent more, try out some new ideas, and broaden my horizons.

Now that I’ve done the course I can attest that it really is hard work preparing lessons and exercises, and some of the students do need a lot of help. It is very rewarding though when they start to understand. I got a real kick out of going round the classroom seeing them all starting to write tests with Selenium and Cucumber, and answering their questions about Ruby and Page Objects and how to name tests and what to assert, and where to put the code and which parts to write tests for…

I think by teaching this course I’ve learnt a lot myself about things like how to communicate ideas, give feedback and encouragement, and to set boundaries and manage expectations. I found marking their work much more interesting than I expected, too. What kinds of mistakes do inexperienced programmers make when doing TDD? Do they find it easier to write good tests with Selenium or Cucumber? Is there any correlation between testing skill and programming skill? (short answers – they don’t refactor enough, Cucumber is way easier, and no, the correlation seems pretty weak)

So do I recommend getting involved? Absolutely! I think the IT industry in general needs more people in it from diverse backgrounds, and this is the kind of course that brings them in. If my experience is anything to go by, you’ll work hard but you’ll learn a lot from the students too. Networking with the other employers in the course Industry Reference Group is useful, and if I was looking to hire a junior tester I’d now know exactly who to ask first. Actually, who knows, in a few years some of my students might even be in a position to give me a job.

Don’t just complain that it’s hard to hire qualified people and/or people from diverse backgrounds. Get down to your local KYH equivalent and help them set up a course! I think that being a good software developer or tester is not restricted to only those with a degree in Computer Science. A course at a trade school where local employers get involved is good value for everyone.

The classic description of TDD that most people know is the 3 rules by Bob Martin. I think his rules are a very succinct description, and for a long time I’ve just relied on them, together with a picture of “red-green-refactor” to describe TDD to newcomers. More recently I’ve found value in expanding this description in terms of states and moves.

When I’m doing TDD in a coding dojo using the Randori form, I get people stepping up to take the keyboard who’ve never done it before, and I find it helps them to understand what’s going on if I explain which state we’re in and what the legal moves are for that state. The picture I’ve used is like this:

I’d like to go through each state and some of the moves you can make in each.

I think before we start on a TDD coding session there is value in doing a small amount of analysis and planning. In the dojo, I’ll spend around 15 minutes in this starting state before we start coding. We’ll talk about the chosen kata so everyone hopefully understands the problem we’re going to solve. We’ll write a list of potential test cases on a whiteboard, and identify some kind of “guiding test”. This is an overarching test that will probably take us a couple of hours to get to pass. It helps us to define the API we want to write, and the goal for our session. We may also talk a little about how we’ll implement the solution, perhaps discuss a possible data structure or algorithm.

I know the group is ready to move on when we have sketched a guiding test or goal for the session, and have chosen the first test we’ll try to make pass.

When we’re getting to red, we’re trying to set up a small achievable goal. We’ll choose a simple test from our list, one that will help us towards our session goal (guiding test). This test should force us to address a weakness in our production code.

Starting with naming the test then writing the assert statement helps us to focus on what the missing functionality is. Then we can fill in the “act” and “arrange” parts of the test. I’m not sure who invented the “Arrange, Act, Assert” moniker for structuring tests, but the idea is that a test has three parts. In the “Arrange” part you set up the objects the system under test will interact with, in the “Act” part, you call the production code to do whatever it is, and in the “Assert” step, you check it did what you expected.

In a compiled language it helps to fill in a bit of production code while we’re writing the test, but only just enough to keep the compiler quiet. Once the test executes, and is red, you can move on.

This is where we flip over to the production code (I’ve seen newbies presented with a failing test trying to edit the test to make it green!).

If we can easily see what the implementation should be, we might just write it, but often it helps to return some kind of fake value, until we work out what the code should be. Sometimes in this state we find the test we wrote is too hard, and we need to get back to green by removing or commenting out the failing test. This is a sign we understand the problem better than we did before, which is a good thing. In that case, we’ll go back to “Getting to red” and write a better test. Otherwise, we get to green by making the new test pass.

The refactoring move is where we want to remove fake implementations, refactor away code smells and improve code readability generally. Don’t forget there may also be duplication and readability problems in the tests as well as the production code. The trick is to do a series of small refactorings that taken together lead to a better design. Try to stay only a few keystrokes away from a running system (green tests).

While we’re looking for refactorings, we’ll probably spot weaknesses in the production code implementation – functionality that is missing or cases that are not handled. This is a cue to note new test cases, not to fix the code. If we find a hard coded return value, say, we should be able to think of a new test case that will force us to write a better implementation.

We can move on when we’re happy the design of the code is good (for the test cases so far).

At some point hopefully we’ll find we can get our guiding test to pass, and/or that we’re out of time and the coding session is over. We’ll look through the code a final time, (as we check it in, maybe), then take a few minutes to reflect on what we learnt during this coding session. In the coding dojo, we’ll spend some time discussing what was good and bad about this dojo session, and what we might do differently next time based on what we’ve learnt.

The cycle begins again with the next coding task or the next dojo session.

I travelled to Oslo last weekend, to take part in Agile Coach Camp Norway. This was an open space conference organized by some enthusiasts, not for profit. I became interested in going to the conference when I heard some other agile coaches tweeting about it. I’ve just started my career as a kind of agile coach, and I’ve always enjoyed the open space parts of other conferences I’ve attended. I hesitated though, since I have quite a technical focus. What clinched it was when Johannes Brodwall signed up – an excellent programmer who shares my interest in using Code Kata for teaching and learning Test Driven Development.

I was surprised to see Bob Martin in the hotel reception when I arrived – he had come on a whim since he was in Oslo that day. He spent some time on the first evening telling the story of how the agile manifesto came about, and his involvement. He’s an impressive speaker, even when improvising. Bob didn’t stick around for the rest of the conference, and he missed out on some really good discussions.

We began the main part of the conference with a “coaching dojo”, which Rachel Davies invented by analogy with a coding dojo. It was fun practicing coaching one another, and getting feedback from people who are used to giving good feedback. It really set the tone for the whole weekend.

After lunch, we had the open space opening session, and loads of sessions were proposed. I suggested 4, and ended up being very pleased I’d done them. I got some great feedback about a short coding dojo I ran – being coached in my facilitation skills was very valuable for me, and the participants seemed to appreciate learning more about the coding dojo format I use.

It turned out that Johannes and I weren’t the only technically-focused people there, and we shared lots of ideas about code katas and teaching TDD. Everyone agreed that success with agile needs developers to change the way they work, and most struggle with TDD. “Parachuting” a trainer in for a couple of days might help developers understand they could work differently, but getting them to actually make changes is much harder. I’m hoping for some success with repeated regular coding dojo sessions with a team. I’ll have to report back when I have more experience of actually doing this.

Another highlight was discussing using games for teaching agile, and in particular teaching agile engineering practices. Jon Jagger has his “cyber-dojo” collaborative programming game that he has released open source, and a “Kanban 1’s game” which he uses for teaching teams about limiting work in progress, and keeping work items small. We talked about the fact that many games are released under the creative commons attribution license, and coaches share them with each other. The games in themselves may take time and effort to create, but Jon and many of the other coaches there felt they don’t lose by sharing them, quite the opposite. They get feedback from others and help to improve the games. I wondered if they were worried about losing business to cheaper rivals who just took their materials, but people seemed confident that the skill of the facilitator is so crucial in the success of a game in achieving learning goals for the participants, that they would not lose out.

It was an intense weekend, with a couple of lovely walks in the snow, and good food together with interesting company. I learnt a lot about coaching and made new friends. I’ll be looking out for similar conferences in future 🙂

The world need more and better programmers. Jason Gorman recently wrote this post encouraging people to start offering software apprenticeships, as an alternative to computer science degrees.

He writes:

“our computing education in [the UK] is preparing students for a career in a version of computing most of us don’t recognise. Students devote the majority of their time learning theory and skills that they almost certainly won’t be applying when they get their first proper job. Computing schools are hopelessly out of touch with the reality of computing in the real world. While employers clamour for TDD or refactoring skills, academics turn their noses up at them and focus on things like formal specification and executable UML and compiler design, along with outdated and thoroughly discredited “software engineering” processes.” — Jason Gorman

Jason ends his post with a call to arms – if you’re a good software developer, get yourself an apprentice, and start training them. It’s the same message I heard from Dave Hoover when he visited Göteborg recently. I think he also sees a multi-year apprenticeship as a better alternative for training programmers than a computer science degree.

I also recently came across this article, written by a computer science teacher in the US, with the following paragraph:

“I no longer teach programming by teaching the features of the language and asking the students for original compositions in the language. Instead I give them programs that work and ask them to change their behavior. I give them programs that do not work and ask them to repair them. I give them programs and ask them to decompose them. I give them executables and ask them for source, un-commented source and ask for the comments, description, or specification. I let them learn the language the same way that they learned their first language. All tools, tactics and strategies are legitimate. ” — William Hugh Murray

So clearly some academics are teaching in creative ways. Rather than abandoning computer science degrees, might it not be better to improve their content?

One of the things about the XP conference is that it brings together industry and academics, and lets them hear from one another. How to teach programming is a very important topic that is often discussed there. XP2005 for example was held at Sheffield university, where I remember chatting to one of the professors, and being impressed by the way they used eXtreme Programming as part of their undergraduate course.

Another thing that happened at XP2005 was the first coding dojo I attended, and I believe the first one ever held outside of France. It was presented by Laurent Bossavit and Emmanuel Gaillot, founders of the Paris dojo. I was excited to discover a context in which I could improve my practical programming skills, in regular short bursts, alongside a continuing paid job.

So one of the things I do in my new life as an agile testing consultant is to use the coding dojo format to teach people how to program better. We’ll do code kata exercises and practice Test Driven Development, Refactoring, and discuss what Clean Code looks like. So far the reaction from professionals I’ve done this with has been very positive. Lots of people who have been coding for years appreciate the chance to learn new practical skills.

I’m also getting involved in more formal education, this spring I’m teaching a three week course in automated testing, as part of a “Kvalificerad Yyrkesutbildning” in software testing. This is a one year full time course for students wanting to learn a practical skill, as an alternative to going to university and studying a more academic subject. In Sweden you can get a student loan while you’re studying this course, and part of the time is spent working in a company gaining on-the-job experience.

I’m starting to plan how I’m going to teach TDD, BDD, and how to use tools like Selenium, Fitnesse, TextTest and Cucumber. I think it’s going to be very hands on and practical, but also go into the general principles behind tool choice and writing maintainable automated tests. I’m helping to write a formal syllabus and exam, with criteria for grades awarded.

I guess what I’m trying to say is that I don’t like this strand of thought in the Software Craftsmanship movement that wants to abandon formal education. There are lots of ways to train software developers, and apprenticeship isn’t without its problems.

I think this is just the sort of thing we’ll be discussing at XP2011, where there will be a host of academics and experts from industry. Won’t you join us?