Coding Is Like Cooking

This article was first published on ProAgile’s blog

With good facilitation, one hour is just long enough for a group to both create an agenda and have some interesting conversations on topics they’re concerned about. We at ProAgile have been holding these kinds of meetings regularly both before and after everything went online in 2020. We’ve found it’s a great way to create community in a world of remote work, and make connections with people beyond our usual collaborators. 

Most people can find an hour in their schedule so it’s easier to attend than something longer like a workshop or conference. The trick is to have really good facilitation so you can get a lot of value from a short amount of time together. This post explains our secrets for a successful online one hour open space.

The invitation

When you invite people to your meeting, give the starting time of the hour, but explain that the video call will be open up to 15 minutes before that for casual discussions. Those additional minutes mean anyone who is unsure of their video setup or who doesn’t know you very well can feel comfortable turning up early and getting some help. It’s a chance for the facilitator to greet people and welcome them before the formal part kicks off.

We don’t spread the meeting invitation link on social media, we only send it to the people who have signed up for the meeting. So far we haven’t had a problem with strangers disrupting our meetings with unwanted content.

The Technology

We use Zoom for our meetings because it has the functionality we need for participants to move freely between breakout rooms. We have also previously used QiqoChat before Zoom had that functionality. (QiqoChat can help bring similar functionality to Teams or Google Meet.) We also use Miro as a collaboration tool for creating the agenda and communicating with one another during the meeting.

The Welcome and Introduction

Time: 2 minutes

Be sure to greet everyone warmly when the official meeting time begins. Make it clear everyone is included, and that together we are going to have some great discussions. We know that because everyone will take part in deciding what topics we will talk about. If the agenda doesn’t seem interesting then you can fix that!

Remind people to put the name they want to be called by in their Zoom window, and to keep their camera and microphone switched on as much as possible. Give out the link to the Miro board (paste it into the chat).

In order for other people to find out about future open space meetings, you may want to post about this one on social media. A picture of the current meeting could be a good addition to that post. Before taking a screenshot of the zoom meeting, warn people that you’re about to do that. If they don’t want their own image to appear, tell them to turn their camera off for a minute while you take the screenshot. Be sure to edit the image to blank out the names of people without their cameras on before you post the picture.

The Sponsor Slot

Time: 1-2 minutes

If your meeting has a sponsor, give them 1-2 minutes to explain who they are and advertise what they want to advertise. Make sure they keep it short and to the point. Thank them for their sponsorship.

The Open Space Technology explanation

Time: 2 minutes

It’s always good to be reminded of how Open Space is supposed to work, however many times you’ve taken part before, and of course it’s essential to introduce newcomers in a good way. Keep this part brief and to the point.

Ask people to assume that everyone here is a really interesting person with lots to share about topics you care about. Every individual who comes to your discussion is the right person. Take time to both talk and listen. Keep the conversation flowing and don’t let any one person dominate.

Explain that it is absolutely fine to switch rooms and join a different discussion group at any time. If you find you’re not learning or contributing anything, take a look at the agenda and just move somewhere else. In Open Space-speak, this is called “the law of two feet”. Note that there are some instructions on the miro board about how to switch breakout rooms if you are unsure how to do that.

Often a conversation benefits from having someone take notes on the Miro board. It’s a way to allow others to get an insight into what you talked about, and to help you remember and follow up on what is said. Encourage people to volunteer to be a note-taker for their room. 

The Agenda

Time: 7 minutes

We find the ideas for agenda items really start to flow when you put people in smaller groups and ask them to write sticky notes together. We create random breakout rooms for 2-3 people and give people the instruction to talk about their agenda suggestions for today. You may want to prompt this with questions like: “What’s challenging at work? What’s a great insight you want to share or get feedback on? What’s a great book you’ve read, and learned something from?”

Ask people to write their topics on sticky notes on the shared miro board on the agenda frame.

The breakout rooms are open for only 5 minutes, we set a timer on the miro board. Hopefully a bunch of notes will now appear on the agenda. When everyone is back, encourage them to move the notes around and create the agenda they want to see.

