Como muchas de estas preguntas, creo que la respuesta es:
Depende
Hay razones para creer que tomar la posición de que todo programador debe saber que cada línea de código está mal orientado.
Si asumimos por un momento que alguien con un conocimiento profundo de un código hará los cambios 5 veces más rápido que alguien que no lo sabe (no es un gran salto de fe en mi experiencia) y se necesita alrededor de un mes de experiencia en codificación para obtener una buena comprensión de un módulo de tamaño significativo (lo que no es irrazonable), entonces podemos ejecutar algunos números (completamente falsos y ficticios):
- El programador A: tiene un profundo entendimiento
- Programador B: ninguno
Digamos que el programador A obtiene 1 unidad de trabajo por día. En 4 semanas de 5 días hábiles, puede realizar 20 unidades de trabajo.
Entonces, el programador B, que comienza con 0.2 unidades de trabajo por día y termina con 0.96 unidades de trabajo en su día 20 (en el día 21 son tan buenos como el programador A), logrará 11.6 unidades de trabajo En el mismo periodo de 20 días. Durante ese mes, el programador B logró un 58% de eficiencia en comparación con el programador A. Sin embargo, ahora tiene otro programador que conoce ese módulo además del primero.
Por supuesto, en un proyecto de tamaño decente, podría tener ... ¿50 módulos? Así que familiarizarse con todos ellos le lleva aproximadamente 4 años, y eso significa que el programador de aprendizaje está, en promedio, trabajando con una eficiencia del 58% en comparación con el programador A ... hmmm.
Considere este escenario: mismos programadores, mismo proyecto (A lo sabe todo y B no sabe nada de eso). Digamos que hay 250 días hábiles en el año. Supongamos que la carga de trabajo se distribuye aleatoriamente en los 50 módulos. Si dividimos a ambos programadores de manera equitativa, A y B obtienen 5 días hábiles en cada módulo. A puede hacer 5 unidades de trabajo en cada módulo, pero B solo obtiene, según mi pequeña simulación de Excel, 1,4 unidades de trabajo realizado en cada módulo. El total (A + B) es 6.4 unidades de trabajo por módulo. Esto se debe a que B pasa la mayor parte de su tiempo sin ninguna habilidad con el módulo en el que están trabajando.
En esta situación, es más óptimo que B se enfoque en un subconjunto más pequeño de módulos. Si B se enfoca en solo 25 módulos, obtienen 10 días en cada uno, con un total de 3.8 unidades de trabajo en cada uno. El programador A podría pasar 7 días cada uno en los 25 módulos en los que B no está trabajando, y 3 días en los mismos módulos que en B. La productividad total varía de 6.8 a 7 unidades por módulo, con un promedio de 6.9, y eso es significativamente más alto que las 6.4 unidades por módulo que hicimos cuando A y B repartieron el trabajo de manera uniforme.
Al reducir el alcance de los módulos en los que B trabaja, obtenemos aún más eficiencia (hasta cierto punto).
Entrenamiento
También argumentaría que alguien que no sepa mucho sobre un módulo interrumpirá a la persona que hace mucho más que a alguien con más experiencia. Por lo tanto, estos números anteriores no tienen en cuenta que cuanto más tiempo dedica B a un código que no entienden, mayor es el tiempo que dedica A al hacer preguntas y, a veces, A tiene que ayudar a solucionar o solucionar lo que B hizo. Entrenar a alguien es una actividad que consume tiempo.
Solución óptima
Por eso creo que la solución óptima debe basarse en preguntas como:
- ¿Qué tan grande es tu equipo? ¿Tiene sentido que todos entrenemos en todas las partes, o si tenemos un equipo de 10 personas, podemos asegurarnos de que cada módulo sea conocido por al menos 3 personas? (Con 10 programadores y 50 módulos, cada programador debe conocer 15 módulos para obtener una cobertura 3x).
- ¿Cómo es la rotación de su empleado? Si está entregando empleados a un promedio de cada 3 años, y le toma más tiempo conocer realmente cada rincón del sistema, entonces no estarán disponibles el tiempo suficiente para que la capacitación se rinda a sí misma.
- ¿Realmente necesita un experto para diagnosticar un problema? Mucha gente usa la excusa "qué pasa si esa persona se va de vacaciones", pero me han llamado muchas veces para diagnosticar un problema en un sistema con el que no tengo experiencia. Puede ser cierto que la persona experimentada podría encontrarlo mucho más rápido, pero eso no significa que no pueda vivir sin ellos durante una o dos semanas. Pocos sistemas de software son tan críticos para la misión que el problema debe diagnosticarse en 1 hora en lugar de 5 horas o el mundo terminará. Tienes que sopesar estos riesgos.
Por eso creo que "depende". No desea dividir 20 módulos entre dos programadores justo en el medio (10 cada uno), porque entonces no tiene flexibilidad, pero tampoco desea entrenar a los 10 programadores en los 50 módulos porque pierde mucho eficiencia y no necesitas tanta redundancia.