Comment Re:Possibly a band aid for poor code organisation (Score 1) 126
Hi Mortimer :)
Someone linked me to this discussion. Nice to read something thoughtful on the topic. I'd like to give you some context and then clarify a couple of aspects of the way we use mob programming.
First, some context. We were asked to develop 3 embedded home control devices, 2 of which have LCD user interfaces and 1 of which connects to a cloud, from the ground up in ~1 year. They allow you to do complex stuff like set up multi-channel heating schedules and bind to a 868mhz radio network... with firmware update capability... etc. They also needed to be future proofed for a whole bunch of new products coming later, supporting ridiculous levels of complexity. Oh and one of them needs to consume less than ~100uA of current. Ah, and there's a 1% RF duty cycle we must abide by ;)
In order to achieve this, they wanted as many people working together on the products as possible without treading on each others toes. To this end, we had more than 20 developers working on 3 products with plenty of cross-over. We also encouraged an evolving codebase rather than locking down interfaces and lots of big up-front design, which we all know utterly kills habitability :)
Our architecture (and technically i'm not an "architect"... we encourage all developers to architect as they go) is one of the most habitable, well tested code bases I've ever seen. We use TDD, and we use it well. It's future-proofed, and largely de-coupled. I'm extremely happy about its general level of habitability.
Now to clarify when we use it :)
When you have that many devs working and re-working code from the ground up with so much shared code too, *and* in an embedded context.... you get some interesting conflicts man! :) The other day someone had added an ISR wrapper to help safeguard context behaviour which conflicted with a bunch of DMA changes... this ain't nasty interface churn I'm talking about, it's serious stuff.
At other times we have some more esoteric issues, such as tests failing as a result of merged code, which can be resolved MUCH faster when both parties involved in implementing the code are present. At times like this, we often form a small "mob".
Otherwise, the only time we tend to use the technique is for training purposes. We do plenty of pair programming though, and that often naturally leads to impromptu... ahem... threesomes.
Best regards
Someone linked me to this discussion. Nice to read something thoughtful on the topic. I'd like to give you some context and then clarify a couple of aspects of the way we use mob programming.
First, some context. We were asked to develop 3 embedded home control devices, 2 of which have LCD user interfaces and 1 of which connects to a cloud, from the ground up in ~1 year. They allow you to do complex stuff like set up multi-channel heating schedules and bind to a 868mhz radio network... with firmware update capability... etc. They also needed to be future proofed for a whole bunch of new products coming later, supporting ridiculous levels of complexity. Oh and one of them needs to consume less than ~100uA of current. Ah, and there's a 1% RF duty cycle we must abide by
In order to achieve this, they wanted as many people working together on the products as possible without treading on each others toes. To this end, we had more than 20 developers working on 3 products with plenty of cross-over. We also encouraged an evolving codebase rather than locking down interfaces and lots of big up-front design, which we all know utterly kills habitability
Our architecture (and technically i'm not an "architect"... we encourage all developers to architect as they go) is one of the most habitable, well tested code bases I've ever seen. We use TDD, and we use it well. It's future-proofed, and largely de-coupled. I'm extremely happy about its general level of habitability.
Now to clarify when we use it
When you have that many devs working and re-working code from the ground up with so much shared code too, *and* in an embedded context.... you get some interesting conflicts man!
At other times we have some more esoteric issues, such as tests failing as a result of merged code, which can be resolved MUCH faster when both parties involved in implementing the code are present. At times like this, we often form a small "mob".
Otherwise, the only time we tend to use the technique is for training purposes. We do plenty of pair programming though, and that often naturally leads to impromptu... ahem... threesomes.
Best regards