We don’t normally ask everyone to present their topics, we find it’s enough for people to just read what’s on the notes. If any notes are particularly unclear you could ask for a short explanation from the author at this point. 

Sometimes people want to suggest merging the discussion of two topics. That can be a good idea but it can also take longer to decide to merge the topics than is worth it. Don’t cut people off unnecessarily but you need to keep this part short.

Before you send people off to the discussions, again remind them to be friendly and to assume everyone has something interesting to say. Point out if there are too many people in one room for comfortable conversation they could self-organise and split the group across two rooms instead. 

The Discussions

Time: 17 minutes discussion + 3 minutes between sessions + 17 minutes discussion

Open the planned number of breakout rooms with the options “Let participants choose room” and “let participants change room”. Ask everyone to join whichever discussion they want to. Explain you will not close the breakout rooms between the two discussion slots, people can just move on to the new rooms when the timer has pinged and their first discussion draws to a close.

The room numbers for the second discussion are distinct from the first ones. This is so that the second discussions can get going on time and don’t need to wait for the first discussions to end. This means you actually have twice as many breakout rooms open as there are planned discussion slots.

Set a timer on the miro board which will go off when the time is up for the first discussion. 

There is a frame on the miro board where people can share useful information and links to things that come up during the discussions. (You can also use the zoom chat for this but then only people in your breakout room get the link.)

The Takeaways

Time: 7 minutes

At the end of the second discussion slot, close the breakout rooms so everyone comes back to the main room. Take the opportunity to thank everyone for the discussions you’ve had and point out everyone has surely learnt something new or been reminded of something useful today. They probably have ideas they should try out now. Point people at the frame on the miro board for takeaways:

We find people are better at identifying their takeaways when talking in smaller groups, so create new random breakout rooms with 2-3 people in and give people the instruction to talk about what they are taking away from today’s discussions. The priority is to talk – writing a note on the miro board is a bonus for the rest of us and it might also help you remember what you said.

Keep those rooms open for only 5 minutes, set a timer on the miro board. When everyone comes back, thank them again and declare the open space over for today. You might mention if there is another one planned and if so, how to find out about it.

The After Party

Time: up to 15 minutes

Don’t close the zoom meeting immediately, leave it open for perhaps 10-15 minutes in case anyone wants to hang around and ask the organisers or sponsors anything in particular. People might want to exchange contact details and continue their discussions in another forum. You could open some more breakout rooms to allow small groups to “end” a conversation, share contact details, etc. 

I am convinced that the world needs more technical coaches. Practices like Refactoring and Test-Driven Development don’t just happen by themselves. It takes quite an investment in time and effort for most developers to see the point, and to realize how much it would help them to work this way. Then they need to put in some time and effort to become proficient using these skills, and a supportive team culture is essential. Having an experienced technical coach on hand can make all the difference for success. 

During 2021 one of the teams I coached was struggling to make progress in a large, complex codebase. We worked together in an ensemble which enabled them to pool their knowledge and get a grip on the code faster than before. We held several learning hours focused on test design which helped them to improve the unit tests and get better feedback on their changes. Everyone said afterwards they felt like working with the coach had helped them to work more effectively. I’d like more teams to experience this kind of progress. 

Samman is the method I use when I’m coaching software development teams. The two basic components are ensemble working – where you gather the whole team to work together on one programming task – and learning hours – where developers learn new skills and practice on exercises. 

I published my book “Technical Agile Coaching with the Samman method” in January 2021, because I wanted to help other technical coaches to use this coaching method and to promote agile ways of working. When I held this book in my hand for the first time it was somehow larger and heavier than I expected. I felt a huge sense of accomplishment! Since then, I’ve more and more realized the book was just the beginning. There are a lot of development teams out there and only a few technical coaches who really know how to help them.

