Sometimes I need to do this:

unless enough_widgets?
  make_more_widgets
end

Which is all well and good, until I start letting two or more of these codes run in parallel. If you’ve never thought about this before, what can happen is something nasty called a race condition, where two or more processes (or threads) simultaneously check #enough_widgets?, and simultaneously both decide that they need to go and #make_more_widgets. With multiple processes now making more widgets, we end up with too many.

The solution is to lock this critical section of code so that only one process could ever run it at once - everyone else has to queue up and wait their turn. That way each check for #enough_widgets? will return an answer that’s accurate. In a single process with threads, this is achieved using the Mutex class, but when you run multiple processes in parallel, across multiple machines, you need something more. You need MegaMutex.

How

Suppose you have a WidgetMaker:

class WidgetMaker
  include MegaMutex
 
  def ensure_just_enough_things  
    with_distributed_mutex("WidgetMaker Mutex ID") do
      unless enough_widgets?
        make_more_widgets
      end
    end
  end
end

Now, thanks to the magic of MegaMutex, you can be sure that all processes trying to run this code will wait their turn, so each one will have the chance to make exactly the right number of widgets without anyone else poking their nose in.

Configuration

MegaMutex uses memcache-client to store the mutex, so your infrastructure must be set up to use memcache servers.

By default, MegaMutex will attempt to connect to a memcache on the local machine, but you can configure any number of servers like so:

MegaMutex.configure do |config|
  config.memcache_servers = ['mc1', 'mc2']
end

Installation

sudo gem install mega_mutex

Hacking

