Mob Programming Part 2

Click here to read Part 1

The Problem

We wanted some complexity in the problem, enough that would warrant us needing to research part of our algorithm.  But also, not too much that we were better off just copying and pasting code from someone else.

We chose to write an engine that calculates the percentage likelihood of winning for every player in a Texas hold 'em game.  There's a good amount of complexity and everyone understood how the game works.

2nd Attempt

This time around we rallied behind a single driver (who we'll just call Jake Byram because that's his name).  He was in charge of facilitating the group discussion.  As a group we decided what classes we needed to create and what their primary responsibilities were.

Jake had a single file open that we all looked at on the projector.  We would only use our machines if we wanted to research something that would help the current task at hand.  Once we've shaped the contract of what a class would be someone else would extract the code into the appropriate file and folder.

We did this for about half an hour (again, we're still just coding over our lunch break).  After we split out enough files we went off individually to flesh out the classes.  With this session we were able to come up with a better set of components with more defined responsibilities. We also found that 1 hour is barely enough time to get work accomplished and only if you stay really focused.

We still maintained a good group dynamic with some joking around, questioning design decisions, debating algorithms, etc.  The whole process felt more organized this time around by having a single driver and everyone focusing on the same screen.

Introduction to my version of Mob Programming

Inspiration

I was first turned on to mob programming from one of the podcast episodes of .Net Rocks that I listen to on my daily commute.  From the sound of it, the founding group has a very specific way or process that they have endorsed as "mob programming".  They even offer workshops and training on it from what I remember.  I'm going to share my version of mob programming that differs from what the founders have in mind.

1st Attempt

I picked a group of about 5 other programmers in my company, most of which have worked with each other on a project, and others that I have never worked with before but have always wanted to.  The plan was to come up with a challenging problem to solve that wasn't large in scope.  The caveats were that no one (other than me) knew what the problem was going to be ahead of time, we would only do a 1 hour session over lunch, and we would all have simultaneous access to the code via Cloud9IDE.

As I fully expected, this session was absolutely chaos, but FUN chaos!  We weren't sure if we should all brainstorm together or silo off code and somehow integrate it all.  We didn't know who was building what components.  And even more frighteningly, we didn't know if Cloud9 was lying to us at times by not syncing all our code correctly across our computers.  

Through the roughly 45 minutes (first 15 minutes were spent eating and talking about the problem) we challenged each other, questioned each other, accidentally deleted each other's code, and made a hot mess out of a JavaScript solution.  We also unanimously agreed to do it again but with a little more direction which I'll cover in the next post along with what the actual problem was that we were trying to solve.

Click here to read part 2