Takes a long time before it acknowledges pair programming, but it gets there in the end. But it never even attempts to quantify the bottom line:
> the work actually assigned getting done faster as people working together can get it done much faster
The only thing that's definitely true is the task is consuming 2x FTE salaries for its duration. Does that translate into 2x faster progress? It's extremely hard to say, as all the previous struggles with software estimation and time recording have shown us.
The challenges are not dissimilar to allocating work to execution units within a CPU; a programmer with two tasks assigned who swaps between them when blocked is "hyperthreading" and usually achieves higher throughput, although frequent task switching incurs time costs.
So in practice engineers have multiple things in progress, both for their own account and things they're helping other people with. That is, after all, part of the point of telling other people about it in standups.
> Probably at some point you have experienced how quickly things can get done, especially in case of emergencies (like “OMG, something is wrong in production”) where multiple people with different skills and knowledge jump together into one “room”?
This is however a warning sign to me. There are a lot of mechanical systems you can run at more than their rated performance in emergencies before experiencing burnout, and the same applies to humans. You can't just crank the team up to "flank speed" and leave it there.
I've tried pair-programming and it felt exactly like that - working at 100% intensity for the whole 8 hours. It felt very productive and intense but also quite tiring.
I certainly learnt a lot and it was probably twice as fast as if we would have worked alone, but I wouldn't want it to be the default for every task, I would just burn out quickly.
The main benefit was finding edge cases immediately (so feedback loop of design-implement-test-fix needed less iterations) and on-the-fly debugging was faster.
That's weird coz I feel more stressed out about working solitary.
With pair programming if im having a rough or unproductive day i can let my pair do the heavy lifting (or vice versa).
When programming alone I get anxiety about whether or not Im doing the right thing almost all the time which causes stress.
I prefer solitary (& am more efficient) if i have a very clear picture of what needs to be done and how but realistically most of the time Im dealing with ambiguity and subtle trade offs.
> the work actually assigned getting done faster as people working together can get it done much faster
The only thing that's definitely true is the task is consuming 2x FTE salaries for its duration. Does that translate into 2x faster progress? It's extremely hard to say, as all the previous struggles with software estimation and time recording have shown us.
The challenges are not dissimilar to allocating work to execution units within a CPU; a programmer with two tasks assigned who swaps between them when blocked is "hyperthreading" and usually achieves higher throughput, although frequent task switching incurs time costs.
So in practice engineers have multiple things in progress, both for their own account and things they're helping other people with. That is, after all, part of the point of telling other people about it in standups.
> Probably at some point you have experienced how quickly things can get done, especially in case of emergencies (like “OMG, something is wrong in production”) where multiple people with different skills and knowledge jump together into one “room”?
This is however a warning sign to me. There are a lot of mechanical systems you can run at more than their rated performance in emergencies before experiencing burnout, and the same applies to humans. You can't just crank the team up to "flank speed" and leave it there.
(irrelevant aside: apparently the USN have called their O365 migration plan "Operation Flank Speed", which I find unreasonably funny. https://federalnewsnetwork.com/navy/2021/05/navy-transitioni... )