As I’m writing this, I’ve just got back from a great couple of days at Agile on the Beach - the scheduled talks were of a very high calibre as were the interim discussions on the “Hallway Track” (a term I’d been looking for to decribe the chatting taking place in the social areas at conferences).
Additionally, the non-talk events like the Beach Party were equally enjoyable … but we’ll skip over some of those details for now.
Another benefit of #mobprogramming - no branching as no one else is committing, everything can be on trunk, enabling Continuous Integration!
— Alex Wilson (@pr0bablyfine) September 3, 2015I attended a talk by Steve Smith about the Death of Continuous Integration - the crux, which I agreed with, is that branching is made so easy by both VCS software and external tools (like GitHub flow) that rigourous Continuous Integration is falling by the wayside.
It was during a chat outside of the talk that I realised Mob Programming, in addition to other virtues which I extol heavily elsewhere, is a huge enabler for Continuous Integration.
In more detail
Since the principle of Mob Programming is everyone working with the same code at the same time on the same workstation, additional non-trunk branches are no longer needed - the group is able to do realtime code review so the Pull Request/Approval model disappears also.
After discussion, we realised it actually goes further than that, and Mob Programming not only enables Continuous Delivery but makes it a logical conclusion to the way a Mob operates.
If Continuous Integration is truly falling by the wayside, then maybe intensely collaborative ways of working such as Mob Programming can help bring it back, or evolve it even further.