The book generated quite a bit of interest and I’ve spent a large part of last year talking and writing even more. I was asked to contribute articles about Samman coaching for some of the biggest online magazines in our industry – Methods and Tools and InfoQ. I also had a steady stream of invitations to appear on podcasts. I just went through and counted them – eight were published in 2021! (I list them at the end of this article)

I was invited to give the keynote address to the ACCU conference. It’s always a huge honour to give a keynote and I spent many hours preparing this talk. For the second time in my career I was also invited to speak at the annual Agile conference organized by the Agile Alliance. It’s one of the biggest conferences in the software world – also a great honour to be asked to speak there.

For most of my career I’ve been part of the Agile, XP, DevOps, Testing, Python and Java communities within software development. Although I have previously done a fair amount of architecture work, this year I feel I also took a step into the Architecture community for the first time. I was invited by O’Reilly to be a judge in their Architectural Katas competitions. I see technical coaching as one aspect of the kind of technical leadership that architects usually bring in an organization. Through this competition, architects from all kinds of organizations can practice their skills and learn from each other. I’m really happy to have been involved.

Looking forward to 2022, I’m anticipating another year of hard work doing technical coaching with teams, but also more and more training others to do coaching. I’m getting a lot of enquiries from organizations who see a need for better technical practices. My colleagues and I have only so much time available to coach teams, so I usually suggest pair-coaching with people already in the organization. Most organizations already have architects and technical leaders and often those people would like to learn to coach teams using the Samman method. It’s for that reason that we’re ramping up the train-the-trainer programme offered by ProAgile. We have new courses on Ensemble Working and also on Learning Hour Design, two of the key activities for a technical coach using the Samman method.

I remain convinced that good technical coaching is essential for building up productive and happy development teams. I look forward to continuing to spread better ways of working and coding together with lots of great people in 2022. Happy new year!

Podcast appearances 2021:

• DevOps Sauna – a lovely chat with Sofus Albertsen, a former colleague of mine.
• Richard Kasperowski – we talked more about music than software I think!
• Mob Mentality Show – Chris Lucian and Austin Chadwick were really friendly and easy to talk to.
• Mosaic Works – Alex Bolboaca really knows his stuff and how to interview people
• That Tech Show – I was really pleased to appear on this one which has such a varied lineup.
• Arrested DevOps – Matt Stratton is a busy man, heavily invested in the DevOps community. Great to talk to him.
• Maintainable – the theme of this podcast is making existing software more maintainable, something I can really get behind.
• Making Tech Better – Clare Sudbury got me talking about Refactoring – a really important topic. 

I was in Finland recently, at the European Testing Conference. I both attended the conference and presented a workshop about “Approval testing with TextTest“. I won’t say any more about that, since Ben Linders did a brilliant write-up already that was published on InfoQ. There were several other highlights, and I wanted to just share a paragraph or so about each.

Mob Testing is what happens when your development team decides to work together on testing tasks as a Mob. I took part in a workshop where Maaret Pyhäjärvi facilitated two different mobbing exercises, one where we automated some UI tests using Selenium, and one where we practiced Test-Driven Development on the FizzBuzz kata. I have already done some Mob Programming and this felt very similar, except the focus was on developing tests rather than production code. It seems to have similar benefits – you have access to all the knowledge of everyone in the team, and you can learn things you didn’t even know to ask about. It makes pairing seem like a slow way to share good working practices.

JUnit 5 is on the horizon, and has several useful improvements over the previous version. Generally the syntax clutter is reduced, and the way you create parameterized tests has been overhauled. The most significant change though, (especially for people like me who work on developing other testing tools), seems to be that they’re designing the test-running engine to be separated so you can re-use it to run other kinds of tests. Any infrastructure that works with JUnit will then be able to run these other tests as well. In principle it opens up JUnit’s success as a platform, to be re-used by other test frameworks. Thanks Nicolai Parlog for this useful summary of the next generation of one of the most widely-used tools in the Java world.

