Coding Is Like Cooking

I’m speaking next week at ScanDev on Tour in Stockholm on the subject of “Software Development Craftsmanship”, and as part of my research I read both “The Clean Coder” by Robert C. Martin and “Apprenticeship Patterns” by Dave Hoover & Adewale Oshineye. These are very different books, but both aimed at less experienced software developers who want to learn about what it means to be a professional in the field. In this article I’d like to review them side by side. First some text from each preface on what the authors think the books are about:

Apprenticeship Patterns

“This book should help you through the tough decisions you face as a newcomer to the field of professional software development. “ (preface xi)

The Clean Coder

“This book is about software professionalism. It contains a lot of pragmatic advice” (preface xxii)

The Content
Both books contain a lot of personal stories and anecdotes from the authors’ careers, and begin with a short autobiography. Some of the advice is also similar. Both advise you to practice with “Kata” exercises, to read widely and to find suitable mentors. I think that’s mostly where the similarities end though.

Dave and Ade don’t say much about how to handle unreasonable managers imposing impossible deadlines. Bob Martin devotes a several chapters to this kind of issue, handling pressure, time management, estimation, making committments etc.

Dave and Ade talk more about how to get yourself into situations optimized for learning and progress in your career. They advise you to “Be the worst”, “Find mentors”, seek “Kindred Spirits”. In other words, join a team where you’re the least skilled but you’ll be taught, look for mentors in many places, and get involved in the community.

Bob talks about a lot of specific practices and has detailed advice. He mentions “… pairing is the most efficient way to solve a problem” (p164) Later in the chapter he suggests the optimal composition of job roles in a gelled team. (p169) He also has some advice about how to successfully argue with your boss and go over their head when necessary (p35).

The Advice
Those few example perhaps illustrate that these two books are miles apart when it comes to writing style, approach and world view. Dave&Ade have clearly spent a lot of time talking with other professionals about their material, acting on feedback and testing their ideas for validity in real situations. The book is highly collaborative and while full of advice, is not prescriptive.

Bob Martin on the other hand loves to be specific, provocative and extreme in his advice. “QA should find nothing.”(p114) “You should plan on working 60 hours per week.” (p16) “Avoid the Zone.” (p62) “The jury is in! … TDD works” (p79) These are some of his more suprising pieces of advice, which I think are actually fairly doubtful propositions when taken to extremes like this. Mixed in are more reasonable statements. “You do not have to attend every meeting to which you are invited” (p123) “The professional developer is calm and decisive under pressure”. (p150)

The way everything is presented as black-and-white, do-or-do-not-there-is-no-try is actually pretty wearing after a while. He does it to try to make you think, as a rhetorical device, to promote healthy discussion. I think it all too easily leads the reader to throw the baby out with the bathwater. I can’t accept one of his recommendations, so I throw them all out.

Some of Dave&Ade’s advice is actually just as hard to put into practice. Each of their patterns is followed by a call to action. Things like re-implementing a program you’ve written in an imperative language in a functional language (p21). Join or start a user group (p65). Solve the same coding exercise once a week for the next four weeks (p79). None of these things is particularly easy to do, but they seem to me to be interesting and useful challenges.


Collaboration
Bob has also clearly not collaborated very widely when preparing his material. One part that particularly sticks out for me is a footnote on page 75:

“I had a wonderful conversation with @desi (Desi McAdam, founder of DevChix) about what motivates women programmers. I told her that when I got a program working, it was like slaying the great beast. She told me that for her and other women she had spoken to, the act of writing code was an act of nurturing creation.” (footnote, p75)

Has he ever actually run his “programming is slaying a great beast” thing past any other male programmers? Let me qualify that – non-fantasy-role-playing male programmers? Thought not. This is in enormous contrast to Dave&Ade, whose book is full of stories from other people backing up their claims.

Stories
Bob’s book is full of stories from his own career, and he is very honest and open about his failures. This is a very brave thing to do, and I have a great deal of respect for him for doing so. It’s also really interesting to hear about the history of what life was like when computers filled a room and people used punch cards to program them. Dave&Ades stories are less compelling and not always as well written.

Bob’s book is not just about his professional life, he shares his likes and dislikes. He reccommends cycling or walking to recharge your energy, or “focus-manna” as he calls it, (p127). Reading science fiction as a cure for writer’s block. (p66) Listening to “The Wall” while coding could be bad for your design. (p63) When describing “Master” programmers he likens them to Scotty from Star Trek. (p182)

All this is very cute and gives you a more rounded picture of what software professionalism is about. Maybe. Actually it really puts me off the idea. I know a lot of software developers like science fiction and fantasy role playing, but it really isn’t mandatory. He usually says that you may have other preferences, and you don’t have to do like he does, but I just don’t think it helps all that much. The rest of the book is highly dogmatic about what you should and shouldn’t do, and it kind of rubs off.

