Comment by DanielBMarkham | Hacker News Reader

Comment by DanielBMarkham | Hacker News Reader

(Looks at HN) Hey! Another Agile story. Mob programming is cool. Wonder what the commenters think?

(Looks at comments) Sigh.

Okay, everybody who has actually mob programmed? Raise your hands. Let's hear how it went. Everybody who has an opinion -- usually about how it's all a crock of shit and a waste of time -- you guys to the back of the room. No offense, but this is kinda the standard response to anything posted on HN.

Modern programming, especially at BigCorp, is much more about tooling and environment (both technical and social) than it is technology. People who get together and work a piece of value from front to back in the system quickly gain a common understanding of how all that tooling and environmental structure is supposed to work. In a day or two of mobbing, you can take a team through what might otherwise be months of mentoring and code reviews. It's so effective at teaching "how to make solutions here" that I'm hearing stories of noobs picking up an entire language simply by participating in a mobbing group over a few weeks.

Got a team that wants to make mob programming into another committee meeting? Guess what? Your team is broken. Get that problem out in the open on day one and then fix it. Don't hide behind process. Mobbing makes you do this.

If programming were measured by the amount of keys you pressed, or KLOC, mob programming would make no sense at all. But it's not. Programming is about making computers do things that people want, whether it's one line of code or a million. So what you're optimizing for is the appropriate mix of diverse problem-solving methodologies and personality types in order to maximize the quality of creative responses to the business problem.

I'm a big mobbing fan -- having watched it and done it. I don't think it's a magic bullet or appropriate everywhere. I think the interesting part of this discussion will be identifying situations where it's a bad idea. (And of course that would be done empirically, not anecdotally)

Agreed. There is a narrative programmers tell when complaining online. It goes like

> If only they would just leave me alone! I would sit in silence for 4 hours pondering the depths of the system at hand. Then I would spend 30 minutes invoking VIM macros at 240 actions/minute (that's why I spent 12 years integrating VIM into my lower cortex, after all). Then I would spend 5 minutes admiring the perfection of my creation before retiring to the pub. Tomorrow, everyone will find everything just works so much better than yesterday and they won't even know how or why. I'll just lean back and say "You're Welcome."

But, the reality is that you don't work in a vacuum; you don't know the whole situation; your proposed solution probably isn't as good as you'd like to think it is; other people are doing stupid things and breaking stuff because you never mentor them; you are doing stupid things and breaking stuff because other people aren't informing you about what you should be doing better; even when you are actively working on code, you spend less than 5% of your time actually typing code; if you are a senior engineer working on non-trivial systems, you probably spend more time sorting out how other people's code works than your own.

These realities don't fit the http://hackertyper.net/ narrative. They're embarrassing and require inter-personal effort to resolve. But, brushing them off is making you a whole lot less productive than you should be.

Wow! I couldn't have said it better myself. Having worked across a variety of codebases and teams over the last 10+ years, it has become obvious to me that delivering software is an inherently social activity (at least the delivery of valuable software)

IMHO, the reason we've seen the rise of XP, Behaviour-driven Design (BDD) and DevOps is that each part of the software delivery community is gradually coming to this conclusion within their own realm

Mobbing for me just makes sense on so many level, especially from the point of view of adding 'expertise' to a problem/solution:

Not sure on how to integrate the latest language feature into your code - bring someone with experience into the mob...

Not sure how this feature could be tested - bring a QA/tester into the mob...

Not sure of the infrastructure requirements of this new database - bring an operator into the mob...

People have been doing this for years, they've just not put a name to it.

In my experience working as a consultant across multiple organisations, not enough people have been doing this.

As for a putting a name on it - a name can help spread the idea (ubiquitous language and all that), but it can lead to abuse and cargo-culting.

I believe a label is often helpful during the 'innovation' and 'early adoption' diffusion of innovation phase, and this is firmly where mobbing is at the moment

Thanks for telling us what we already know about software development.

It's what we all already know, but it's not what we say to ourselves or to each other. Instead, we say things like

> I like programming alone godammit! Will programming alone be relegated to hobby projects while I head to the meeting room for all my job-related programming duties? Bah humbug!!!

So, in the middle of a lot of "Bah humbug!!!", it's good to have a reminder that maybe this awkward interpersonal stuff is important to, you know, actually getting real shit done.

So do you think mobbing is something that you would do instead of pair programming, or do you see them as complementary?

From what I've seen so far (10-15 examples), mobbing is superior to pair programming. Pair programming has a lot of social pressure (I don't like working with X!) that just isn't there with mob programming.

There's gotta be some inflection points, though. This is an extremely interesting area to watch. If it holds up in general, it's really completely re-structuring what we think about when we think about a tech team delivering value.

ADD: The thing to keep in mind here is that we're still very early in the hype cycle. Lots of smoke, and people who make money waving their arms around. Having said that, there is real value here. So it's interesting.

Great comments Daniel, and I think you've touched on one of the key points that we're seeing with the rise of mob programming and lean practices etc "it's really completely re-structuring what we think about when we think about a tech team delivering value"

This is the sticking point for many people, as we still like to draw analogies between coding and typing, or coding and physically building structures (which inherently are limited by the application of manual labour), rather than seeing it for the value-creation/design-thinking act that it actually is (and accordingly the need for good imagination and decision-making abilities)...

Reply on news.ycombinator.com