Joel Hynoski has worked at many of the tech giants in our industry, including Google, Twitter, Apple, and now Lyft. He spoke about some of the engineering challenges they had overcome, specifically in the area of testing. One thing I liked was their tool that detects flaky tests, and puts them in ‘jail’. (A flaky test is one that sometimes passes and sometimes fails, when run against the same code. They are a pain and can be a huge waste of time.) When a test is in ‘jail’, that means it’s no longer run in the build pipeline, so it doesn’t block new releases. It instead gets flagged as needing maintenance. They then have a SLA that says how long a test is allowed to remain in jail before an engineer needs to look at it and fix the flakyness – a day or two I think.

I can feel a little in awe of someone who has worked in those kinds of famous engineering organizations, working at web-scale with some of the best developers in our industry. What I found most encouraging about talking to Joel, was that he was very down to earth about the problems these organizations face. They still battle with legacy code, despite it often only being a few years old. They have trouble creating reliable automated tests. The developers don’t always trust the test automation. They still have production bugs and hotfixes…

Alex Schladebeck spent the first ten minutes of her presentation giving a splendid rant about the bad reputation of UI testing. To summarize: (criticisms she hears about UI tests -> her responses)

UI tests give slow feedback -> and valuable feedback, doesn’t have to be after every build
need more infrastructure/machines -> yes, deal with it
they’re the top of the test pyramid -> they are in the pyramid! you can’t ignore them. They find different stuff than unit tests. Consider your context.
they’re flaky -> they’re not as bad as they used to be! Could be your app isn’t designed for testabilty? Could be your test design is poor?
they cause lots of work when small changes in your app -> that happens in development work too! Also, happens more if you design them badly.

She then went on to give some excellent advice about how to design your UI tests. It was mostly about layering your test code in different levels of abstraction, and getting a good collaboration going between developers and testing specialists.

Conferences are about meeting people and the organizers of this conference had very deliberately scheduled sessions to encourage this. We had a ‘speed dating’ session where you talk to about 8 random people for five minutes each. We had a ‘lean coffee’ session, where all the speakers were each asked to facilitate a discussion table. I thought this worked particularly well as a way to find people with similar interests, and get them to talk about their experiences. The hands-on workshops were all at the same time, so you had to go to one and not just attend talks all the time. There was also an open space scheduled when it would not clash with any other kinds of sessions. I thought all this together made for a pretty welcoming conference where you were bound to get to know new people.

Overall I had a really good time at this conference and I’d recommend it to both testers and developers with a strong quality focus.

I forget exactly when, but I think it was 2008 or 2009. Anyway, I was at a software conference, and I was chatting with a developer after one of the sessions about cool new technologies and stuff. I don’t remember what hot new thing it was we talked about, all I remember, is the shoes he was wearing!

This is rather an unusual style of running shoe. At the time, I’d never seen any like this before, and I was intrigued. It turns out that this developer I was talking to was, like me, also something of a serial early adopter, it’s just that he not only picked up shiny new programming tools and technologies.

At the time, I was running in a pair of shoes with thick heel padding the shop assistant had assured me would correct my bad posture and foot “pronation”. This guy’s “five finger” shoes had none of that, in fact quite the opposite. I was looking at disruptive running technology.

The conversation quickly switched from the latest programming tools and frameworks, as this guy explained the essential benefits of his shoes:

• Lightweight
• Your toes can spread out, giving better push-off from the ground
• Thin sole – you adapt your stride to the surface because you can feel it
• No heel padding, means you strike the ground with the whole foot simultaneously.

And of course, most importantly for a technology enthusiast:

• People stare at you feet!

Following this conversation, a little googling about and watching the odd video by a “running style expert”, I became convinced. To be honest, it wasn’t much contest – shiny new technology, being in with the cool kids – I bought some new shoes, with toes and everything!

It took me several weeks to get used to them. You have to start with short distances, build up some new muscles in your foot, and learn to strike the ground with the whole foot at once. In my old shoes, I had a tendency to strike heel-first, because of the huge wad of padding on the sole, but in these minimal shoes, that just hurt. It was useful feedback, the whole-foot-at-once gait is supposed to be better for your knees.

