4 ms·

I can see some use for the mob, but I think I'd struggle to do it all the time. For certain fiddly things, it can help a lot to have several eyes. "Spot the bu

I can see some use for the mob, but I think I'd struggle to do it all the time. For certain fiddly things, it can help a lot to have several eyes. "Spot the bug" type issues, perhaps. Also "let's design and agree this interface" seems like a thing that might work, eg if you're all implementing the interface in separate backends on your own time. The big one is probably "let me show you how it currently works" which probably a lot of people have done as an intro to a new team. But just generally coding as group I think could get tiresome. You'd have to think about how to navigate things socially, ie how do I get the shy person to bring their ideas if they have any, and not let the domineering one keep talking over everyone? Plus you tend to think faster than you can implement, and that impedance mismatch would need to be dealt with across people. Finally there's the cost of it. Four devs could easily cost the company a million bucks a year. 250 days of $4000 8 hour days -> $500/hr. Seems like a lot, you'd better have some quite scalable income to make it worthwhile. It's definitely not impossible, but chances are you want to sometimes use the $500, sometimes work separately. Also there's tools to make this a lot easier these days. VS Code lets you share itself online, that's pretty useful.

schurzi 5y ago
(I was part of the group described in the article) You are absolutely right. We also don't want to work like this all the time. As always this is a tool which is suited for specific circumstances. We found it really helpful for implementing things that need a lot of discussions or for distributing knowledge. These are instances where you need a lot of time talking with your team anyways so the mob is a combination of implementation and the separate discussion, reviews or knowledge transfers that you do regardless. Opposed to this, the mob is absolute overkill, if you write boilerplate or uncontroversial code the whole time. Also in situation where nobody has knowledge and all members of the mob are struggling to continue it might be better to quit and choose one or two scouts to gather knowledge before continuing.

schurzi 5y ago

(I was part of the group described in the article) You are absolutely right. We also don't want to work like this all the time. As always this is a tool which is suited for specific circumstances. We found it really helpful for implementing things that need a lot of discussions or for distributing knowledge. These are instances where you need a lot of time talking with your team anyways so the mob is a combination of implementation and the separate discussion, reviews or knowledge transfers that you do regardless. Opposed to this, the mob is absolute overkill, if you write boilerplate or uncontroversial code the whole time. Also in situation where nobody has knowledge and all members of the mob are struggling to continue it might be better to quit and choose one or two scouts to gather knowledge before continuing.