So, like a "surgical team"? Fred Brooks proposed that 45 years ago, and I still don't see any evidence that anyone is moving in that direction.
Everyone I know says that all programmers and managers need to read TMMM, but any time I've brought up any part of that book other than Brooks's Law, I've been immediately shot down. According to every coworker and manager I've had, this book is a classic of the field -- yet apparently has all of one useful sentence between its covers.
Well we have pair programming now, but unfortunately that has all the problems of two surgeons with none of the benefits of complimentary skills.
For a while I was paring with someone where we did take on more of a surgical team model that worked quite well. The other guy was the c++ and domain expert cranking out code and I was the unix, git, etc expert and acting as the toolmaker and "magic spell" provider.
That said, in a real surgical team some of members make considerably more money than the others so I doubt we'll see it take off in our industry.
Outside of unusual scenarios the pay ratio between the best paid member of a software team and the worst paid member probably caps out at around 4x, whereas on a surgery team it's probably more like 10x.
My ex colleagues who landed at Pivotal when we parted ways years ago described it as a sweatshop with rigid 9-5 hours and pair programming, that it was very much aggressively pushing in the blue-collar meets software development direction.
Everyone I know says that all programmers and managers need to read TMMM, but any time I've brought up any part of that book other than Brooks's Law, I've been immediately shot down. According to every coworker and manager I've had, this book is a classic of the field -- yet apparently has all of one useful sentence between its covers.