Conclusions
The bottom line is, I wouldn’t reccommend “The Clean Coder” to any young inexperienced software developer, particularly not if she were a woman. There is too much of it written from a foreign culture, in a demanding tone, propounding overly extreme behaviour. The interesting stories and good pieces of advice are drowned out.

On the other hand, I would recommend “Apprenticeship Patterns”. I think it is humbly written and anchored in real experience from a range of people. I agree with them when they say you need to read it twice to understand it. The first time to get an overview, the second time to understand how the patterns connect. It’s not as easy to read as it might be. But still, I think the content is interesting, and it gives a good introduction to what being a professional software craftsman is about, and how to get there.

This weekend I was in Stockholm to facilitate a Code Retreat, organized by Peter Lind and sponsored by Valtech. We were about 40 coders gathered in the warm autumn sunshine early on a Saturday morning at Valtech’s offices. (Do take a look at Peter’s blog post about it, he has a photo too).

It’s actually the first time I’ve even attended a code retreat, let alone facilitated, but I think it went pretty well. Corey Haines has written extensively about what should happen, and what the facilitator should do. I think he’s given a great gift to the community, not just by inventing the format, but also by documenting it thorougly.  I’ve previously led various coding dojos and “clean code day” events, but code retreat is somewhat different in format, if not in aim.

The reason for going to a code retreat is to practice your coding skills. By repeating the same exercise over and over, with different pairing partners, you have a chance to work on your coding habits. Do you pay attention to what your tests are telling you about your design? Do you remember to refactor regularly? Can you take really small steps when you need to?

For the day in Stockholm, we followed the tried and tested formula for a code retreat that Corey has laid out. I spent about 20 minutes introducing the day, the aims and the coding problem (Conway’s Game of Life). Then we did 6 coding sessions, each with a short retrospective, and a longer retrospective at the end of the day. Each session comprised 45 minutes coding in pairs, 10 minutes retrospective in groups of 6-8, and 5 minutes to swap partners. I also began each coding session by reminding everyone of what we were supposed to be practicing, and highlighted a different “challenge” to add some variety. The challenges were things like:

– concentrate on writing really beautiful code so the language looks like it was made for the problem. *
– partition code at different levels of abstraction. **
– Think about TDD in terms of states and moves.
– do TDD as if you meant it
– concentrate on refactoring in very small steps

Each pairing session is just 45 minutes, and in that time you don’t actually have time to really solve the whole kata, and that’s actually quite difficult to cope with. Most coders are very motivated by writing code that does something useful, and like to show off their finished designs at the end. To try to prevent that, Corey emphasizes that you should keep in mind the end result isn’t important, and be sure to delete the code at the end of the session. I found that even with that rule, there was quite a lot of discussion of how the designs ended up, and some people even saved their code.

One of the things I encouraged people to try was working in an unfamiliar programming language, and although I specified “for 1 or 2 sessions”, I was surprised to find how popular it was to do this. After the first session when most people used Java, C#, Ruby or Python, there were more and more people coding in Clojure, Javascript, Erlang and even Vim script. I think it got a bit out of hand actually. It’s hard to practice your coding habits and TDD skills when you’re struggling with the language syntax and how to get the tests to run. Next time I facilitate I’ll try to be clearer about using a familiar environment for most of the sessions.

One of the things I offered in the last session was using the cyberdojo, and three pairs agreed to try it. I had them working in Java and Ruby, switching pairs every 5 minutes, coding in a browser window. They complained about the browser experience compared with their IDEs, but they liked the feedback cyberdojo gives you. It shows how long you spend between running the tests, and whether the tests pass, fail or give a compiler error.

I’m not sure if it was a good idea to bring in the cyberdojo at the code retreat. One of the main things we discussed in the retrospective for that session was the resistance they all felt to changing the first test that was written at one of the three pairing stations. This test was too big and focussed on a boring part of the problem. Yet each person who “inherited” the code tried their best to make it pass, no-one started over with a better test. It’s that kind of collaboration problem that the cyberdojo is good at highlighting. It’s not so much a tool for improving your coding skills as improving your collaboration skills. This is good, but not really the purpose of the code retreat.

Thinking back over the day, I’ve also become a little uncertain about the “delete your code” rule. I understand why it’s there, but it didn’t seem to prevent people from trying to solve the whole problem in 45 minutes. By deleting the code, you also lose the opportunity to use analysis tools like those in the cyberdojo to give you some more feedback on how you’re doing.