After a few weeks of running shorter distances, slower than before, I gradually found my stride, and really started to enjoy running my usual 7km circuit of the local forest, in my eye-catching five-fingered shoes.
Unfortunately it didn’t last. Maybe two or three months later something happened. I think the technical term for it is Swedish Autumn. It turns out that forest tracks gain a surprising number of cold, muddy puddles at that time of year! Shoes with a very thin sole that isolate and surround each individual toe in waterlogged fabric, mean absolutely freezing feet 🙁

So I’m back on the internet, looking for new, shiny technology to fix this problem, and of course, I buy some new shoes. This time I got a pair of minimalist shoes in waterproof goretex, with basically all the features of my old shoes, minus the individual toes.

I was back out on the forest track, faster than ever, with dry, comfortable feet – win! The only problem was, people were no longer staring at my eye-catching toes. So you can’t have it all!

So this is normally a blog about programming. What’s going on?

Test Driven Development as a Disruptive Technology

I’ve been thinking about this, and it seems to me that as with running shoes that have toes, TDD is something of a disruptive technology. Just as I haven’t seen the majority of runners switch to shoes with toes, I also havn’t seen the majority of developers using TDD yet. Neither seem to have crossed Geoffrey Moore’s “chasm”.

Lots of developers write unit tests, but I think that’s slightly different. I’m talking about a TDD where developers primarily use tests to inform and direct design decisions, and rely on them for minute-by-minute feedback as they work. In 2009, Kent Beck made an observation in his blog that “the data suggests that there are at most a few thousand Java programmers actively practicing TDD”. I don’t think the situation is radically different today.

So can we learn anything about TDD from the story about running shoes? A couple of points I find relevant:

• Early adopters will try a new technology based on really very flimsy evidence, and will persevere with it, even if it slows them down in the short term.
• Early adopters like to look cool and stick out.

You may think that last point is just vanity, but actually, being a talking point helps drive adoption, but primarily amongst other, similarly minded technology geeks.

I remember a while back I was at work, writing some code, when a guy from another team came over to ask me something. He was about to leave, when he did a double-take and stared at my screen for a moment. “Are you doing TDD? I’ve never seen anyone actually do that in production code. Do you mind if I watch?”. So, you see, eye-catching shiny new technology, and I’m one of the cool kids, about to be emulated by the guy in the next team. 🙂

The other part of this story, is of course the compromise I made when the cool technology met the reality of a muddy Swedish forest track. The toes went, but the shoe I ended up with is still radically different from the one I had before. I think that for TDD to reach the mainstream, it may need to become a little less extreme, a little more practical – but without losing the essential benefits.

What are the essential benefits of TDD? Well, I would say something like this:

• Design: useful feedback, pushing you away from long methods and tightly-coupled classes, because they’re hard to test.
• Refactoring: quickly detecting regression when you make a mistake
• Productivity: helping you to manage complexity and work incrementally

So is it possible to get these things in another way? Without driving development minute-by-minute with tests? Well, that’s probably the subject of another blog post…

You might be interested to watch a video of my recent keynote speech at Europython, where I told this story.

I was recently at the Software Craftsmanship Conference at Bletchley Park in the UK. This is a one-day conference for software developers, attended by around 150 programmers. All proceeds from the event go to support Bletchley Park, which is of historical interest to programmers in particular – the site where Alan Turing and others cracked the enigma code in the 2nd world war. It was the fifth time this conference has been run, and the first time I attended. This is a short experience report.

In the morning I ran a workshop titled “Outside-In, with or without Mocks?“. We were about 50 people in the Ballroom in the Mansion, a very grand room, and it was really great to see so many people working in pairs at laptops, puzzling over some code and tests and how to do Test Driven Development. We were looking at a code kata I’ve designed called “Train Reservation“. It’s in no way a beginner exercise, and the crowd at Bletchley seemed to get on with it rather well on the whole. I’m just sorry I didn’t get round to talk to each pair very often, with 24 pairs I only had a couple of conversations with each during the 2 hour session!

