Mob Programming - first impressions

25 Mar 2018 in programming |

I am currently involved in product development with a small but fine team (4 devs, one product designer). We had to redo one of the core components in order to make it fit for its refined and renewed responsibilities. We did not see how we could work separately or even in pairs on this central junction of the application - the decision was made to go forward with mob programming

how we did it

For about 2½ days we were sitting together. Each one brought their laptop along so that we didn’t have to get used to someone else’s dev environment. One was the “driver”, typing what needs to be done and projecting the screen onto the Surface Hub. The others are the “navigators”. We would set the time at 15 minutes for switching the driver, but we usually let the current “step” end before switching over. Switching over meant pushing to the branch, and the next one pulling and carrying on.

interesting precondition

We did not reinvent the component completely but had the previous incarnation to work with. That way it had characteristics of a code kata.

how did it turn out?

  • Mob programming does not optimize for speed - while it is hard to put a number on this, subjectively it feels slower than working alone or in pair. There is simply more brain in the room and things need to be sorted out!
  • Mob programming optimizes for code soundness - With all people involved, the solution seemed to converge towards building what is necessary. Hence, there weren’t masses of code involved but that which was written was absolutely necessary, well named and sound.
  • Mob programming optimizes for knowledge transfer and learning - You get to see how others write code and run their coding errands. Everybody makes an effort to understand what is happening (since everybody will be driver or navigator at some point). f something is unclear it will be asked straight away, then explained, or the question actually leads to code modifications with regard to naming and clarity. If everybody must understand the code, it must be pretty clear.
  • Mob programming optimizes for team flow and empathy - It provided a sense of shared accomplishment and generally “good vibes” in that the whole team sits in the same boat and everybody can peek into the other’s mind.

would we do it again?

Yes, absolutely. I think there are many tasks that can be done well alone or in pair. But if you need a concerted effort that requires a number of changes and a lot of thinking, or possibly a situation where you introduce a new concept, this approach appears to make a lot of sense. But beware, though, that, at least for us, the mob programming days were absolutely exhausting. A lot of focus and zero distractions means that at the end of the day you are done!

It’s worth it, though, give it a spin if you get the chance.

Chronology

  |  
comments powered by Disqus