Hacker News Reader

Comment by dudifordMann | Hacker News Reader

Perhaps this is good for feature development, or maintenance, but, what about contracts that deal with wholly new development of a complex system? It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure. Perhaps I am being disingenuous.

I do love the idea of being able to not let the numerous tedious meetings interrupt progress.

[edit] Thanks everyone for adjusting my perspective. I am sure junior engineers (and seasoned stubborn ones) would learn a lot with cradle to grave development in such a fashion [/edit]

View on HN

Having spent thousands of hours pair programming I would assume that this is were mob programming is especially valuable. The decisions you make early on are the decisions that everyone on the team will have to deal with. So if you do nothing else as a team this should be it. I actually recently had a client who was lukewarm about pair programming. But they mob programmed on new laying foundation work fit new services. We pair programmed on three new services together at the same time. So much syncing had to happen afterwards that mob programming the foundation would easily have been more efficient and effective.

> It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure.

I'd disagree there, if there's a place for mob programming, it's probably here. Given every member of the team will most likely be branching features from a singular foundation, it becomes far more important for every person to have a chance to understand the core completely. This also has the side benefit of reducing friction later on by establishing basic conventions.

A former colleague of mine, one for whom I have great respect, is applying mobbing for this right now. So far, they think it's a great way to get and keep everybody on the same page.

I'm still skeptical of mob programming, although as somebody who's done a lot of pair programming I'm open to it. But the theory makes sense to me. Early on it's easy to make decisions or fall into habits that cause trouble later. Figuring out some of those initial choices strikes me as the best place to apply a lot of brainpower. Once the architecture is established, I'd expect things would be much easier to parallelize. (But I'd still keep pairing and frequent pair rotation to keep everybody in sync.)

Reply on news.ycombinator.com