No hay un promedio para esto, ya que depende de una serie de cosas. Incluiré aquí las que se me ocurren, pero seguro que hay más:
1. La duración y la frecuencia de las reuniones. Si los ingenieros pasan la mitad de su tiempo en reuniones, se escribe menos código
2. Cómo de buenas son las especificaciones dadas para un trabajo. He estado en situaciones en las que he pasado 2-3 horas trabajando con una persona de negocios para entender el problema de negocio que necesito resolver con este código en el que estoy trabajando. Además, lo que una persona de negocios piensa que son buenas especificaciones podría no serlo, debido al nivel de detalle que los programadores informáticos necesitan para traducir un requisito en un código correcto y funcional. (En resumen: pueden necesitar algo de tiempo para entender lo que tienen que escribir)
3. Qué tan bien conoce el ingeniero la base de código / el diseño general de la app. (En resumen: necesitan saber dónde poner el código que necesitan escribir)
4. En qué lenguaje está implementado el sistema. Los lenguajes de bajo nivel, como C++, suelen requerir más líneas de código para conseguir un cuerpo de trabajo, y los lenguajes de alto nivel (como Ruby, Perl y Python) suelen poder empaquetar mucho trabajo en una o dos líneas. (En resumen: los partidos de baloncesto llevan menos tiempo que los de golf, y dependiendo de dónde te presentes -el club de campo o la Y- probablemente tengas que jugar el partido que se ofrece).
5. Si el trabajo del ingeniero's es una nueva funcionalidad añadida al sistema, o bugs (funcionalidad inexplicable o no deseada en la aplicación). Si se trata de un error, un ingeniero podría pasar horas -o días- para averiguar que necesita añadir o eliminar una sola línea de código... o incluso un solo carácter del código fuente. Entorno: ¿el programador se encuentra en un lugar tranquilo donde puede pensar y hacer su trabajo, o la gente está constantemente molestando a "esos informáticos" para que le arreglen la impresora o el último cotilleo de la oficina/juego deportivo?
7. Estado del código: si el cambio solicitado afecta a un sistema clave, el programador puede pasar un poco de tiempo escribiendo y mucho tiempo probando su cambio para asegurarse de que no se rompe nada. Si es difícil ejecutar este código por cualquier razón (estado interno del código, el proyecto está en la vanguardia de algún hardware de vanguardia, o la base de código es simplemente grande), puede tomar algún tiempo para lanzar la aplicación para probar el cambio. Sin embargo, si la base de código está limpia, la funcionalidad del producto puede crecer a un ritmo más rápido que el total de líneas de código en el producto.
Supongo que las pequeñas startups tendrían una mayor proporción de líneas de código escritas que Google, incluso teniendo en cuenta estas cosas, porque hay menos coordinación requerida Y todo lo que Google (o Facebook) hace necesita manejar mil millones de usuarios, pero las pequeñas startups (yo'nunca he oído hablar de Palantir) pueden tener bases de usuarios que miden en los 10.000 o 100.000 - grande sí, pero lo suficientemente grande donde la escala realmente se convierte en un problema? La verdad es que no.
A los programadores casi siempre se les pide que construyan cosas que nunca han construido antes, potencialmente con reglas de negocio que aún no entienden, y/o en entornos interesantes/únicos. Estos factores externos afectan a la cantidad de líneas de código que un desarrollador puede escribir, y los factores internos (la familiaridad con la base de código, el lenguaje en el que está escrito, el estado del código) también afectan a la producción de un ingeniero.
Ejemplo: uno de los proyectos en los que creo que hice algunos de mis mejores trabajos fue un proyecto de Ruby on Rails de 7 ingenieros y 18 meses. Alrededor de un año en el proyecto tuvimos una base de código de alrededor de 10.000 líneas. Este es un código base muy pequeño. ¿Por qué? Porque mejoramos constantemente el estado del código, utilizamos las mejores herramientas posibles, y nuestro proyecto también requería mucha comprensión del dominio del negocio por nuestra parte. Así pudimos escribir una aplicación muy compleja con relativamente poco código.
Nuestro "promedio de líneas de código por ingeniero / mes" probablemente parecía horrible, pero esta historia ilustra por qué las métricas como "promedio de líneas de código por programador" son pobres: muchos ingenieros ven las líneas de código como una futura carga de mantenimiento, y se esforzarán por reducir las líneas de código en sus respectivos proyectos. Es mejor colgar un cuadro en la pared con un solo clavo, frente a colgarlo con una docena.