Junilu Lacar wrote:The opportunity to teach less experienced or newer developers
This is a key point, I think. There's an analogy with Test-Driven Development in here somewhere, let's call it Training-Driven Development, TDD ;)
A long-term project lives or dies by the quality of the maintenance. Initially it seems great to have a single developer who has a deep understanding of everything and can solve every problem quickly and efficiently, but eventually that developer is going to move on. What happens after that depends on how well the successors share that deep understanding.
I have spent most of my career as a contract developer, typically brought in to work on codebases which have grown horrible through years of suboptimal fixes and "improvements". The story is almost always the same. A single hero developer (occasionally a small team) who was always too busy or too secretive to explain why and how. Then the hero moved on to a new project, beginning the decline into a ball of mud.
Techniques such as pairing (and, as Junilu points out, mobbing) and code reviews seem like a needless slowdown, just as writing tests seems like extra work which just gets in the way when you know you are writing good code.
Test-Driven Development has gained a lot more traction, though, probably because the benefits pay off sooner. But the analogy holds, and investing in the future through immersive training has a place too.
I'm not going to claim that these training techniques should
always be used, though.
I'm a huge Test-Driven Development fan (you only have to look back at my Ranch history to see that) but even I admit that it's not always appropriate. Some will only have a very short life, such as the data analysis and graph drawing code I am currently writing for my PhD research, and the overhead of writing tests is pointless. Likewise, some projects will be so personal or so short-lived that they will never be handed over to other developers. In those cases the overhead of training successors is also pointless.
But in the context of a complex, long-lived project, succession planning and training is as important as any other "non functional" requirement. In such cases, collective ownership, pairing/mobbing, and code reviewing are some of the easier ways to integrate training in with the day-to-day development work.