¿De cuánto código debo ser responsable?

A través de colegas y entrevistas de salida, he oído que en mi pequeña empresa soy "responsable" de entre 3 y 10 veces más código del que sería en otro trabajo. Estoy tratando de buscar algún tipo de métrica difusa que pueda usar para comparar mi carga de trabajo con otros en mi campo.

Por "responsabilidad del código", no me refiero a "Soy el único que conoce el área X de la base del código" (aunque lamentablemente, a menudo es cierto en un entorno de inicio), sino que me refiero a un número como "code_base_size / número_de_desarrolladores ".

¿Hay algún recurso que pueda usar para ayudarme a medir con mayor precisión mi carga de trabajo que solo contar líneas de código?

La única medida concreta para un desarrollador empleado es la cantidad de horas que pasa codificando y reparando errores, y el dinero que le pagan por ello. Si se queda hasta tarde en la noche 6 días a la semana por 50K US $ al año, entonces tiene un problema. No importa de cuántas líneas de código desee que sea responsable su jefe, no manejará más de lo que puede hacer, teniendo en cuenta una determinada calidad de código, por supuesto. Desarrollar un código de baja calidad sin pruebas unitarias es una buena manera de manejar mucho más código, pero la compañía tendrá que pagar el precio de una gran deuda técnica .

En las pequeñas empresas, los desarrolladores tienden a ser responsables de mucho más código que en grandes corporaciones. El factor del 3 al 10 al que te refieres me parece realista.

Conozco un equipo de tres personas que manejó una base de código de línea de 1.5 millones y no se ahogó en él. La medida importante no es la cantidad de código de la que eres responsable, sino la cantidad de código que necesitas cambiar en un cierto incremento de tiempo.

También está el ángulo de evaluación de riesgos. Si usted es la única persona que conoce un código, ¿cuál es el costo de oportunidad que se perdería si camina debajo de un autobús? Las pequeñas empresas generalmente no hacen una evaluación de riesgos como esa, pero esto significa que el éxito continuo del negocio se deja al azar.

El tamaño base del código / número de desarrolladores no está relacionado con la carga de trabajo. Si tiene una enorme base de código estable, esa métrica será alta. Si todavía tiene una pequeña base de código en desarrollo, esa métrica será baja. Los cambios de líneas por unidad de tiempo por desarrollador están más relacionados con la carga de trabajo. Pero incluso entonces, pasé días para rastrear errores sutiles cuya solución era una línea ...

El código debe ser responsabilidad del grupo, no de un desarrollador. El soporte debe delegarse de manera justa cada semana, parece estúpido asignarlo de otra manera. Si ese no es el caso, le sugiero que hable con su gerencia.

En la situación en la que describe a un desarrollador, podría tener dificultades para cumplir con los plazos debido a la gran cantidad de soporte de un área en la que otros desarrolladores no trabajan. Es una estructura de gestión muy ineficiente.

También le sugiero que se aleje de medir la carga de trabajo en líneas de código. Horas de hombre es la única métrica sensata en la que puedo pensar

Medir el progreso de la programación por líneas de código es como medir el progreso de la construcción de aeronaves por peso - Bill Gates

NÓTESE BIEN. No digo igual, digo justamente. También vale la pena señalar que está bien especializarse en ciertos aspectos de la base del código, eso sucede naturalmente. Es solo un problema si nadie más trabaja en ese código.

Por ejemplo, si Facebook tuviera 2 programadores, obviamente tendrían un exceso de trabajo, pero ¿CÓMO llegaría a esa conclusión? Ese es el tipo de pregunta que buscaba.

Esta no es una pregunta de programación, es una pregunta de administración.
Hay algunas preguntas fáciles de responder y no tienen nada que ver con el software.

1. ¿Cuántas horas trabajas?
2. ¿Cuántas horas deberías estar trabajando?
3. ¿Se están cumpliendo los plazos?

Entonces sigue esta lógica:

• Si 1> 2, necesita más personas o plazos menos agresivos.
• Si 1 <2, necesita menos personas o más iniciativas.
• Si no se cumplen los plazos y 1> = 2, necesita más personas.
• Si no se cumplen los plazos y 1 <2, debe despedir a alguien.

Esta es una simplificación excesiva que tiene dos defectos evidentes.

• Las personas no son creadas iguales.
• Hay maneras de hacer que la gente produzca más (actualice su computadora o algo así).

Pero se entiende la idea.