Does the Mob Programming work? Year Recap
TL; DR: Yes
A year ago, I wrote an article Don’t do Code Review, try Mob instead and I promised the commenters to review this topic after a year. It’s exactly a year. So here we go!
Business-technical decisions in code
Commonly, we find ourselves in a situation that we understand the problem, and we understand the needed outcome. The only question remaining is HOW? How to do that?
- Add a parameter or a method?
- Rely on DB integrity or code it?
- Put code into service A or B?
- Do we have to resolve an edge case or can we call it “Won’t fix bug”
Such decision in code that reflects a business need is made many times a day. The decision must be made, and it must be a good decision.
As we work in Mob, we do such decision always together. We all understand consequences and benefits. Anyone can immediately raise an argument for/against a solution. And we discuss it in the given moment, without further delays.
This kind of business-technical decision is often difficult. In the no-Mob style a decision may result in a consultation; in a team meeting; or in a code review ping-pong. Making the decision might take hours or days.
Mob programming immensely shortens the decision time. In Mob it takes from seconds to tens of minutes.
Code maintenance
I have an experience from previous projects with maintaining an old code. There is always a huge amount of suspicious (even crazy) code in the legacy software. Especially difficult to maintain is a legacy code that is developed by people who aren’t in the company anymore. Difficult… it’s a nightmare.
Our team spend ~30% of time by maintaining existing software. Some parts are a year old, some are 10 years old. We aren’t exceptions, we have skeletons in a closet as well.
With Mob programming, the maintenance is manageable. There are 4 of us, so there is a bigger chance that one colleague remembers a reason why something is done, and how to use it. When non of us knows, we investigate the code, and together come to a conclusion how to proceed.
It might happen that we hit really bad part of the code, and in that case my colleagues help me from procrastination just by theirs presence. I simply cannot procrastinate because there is always at least one person trying to resolve the problem. In bad days colleagues usually helps me to get into a better mood.
Maybe the Mob isn’t the reason why I’m happy in the work, maybe it’s because my colleagues are so awesome!
Business
When we speak with business people, we’re always together. One cannot remember everything, but usually at least one of us know an important detail that later helps with the Business-technical decisions in the code.
Our company is pretty agile — we don’t have a layer of analysts or a middle management. Therefore we are close to the business — we participate on the business decisions, and still we are developers.
Mob fits pretty well into an agile company.
Minor technical decisions
From time to time, we split.
Another team needs a help? One person splits to help them.
The CI is failing? One or two might split to investigate. If it’s too difficult, the whole team joins the investigations.
Do we need to implement a purely technical feature? Like log every request/response? One might split, implement it, and another does a code review. This works fine as well for us.
Disadvantages
I cannot listen to music during coding anymore.
Advantages
I can walk!
That’s all
I work in a Mob team for a year and half, and I wouldn’t change.
