Eso depende del proyecto. En promedio (todavía no es realmente exacto) un nuevo proyecto oscilará entre 0-10,000 (dependiendo sobre todo de si estás en la arquitectura o en la fase de construcción inicial) mientras que un proyecto realmente antiguo estará en cualquier lugar de negativo (a través de la optimización, refactorización) a 0 (tratando de hurgar y encontrar lo que está pasando para evitar romper algo cuando vas a hacer el cambio) a tal vez unos pocos cientos (la adición de una nueva característica después de un montón de hurgar para asegurarse de que nada se romperá al agregarlo.)
Los trabajos de programación son notoriamente difíciles de poner medidas estandarizadas de cualquier tipo (aunque la notación Big-O hace algo para ayudar en este esfuerzo desde un punto de vista puramente técnico de rendimiento de código para el hardware disponible) ya que estás tratando de cuantificar algo que está tratando de cuantificar algo de una manera abstracta – preguntando «¿cuántas líneas de buen código sería razonable?» estás pidiendo esencialmente construir un sistema completo de Turing para describir otro sistema, para cada escenario posible en el que se pregunte.
Las personas con mucha experiencia en el desarrollo de software suelen ser capaces de acertar en la estimación de un proyecto dentro del 20% si hacen una buena cantidad de investigación de antemano y conocen a fondo todos los aspectos de los sistemas involucrados, pero que por lo general también incluyen un considerable factor de manipulación porque la única cosa que la experiencia realmente enseña en ese sentido es asumir que se está subestimando (entre miles, Todavía no he conocido a un desarrollador que no haya sobreestimado su capacidad para bombear código – típicamente porque todo el mundo asume que todo el proyecto está en un estado de «flujo» mientras se estima, desde los desarrolladores hasta los clientes, pero llegar a ese estado mental en sí mismo tiende a implicar una parte considerable de tiempo y depende de un montón de factores ambientales.)
Como ejemplo extremo de esto: Una vez trabajé para un contratista que escribía software de negocios cuando yo estaba empezando en la industria, después de unos meses tuve lo que pensé que era una comprensión decente de cuánto tiempo tomaría un proyecto similar. Lo estimé, asumiendo que iría más o menos como el anterior (eran casi idénticos, de hecho era la versión 2 del proyecto anterior que se estaba reescribiendo desde cero para facilitar nuevas funcionalidades). Todo iba bien en la fase de arquitectura, entonces un templo hindú alquiló la unidad de al lado y cada 10-30 minutos, cada día, alguien hacía sonar una campana de vaca, se discutió sobre lo molesto que era la campana de vaca, se discutió con la dirección sobre una nueva ubicación a la que trasladarse, se habló de las discusiones de la dirección pidiendo a la gente su opinión sobre nuevas ubicaciones y planos, etc. Pasó un mes y prácticamente no se hizo ningún progreso, hasta el punto de que tuve que empezar a trabajar desde casa porque era incapaz de concentrarme durante más de 10 minutos seguidos sin una interrupción, estaba en una mezcla de pánico pensando que me iban a despedir y sorprendido de que nadie lo hubiera mencionado. Otro mes (esta vez de trabajo productivo) con pocas actualizaciones visibles para el cliente y decidieron empezar con el scope creep, probablemente asumiendo que no había nada importante que cambiar – lo que llevó a tirar enormes segmentos de código existentes, revisar otros, añadir nuevos a la arquitectura, etc. Dos meses y medio más tarde termino el proyecto (la mayor parte del tiempo desde casa, sólo entrando por días con reuniones) y pregunto cómo mi jefe no estaba flipando con que el proyecto se retrasara tanto – resulta que sus décadas de experiencia en software le enseñaron a multiplicar las estimaciones dadas por los desarrolladores por 4.
Más de una década de experiencia en la industria después y he aprendido la moraleja de esta historia: siempre va a haber un cencerro. No se puede estimar en base a su pico ni se puede asumir que no habrá investigación, planificación, reuniones, etc involucradas en un proyecto que restan tiempo a la escritura de código. A su vez, medir el código por el número de líneas escritas es, en realidad, muy parecido a tratar de operar con acciones sobre la base de información puramente técnica: podría funcionar, hasta que sucede cualquier evento y todos sus marcadores técnicos no significan nada.