[http://github.com/songkick/mega_mutex](http://github.com/songkick/mega_mutex)

I had the chance to run a 90 minute session at this year’s Agile Conference in Chicago. The conference as a whole was an terrific experience but here I’d like to talk about my session, and what I learned from it.

The session focusses on the barriers that prevent people from adopting pair programming. I’ve encountered a whole variety of reasons for this in different teams I’ve worked on, and the first part of the session involved the participants working in groups to talk about specific characters I’d created who exhibit some of these problems.

We used these discussions as a catalyst to look over the general set of issues that can be a barrier to people’s adoption of pairing. We then went on to talk about tips and tricks for tackling these issues, but I’ll save those for another post.

Here’s what we came up with.

Issues

Lack of Feedback Within the Team

Trying out a radical new practice like pair programming can feel pretty disruptive to some people. It’s important when a team is going though such volatile changes that they get plenty of opportunities to feed back to one another about how it’s going. It’s also important that they recognise the benefits that pairing can bring for them. Offering pairing as a solution to a problem that the team has identified for itself will make for much more enthusiastic adoption than simply mandating it as a necessary agile practice.

Lack of Management / Team Approval of Pairing as a Valuable Practice

Again, if the team doesn’t recognise that pairing will help them, they’re unlikely to really give it an enthusiastic - and therefore successful - shot. More importantly, if management isn’t actively encouraging teams to try the practice out, it’s likely that at least some of the team will be reluctant to try it for fear of displeasing their boss.

Lack of Trust in Team from Management

The benefits of pairing are counter intuitive: two people working together are actually much more than twice as productive as if they were coding solo, yet this is not obvious to the causal or cynical observer. Management don’t necessarily need to understand this, but they certainly need to make the team feel trusted to make their own decisions about whether the practice can make them more effective. If the team don’t feel trusted by their management, they’re unlikely to try out a practice that can seem mysterious and even frightening to the uninitiated.

Lack of Trust Between Team Members

Pair programming brings people much closer together than they might normally have to be in a work situation. Thoughts and opinions are shared in rapid succession about quite subjective issues. It’s important that team members trust each other in order that they can settle in to this new level of intimacy.

Lack of Respect for Cultural / Gender Differences

Again, the level of intimacy between team members that paring demands can cause problems when people fail to consider one another’s backgrounds. Different people have different needs for personal space, for example. People with an intense need for personal space may be put off pairing simply by the idea of having someone sitting in such close proximity to them. Pairing that person with someone who is from a very tactile culture can be a disaster! It’s important to respect and work around these kind of issues as they are usually deep seated and cannot be simply rationalised away.

Need the Right Incentives

Often team members, especially from organisations used to a more traditional way of working, can be given incentives that don’t make paring the obvious choice. If people tend to be singled out for praise for delivering a particular feature, for example, it’s likely that they will be keen to own features by themselves so that they can take all the credit.

Lack of Experience at Pairing

There are some basic protocols that make pairing work effectively - talking about what you’re doing; swapping the keyboard when a new test is written or a test passes for the first time; taking regular breaks - but these are tricks that people tend to have learned though experience. On a team full of people who have never tried pairing before, you can expect some fairly basic mistakes to be made that may make pairing feel less enjoyable or effective than it could be.

Fear

This seems to be a significant barrier for people who’ve never tried pairing before. Some people are simply afraid of the unknown - they may have been programming solo since they were quite young and are really used to this way of working.

The other big fear is the one of intimacy - having to share your ideas and opinions freely and have them instantly judged by someone else is a much more direct way of working than many programmers are used to. This goes along with a fear of looking stupid - many programmers fear their ideas or designs are not that good, and would rather not have to demonstrate this to a pair.

A more sinister fear is the one some ivory-tower builders can have of losing their job security - by being forced to share their ‘unique’ domain knowledge with their team members will they lose their power and potentially their hold on their job?

Autism

Joseph Pelrine has talked about the higher-than-average incidence of Asbergers Syndrome or other ASD psychological conditions within the computer programming progression. People on the autistic spectrum demonstrate many skills that make them excellent programmers, yet they also suffer real barriers in communicating with other people. These barriers can make the close collaborative experience of pairing stressful for both them and their pair, and it’s important to be able to recognise the signs of this and work around them.

Need to Understand the Importance of Learning

A big part of the benefit of pairing is the spread of knowledge throughout the team, both about the problem domain and the technology being used. When an organisation simply doesn’t understand the value of learning, it may not yet be ready for the benefits that pairing can bring.

One of the main reasons I was drawn to adopt Ruby as my primary development language last year was the RSpec story runner, a fledgeling project to bring developers and users closer together with executable specifications that are easy for both humans and machines to read. I was really attracted to the community around these tools and the energy and focus they were putting into bridging that communication gap, and wanted to be a part of it.

18 months on and the RSpec story runner has matured into Cucumber, a hugely popular open-source tool for executing these tests. Ruby has made an excellent platform for Cucumber, the flexibility of the language and the collaborative open-source culture around it meaning the tool has matured rapidly, with over 177 different people contributing code to the project to date.

Over the summer, Cucumber began to speak to applications written in other programming languages than Ruby, by adding an adapter mechanism for the language in which the step definitions (the glue code which actually pokes around with your app) are written. Firstly this was done with JVM languages so that when Cucumber was run under JRuby, it could test an application via step definitions written in Java, Groovy, Clojure or Scala.

This still left .NET teams out in the cold though. One approach would be to run Cucumber under IronRuby but having tried some experiments with it, it feels like the slow boot-up time of IronRuby will make for frustrating TDD cycles right now. In response to this, I hatched a plot with Aslak Hellesoy, the creator of Cucumber, and Richard Lawrence to create a generic wire protocol for Cucumber which would allow it to invoke step definitions against a remote service written in any language. Over the last few months Richard and I have worked on the protocol, and at the same time Richard has built the .NET tool (Cuke4Nuke) that allows you to implement and serve up your step definitions in C#. Richard has just published an excellent short screencast which shows how to use it. If you’re writing .NET and would like to enjoy the warm glow of Cucumber, you owe it to yourself to take a look.

As a coach, I like to introduce new practices only when I can offer them as a solution to a problem that the team has identified for themselves. On my current team we’ve been tracking our Work in Progress (WIP) for some time, but we’ve never taken the step of systematically limiting it.

At a recent retrospective it became clear that everyone was feeling the strain of having too many things going on at once:

• Our velocity was really bumpy, with no releases for days at a time, then suddenly several stories going out at once in a big batch.
• Our QAs, who run final checks on stories before they go live, would be periodically hit by a tidal wave of work when one of these batches came through
• Stories would languish in the ‘nearly done’ stage, with developers too distracted with new work to finish off final copy changes and tweaks.
• There was a general feeling of being constantly distracted.
• We were doing less pairing than we wanted: the person you wanted to pair with always seemed to be doing something more important.
• We weren’t getting as much done!

We all agreed it was time to set a WIP limit.

So we studied our Cumulative Flow Diagram (CFD) chart, and looked back for a time when we’d been more productive. We used the measured WIP from that time as our new limit, and stopped taking on any more work until we’d drained down our number of stories in progress to that limit.

Here are the benefits we’re now enjoying:

• Our delivery velocity is smoother
• We’re pairing more again
• Our stand-up takes a sane amount of time, and people aren’t fidgeting and bored because what’s being discussed is more relevant to more people
• The cycle time to get a change through the build and into production is now way shorter

It’s too early to say, but I think we’re also starting to get more done again. Little’s law would certainly indicate that this is a likely outcome.

XtC are pleased to announce the 9th consecutive London XpDay:

The Agile community has grown and matured over the years we’ve been running XpDay, so now we want an event that helps practitioners collectively advance the State of the Art.

The first day will consist of programmed sessions, the second day will be an Open Space where attendees will discover more about the topics that interest them most. We have three remarkable keynotes lined up for this year: Mark Striebeck, Doron Swade and Terry Saunders. Of course, we’ll still have our famous evening social events.

– from Rachel Davies

The cost for the conference is £350. Highly recommended.

Scheduled Programme: http://www.xpday.org/programme

Booking Form: http://booking.xpday.org/registration.php

London XpDay: http://www.xpday.org

We all like usable software, but what about usable code? How do we test the usability of the code we write?

One way is to get another programmer to work with it. If a bug is discovered in some code you’ve recently written, instead of just quickly fixing it yourself, see how easy it is for someone else to fix. Write a failing test that isolates the bug, find a pair - ideally someone who has been working on something completely different - and let them loose on your code.

Try to resist telling them where to look - watch how easy they find it to navigate the code, find their way around it. Listen to their comments, and encourage them to start making little changes - rename things that don’t make sense to them, for example. Hopefully you were pairing when you wrote the code in the first place so the design will already reflect two people’s perspectives on the problem, but you often need at least three people’s input on a design before it really starts to become usable.

CITON (Continuous Integration and Testing Conference) Europe was one of my favourite conferences last year: A chance to hang out with some very thoughtful and experienced people in a close-knit setting. CITCON US has just announced the venue and dates. The conference is amazing value - free! - but the 150 places go fast, so keep an eye on the mailing list for when registration opens.

Organised and facilitated by Elizabeth Hendrickson this was a great group of people to meet with. Elizabeth ran the day as an open-space, a format which I really enjoy, and which worked very well for such an interesting, intelligent and enthused bunch of people.

I came away from the day having had the chance to discuss, in depth, some ideas that had just been floating around in my head as vague notions. This is the really great thing about getting groups like this together - you find that there are actually other people who you can talk to about these crazy ideas.

We also came up with a fantastic new feature for Cucumber. More on that later.

Long-running acceptance tests suites are a problem we’ve spoken about before. Following these discussions, I’m now more convinced than ever that the feature missing in most of our automated acceptance testing tools right now is memory. By remembering test results from previous runs, and ideally the source code changes that were associated with that run, we can build a model of the tests and their relationship to the code. We can use this to help prioritise the tests to optimise for failing fast - pick the tests most likely to fail and run them first. This is the strategy JUnit max has adopted, and it really makes sense to me. I look forward to getting some time to develop these ideas further.

I ended up in a session about using Cucumber with .NET which I think Aslak and I had both expected to be about explaining the new abstraction of ‘programming language’ in Cucumber, which allows step definitions (the glue that allows the cukes to drive your app) to be written in a variety of languages. In fact, the feedback we got from the assembled was that it would be even better to offer a generic ‘wire level’ language. This would then allow people on any platform at all to work with Cucumber - currently only platforms that run Ruby will work - and to write their step definitions without having to touch Ruby at all.

This is an idea that could only have emerged by getting that group of people together. Richard Lawrence and I paired up there and then and got to work on the new feature, which I fleshed out during more pairing sessions during the week with Aslak and Richard. Watch this space for more details as we get this working.

Did I mention that I like pair programming? Here are some reasons why it’s good for you and your boss.

More Trucks

The higher the truck number of your team, the more resilient it is to losing people. Pair programming spreads knowledge of the code around the whole team meaning each team member has a much more broad knowledge of the system than on a traditional team.

Free Training

Every time I pair with someone, I learn at least one new trick, be it a keyboard shortcut for my editor, a new command-prompt command, or a language idiom. This training costs nothing and builds the confidence of even the most junior team members who always have something to contribute, to say nothing of how much they will learn from sessions with their more senior colleagues.

Team Bonding

Working together in pairs breaks down barriers between people much more quickly than when they are working alone, and provides a natural environment for teams to learn to trust one another, and enjoy one another’s company. These are vital attributes that will get your team though the tough times, ensuring they can pull together when necessary.

Better Designs

Experienced programmers know that coding is much more a process of design than of mere implementation. When subjective design decisions are taken by at least two people on the team, those decisions have much more authority and are more likely to be understood and accepted by the rest of the team than if they had been taken alone. When one member of the pair has a good idea for a solution to a problem, this may stimulate an even better one from their pair. Science says so.

Less Bugs

The perpetual code review that’s done during a pairing session not only produces better designs, but it also catches a lot more defects as they are written. Pairs will tend to write more thorough automated tests, and are more likely to spot holes in logic that would otherwise have to be picked up by subsequent manual testing.

More Fun

Generally, programming in pairs makes for more a more relaxed and enjoyable atmosphere in a team. People become comfortable with their own strengths and weaknesses and are able to talk and joke about their work much more readily, since they are already used to that dialogue. This is obviously terrific for morale and staff retention.

More Focus

Pair programmers do not check their emails when they’re waiting for a script to run, disappear into their inbox for 20 minutes, then come back and have to remind themselves what on earth they were doing. When they hit a little break-point, they review what they’ve done so far and make a plan for their next steps. They stay focussed. Twitter can wait.

A while ago I wrote a tip that showed you how to copy your public SSH key to a remote server to allow you to login without entering a password every time. I’ve since put this into a script that I use, and today I got sick enough of copying that script onto yet another machine that I packaged it up as a gem, so now we can all use it.

It works just like the plain old ’ssh’ command, but this time you’ll never have to enter your password again:

ssh-forever username@yourserver.com

Your key will be generated (if necessary), copied to your server, and you’ll be logged in as normal.

Installation

gem sources --add http://gemcutter.org
gem install ssh-forever

Example:

[matt@bowie ssh-forever (master)]$ ssh-forever mattwynne@mattwynne.net
You do not appear to have a public key. I expected to find one at /Users/matt/.ssh/id_rsa.pub
Would you like me to generate one? [Y/n]y
Copying your public key to the remote server. Prepare to enter your password for the last time.
mattwynne@mattwynne.net's password:
Success. From now on you can just use plain old 'ssh'. Logging you in...
Linux broncos 2.6.29-xeon-aufs2.29-ipv6-qos-grsec #1 SMP Thu Jul 9 16:42:58 PDT 2009 x86_64
  _
 | |__ _ _ ___ _ _  __ ___ ___
 | '_ \ '_/ _ \ ' \/ _/ _ (_-<
 |_.__/_| \___/_||_\__\___/__/
 
 Welcome to broncos.dreamhost.com
 
Any malicious and/or unauthorized activity is strictly forbidden.
All activity may be logged by DreamHost Web Hosting.
 
Last login: Sat Aug 15 17:24:17 2009
[broncos]$

Why?

Because I can never remember how to do it by hand. Now I don’t have to, and nor do you.