I set up the exercise more or less to force people to use some kind of mock, fake or stub to replace the Booking Reference Service and the Train Data Service, because I am interested in how different people use these. I’ve observed that some programmers avoid using test doubles whenever possible, while others use them frequently. I’ve also observed that some people prefer to work outside-in, starting with a guiding test, while others prefer to start with the business rules at the heart of the problem and work outwards from there. At this particular workshop, there were all sorts of approaches being used. Some started with the guiding test and stubbed the services. Others started with the business logic around the seat selection rules. Different approaches, as I had hoped! Overall I feel encouraged that this exercise is a useful one, and people seemed to get on better with it than the last time I ran it, at XP2013. It’s till rather too big of a problem to tackle in a half day workshop though. I’ll be updating it some more before I run it again, although I don’t have any fixed plans for when that will be yet.

In the afternoon, I went to a session by Ivan Moore and Mike Hill, “Inheritance to Composition“. They gave us a demo of this particular refactoring using a very simple codebase, before launching us into a much more complex one – Fitnesse (starting from the branch “revised-ResponderFactory”). The idea was to take some classes that were using Inheritance – specifically the Template Method pattern – and convert them to instead use Composition – specifically the Strategy pattern. They also helpfully provided us with a sheet of instructions – 6 steps to complete the refactoring with minimal risk and code breakage.

My pair and I got on fairly well with the refactoring, and by the end of the session we were on step 5 with the goal in sight. The experience was of using Eclipse’s refactoring tools extensively, and relying a great deal on the compiler. The tests we had to lean on took a minute and a half to run, and actually, the tests for the classes we were working on were more mini-integration tests than unit tests as such. It meant there were relatively few updates to the tests as we did the refactoring, but the feedback loop was slow. I thought that was really interesting, and was wondering how the experience of the refactoring would change in a language like Python. There you don’t have a compiler, or very much help from refactoring tools.

So after the workshop, I set about trying to construct a similar problem in Python. Perhaps understandably, I didn’t want to translate the whole of Fitnesse to Python, (!), so I tried to re-write only the elements of it essential to this exercise. You can have a look at what I’ve come up with in my new repo “WikiSearchKata“. I’m still working on preparing this properly as an exercise, (the instructions are still rather thin), but I plan to try it out at a GothPy meeting sometime soon.

After the conference sessions had ended, we were treated to a guided tour of the National Museum of Computing which was for me, the highlight of the day! Our enthusiastic guide showed us all sorts of ancient computers and storage devices and punch cards… a few I recognized from my childhood. My dad used to bring home old punch cards and my mum used to write her shopping lists on them when she went to the supermarket. They had a 48K ZX spectrum with rubber keys – just the same as the one I wrote my first program on! They had a CRAY supercomputer similar to the one I remember seeing once when I visited my dad’s work as a child. It’s a similar size to (the outside view of) a Tardis, with a big red button on the front. I don’t think we found out what the red button does, but the guide did say we probably have more computing power in the smartphone in our pocket! I found the changes in storage capacity actually even more impressive. They had these washing-machine sized boxes and dinner-plate sized metal disks that together made a hard drive. I think it held something like 4K.

The highlight of the tour was the WITCH computer – the oldest working computer in the world. It was brilliant! You could actually see what it was doing while it read in a paper tape punched with holes – the program – and loaded values into registries and did calculations. It made this fantastic whirring noise as it ran, and has all these little whizzy flashing lights. It works in decimal rather than binary, so each number is represented by a little “dekatron” – a glass tube with a red light inside, that moves between positions 0-9 in a circle. So you can read which number is in the registry by looking at the position of each light in the array. They also had this little button you could press to make it step through the program one instruction at a time. I got to press it, and single-step a computer from 1951!

Compared with other conferences I’ve been too, this one was rather short, just one day, and with rather long sessions – half or whole day. It was hard work coding and facilitating all day, but in general very interesting people and coding exercises. A second day would have made it more worthwhile my making the trip. In any case, my thanks to Jon Dickinson for organizing it.