Outside of this code retreat, I’ve been trying out the codersdojo client quite a bit recently, to see if it gives a useful analysis of a coding session. Unlike cyberdojo, it lets you use your normal coding tools/IDE. So far it’s still in beta testing and seems too buggy for me to recommend, but if you’re lucky enough to successfully upload your coding session, you do get quite a good visualization of some of your coding habits. It will clearly show if you spend a long time between test runs, or if you spend a lot of time with failing tests.

So after my first code retreat, I’m feeling very encouraged that this is a good format for becoming a better coder, and I’d be happy to run one again. I’d like to try using coding visualization tools as part of the retrospective for each session. I’d also like to try setting the challenges before people have chosen a pairing partner, so they can find someone who also wants to work on my challenge rather than just try a new language. Or maybe I just need to emphasize more that trying a new language isn’t the focus of the day.

In any case, I hope this blog post shows that I learnt a lot from facilitating this code retreat, even if I didn’t write a single line of code myself 🙂

* “You can call it beautiful code when the code also makes it look like the language was made for the problem” — Ward Cunningham quoted in “Clean Code” by Bob Martin.
** G6: Code at Wrong Level of Abstraction – advice from “Clean Code” by Bob Martin.

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 🙂

A little while ago, Fredrik Wendt and I put together a little survey and sent it to all the people we know who have attended coding dojo meetings here in Göteborg. There are several groups in the city which run these kinds of meetings from time to time. We wanted to know what kinds of things people are learning from practicing code katas in a group, and get some feedback and comments to help us to develop the groups we run.

The survey got 29 responses – thankyou to everyone who participated! I was very encouraged to see that the overwhelming majority – 90% – said they would recommend the dojo to other people who wanted to improve their programming skills. There were lots of comments too – I won’t include them all – but I particularly liked:

Fredrik and I set up JDojo@Gbg about a year ago, as an free coding dojo for Java programmers, sponsored by Iptor. We advertized it as a taught course – 5 sessions, once a month, come and learn TDD. We ran it twice together, and now Fredrik is continuing it together with Ola Berg.

The second sort of coding dojo going on in the town is various language user groups. It must be four years since I pestered Niclas Nilsson and CJ that we should do code Katas at Got.rb (Göteborg Ruby User Group). Inspired by the success of that group, and together with Andrew Dalke and Johan Lindberg, I set up GothPy (Gothenburg Python User Group) about two years ago. More recently, Jonas Nicklas set up Got.js (Göteborg javascript user group) and Jörgen Lundberg set up Scala Geats (Göteborg Scalaenthusiaster). So there are several small, language specific groups that meet and do dojo evenings occasionally, interspersed with other activities.

The third kind of coding dojo meetings going on is where people run them internally at their employer, which lots of people do from time to time. In addition, Fredrik and I are both facilitating these kinds of groups at clients, as part of our work coaching teams and encouraging them to be more agile.

I was pleased that people from all these sorts of groups filled in the survey, and that many people had been to more than one kind.

Most of the survey respondents had been to 4 or 5 dojo meetings:

We asked several questions about perceived skill level before and after participation in dojo meetings. We wanted to know what people thought they were learning, basically.

As you can see, people were fairly good at the programming language in question before the dojo(s), and only reported marginal improvements, 0.3 on average, on a five point scale.

When it comes to the IDE used in the dojo, again, we are looking at a modest improvement, also 0.3 on a five point scale.

Using Mock Objects is a topic that doesn’t always come up in dojo meetings, I personally have certainly had more of a focus on classic TDD. The feedback shows that people didn’t feel they were that good at it before the meetings, and not that much better afterwards – an average 0.5 increase on a 5 point scale. From some of the comments, I think this is an area to focus on more in future. To that end, we’re having a GothPy meeting next week looking at Mockist TDD 🙂

Refactoring is an essential part of Test Driven Development, and in fact any modern programmer’s toolbox. I was pleased to see that people thought the dojo had helped them to improve this skill too – 0.5 on a five point scale.

So it looks like going to a dojo encourages you to write unit tests more often – 0.6 (on a five point scale) more often on average.

This result is the most pleasing to me, since I think TDD is such an important skill, and it can be so difficult to get going with. People are moving from a low level of skill up to a medium level of skill – a whole 1 point (on a five point scale) on average! No-one is claiming to be a TDD expert yet though, I will have to repeat the survey in a few years and see if anyone is brave enough to claim that by then 😉

Fredrik and I are off to Agile Testing Days in a week or so, where we’ll be presenting a bit about what we’ve been doing at these various groups, and what we recommend for others starting their own coding dojos. We’ve learnt a lot by running these meetings, and had fun too. Hopefully these survey results might encourage you to find a coding dojo and improve your programming skills!