¿Es cierto que los ingenieros de software profesionales producen solo de 50 a 100 líneas de código por día?

AFAIK LOC es una de las métricas más inútiles para medir la productividad.

Dejando de lado la diferencia en el nivel de abstracción de los lenguajes de programación que hace que la comparación directa de LOC escrita sea en gran medida irrelevante, LOC por sí solo no siempre se traduce en la grandeza de un programa.

Un bucle for es casi siempre mejor que una iteración de despliegue manual, sin embargo, las frases crípticas suelen ser perjudiciales para los desarrollos a largo plazo. No hace falta decir las refactorizaciones que reducen las hinchazones y las duplicaciones en la base del código. ¡Puedes ser ultra efectivo eliminando el código !

En pocas palabras, la profesionalidad se manifiesta por los resultados de calidad a pesar de las limitaciones de tiempo y recursos, el LOC solo apenas tiene sentido para la mayoría de nosotros.

En mi experiencia, eso es bastante cercano y posiblemente incluso un poco generoso. Pero eso es usar una metodología de conteo que elimina los comentarios y mucho espacio en blanco. Entonces, 100 LOC “contables” en realidad podrían traducirse a 300 – 400 LOC físicas (a menos que esté escribiendo código que no sea legible por humanos).

Por ejemplo, el proyecto de código abierto NHibernate tiene alrededor de 500k LOC físicos según github, pero el contador LOC de Visual Studio muestra solo unos 65k (ya que elimina los comentarios y los espacios en blanco).

Usando el último método de conteo, la mayoría de los desarrolladores parecen producir alrededor de 50 LOC por día. Un desarrollador estrella de rock (el mejor en un equipo de 100 desarrolladores) podría producir 250 LOC por día.

Pero, LOC no es una medida perfecta, ya que un desarrollador novato podría producir un alto recuento de LOC simplemente copiando / pegando código para lograr la reutilización del código frente a un enfoque OO bien diseñado sin código duplicado. También es generalmente el caso de que los desarrolladores novatos presenten soluciones de “fuerza bruta” a los problemas, lo que requiere más código que una solución elegante producida por un desarrollador más experimentado.

Lo que pasa con los promedios es … puedes congelarte el trasero y tu cabeza podría arder … pero en promedio eres cálido y acogedor.

Entonces, en promedio, en una semana, un profesional puede pasar 6 días pensando en el problema, diseñando la solución, planificando de la mejor manera y, en el día 7, escribe una solución perfectamente sólida en 700 líneas de código. Todo escrito en una sola toma.

En promedio, escribió 100 líneas de códigos por día, durante esa semana.

Es como decir que un pintor profesional golpea 200 veces con un pincel al día.

O un bajista profesional toca la cuerda 200 veces al día.

O un chef profesional usa el salero 80 veces al día.

O un escritor profesional escribe 800 palabras al día.

Hola, hay un ejemplo perfecto. Un escritor profesional puede estar días y días sin escribir una sola palabra, y cuando “golpea”, escribes como el diablo. Porque, los trabajos creativos (como escribir o programar) solo se miden por el resultado FIN. A nadie le importa cómo se hizo.

Si trabaja en una fábrica, o es mecanógrafo, entonces se mide por la productividad en unidades. Puedes decir, para un mecanógrafo, que escribes en promedio 50 palabras por minuto, porque lo que se requiere es que escribas FAST. En el caso de un escritor, no se trata de qué tan rápido escribe, sino QUÉ escribe.

No quiero decir que un trabajo como mecanógrafo o en una fábrica no sea importante, ni estoy implicando que las personas que trabajan en esos trabajos no sean creativas. Solo estoy insinuando que la métrica es diferente.

Entonces, yo diría que no, es falso.

Más o menos sí. Es decir, sin contar las líneas en blanco y el código generado automáticamente, y se calcula a lo largo del tiempo de desarrollo completo. En realidad, 50 podría ser incluso mucho para algunos proyectos más complejos.

Existen muchas herramientas que generarán mucho código con solo hacer algunas selecciones. Por ejemplo, el Entity Framework de Visual Studio permitirá a los desarrolladores importar una base de datos existente en un modelo y el sistema creará todas las clases y funcionalidades necesarias para el acceso a los datos. Un ajuste fino lo optimizará un poco más, pero básicamente crearía código sin escribirlo usted mismo.

Y hay muchos otros generadores de código que ayudan en el mundo del Desarrollo rápido de aplicaciones, o RAD.

Pero debe comprender que el proceso de creación de aplicaciones implica algo más que escribir código. Se requiere mucho diseño para que los desarrolladores sepan lo que tendrán que desarrollar. Básicamente, esto implica escribir documentación y dibujar diagramas que fácilmente podrían ocupar la mitad de la tarea del proyecto completo. También está el problema de la corrección de errores, donde un desarrollador podría estar buscando durante dos horas solo para encontrar ese único error que necesita cambiar. Esa es una línea de código en 2 horas … Y las pruebas más la corrección de errores también requieren mucho tiempo.

Escribir el código real es aproximadamente una quinta parte de todo el proceso. Entonces, si un proyecto requiere 125 días de principio a fin, con 8 horas por día, entonces el proyecto tomaría 1,000 horas. Si el código tiene 100,000 líneas de código, eso significa que había alrededor de 100 líneas de código por día. Lo más probable es que el proyecto tenga menos código, especialmente si no cuenta líneas en blanco o código generado automáticamente.

De todos modos, es una mala forma de medir el rendimiento de los desarrolladores. Si desea ver su rendimiento, tendrá que hacer revisiones de código.

Comencé a escribir código nuevamente, e hice unas buenas 60 líneas de código hoy. Eso incluyó la lectura de alrededor de 80–200 páginas de documentación, un montón de manejo de errores y un montón de configuración e investigación. Sin embargo, si realmente mira el código, notará que el 90% de él era repetitivo de los ejemplos.

Mañana espero incluir las 25-30 líneas que realizan notificaciones push … y espero que la mayor parte sea un código sólido basado en los ejemplos del proveedor.

Como la gente ha mencionado, LOC es una métrica algo pobre. Una métrica mejor, pero menos cuantificable es “cosas que hiciste hoy. Según esa medida, hice un par de cosas de trabajo hoy: mi función lambda está a medio camino (2 de 3 cosas que debe hacer están hechas), dos correcciones a una herramienta de implementación (2), algo de soporte de implementación de producción (2), otra cosa lambda que estaba esperando una solución del proveedor (1), y revisó un documento UX (1). Eso fue 7 cosas hoy, lo cual es bastante bueno.

Tomaré profesionales para insinuar palabras eficientes, adeptas, capaces, reflexivas y otras como esas.

Un ingeniero tomará tiempo para comprender la funcionalidad, transponer esa funcionalidad a los requisitos, el arquitecto, el diseño, el cronograma y crear pruebas de aceptación. A menudo, las líneas de base de estos documentos necesitarán revisión, y no es raro que sean documentos vivos para gran parte del proyecto, dependiendo de los cambios solicitados. Y luego codifican. Todo esto necesitará revisiones, y las revisiones de código obviamente se llevarán a cabo durante todo el proceso de desarrollo … y el desarrollador también pasará tiempo haciendo revisiones para otros (agregue no un tirón a la oración principal).

Tal vez un líder técnico hará la mayor parte del trabajo de planificación, pero un ingeniero de software profesional debería validar y comentar mínimamente los diseños de alto nivel con respecto a los requisitos y la arquitectura, proporcionando retroalimentación del cronograma, preferiblemente haciendo el diseño de bajo nivel ya que van a hacer el código, y hacer y responder a las revisiones.

Con esas consideraciones, 50 a 100 líneas de código por día en promedio podrían estar bien … o podría ser demasiado o podría ser muy poco. Depende de la complejidad, el calendario, muchas cosas, estoy de acuerdo con todos los que comentaron por qué SLOC no es una buena medida, pero particularmente debido al proceso necesario para llegar a la codificación.

Dicho todo esto, muchos ingenieros de software saltan al código, a veces a pedido de sus gerentes que no quieren perder el tiempo. No conozco las estadísticas sobre la frecuencia con la que funciona con éxito, pero he visto muchos ejemplos de giros incorrectos que tuvieron un tiempo significativo y / o costos de calidad debido a la falta de planificación. Pueden hacer mucho más de 50 a 100 líneas de código promedio durante la vida del proyecto, pero no es muy profesional hacer algo nuevamente debido a una mala planificación.

En realidad, es un poco menos de 50 líneas . He visto y participado en algunos estudios sobre esto y el consenso general es que una “línea de código” debe cumplir con algunos atributos clave para ser contados en primer lugar. Si escribe 500 líneas que se reemplazan por 5 líneas de código escritas al día siguiente, sus 500 no cuentan. También debe considerar todos los tipos de programadores y escritores de código, algunos de los cuales pueden tomar un año para escribir 6 líneas de código (como en los algoritmos avanzados). Y hay tanto código por ahí que está en modo de mantenimiento donde solo está reparando errores o mejorando el código. Estos programadores generalmente reducen y eliminan el código escrito previamente, lo que lo elimina del número promedio de líneas que se consideran escritas.

Muchos estudios muestran que los desarrolladores solo escriben 6 o 7 líneas por día en promedio.

“Si una línea de código cae en el bosque …”

Como regla general, no, eso es demasiado poco.

En mi pantalla de 22 ″ estándar de pantano, puedo ver unas 50 líneas de Java en mi IDE antes de tener que desplazarme, por lo que 50 líneas es realmente una * cantidad increíblemente pequeña de código.

Solo mirando mi último proyecto, son alrededor de 30,000 líneas de Java y alrededor de 3,000 líneas de Objective-C, así que digamos 33,000 líneas. La confirmación inicial en GitHub fue el 22 de mayo, así que básicamente hace 3 meses, digamos 90 días, o 65 días, quitando los fines de semana.

Parecen unas 500 líneas por día, aunque probablemente esté bastante sesgado por el hecho de que a veces trabajo los fines de semana, además me mudé de casa en ese momento, así que estuve fuera de acción por un tiempo. Tampoco incluye las 4000 líneas de FXML y los más de 50 archivos XIB. Puede que no sean “líneas de programación” como tales, pero a veces todavía lleva tiempo, bastante tiempo.

Sin embargo, eso realmente no cuenta toda la historia.

Escribir software puede ser rápido, o puede ser un verdadero trabajo. Cuando comencé el proyecto por primera vez, podría haber estado cometiendo un par de miles de líneas por día, pero ahora, cuando llega a su fin, puede ser un poco difícil encontrar esos pequeños errores desagradables que he estado posponiendo hasta ahora. O tal vez estoy haciendo cosas realmente aburridas, y tomo descansos frecuentes en Quora, por puro aburrimiento.

Algunos días, cometer 50 líneas es un gran día, y he encontrado y solucionado un error grave. En otros días, puede que haya eliminado 1000 líneas, porque he encontrado una mejor manera de hacer algo, o tal vez me di cuenta de que mi idea inicial era una mierda.

Algunos días, 50 líneas son terriblemente improductivas.

Realmente depende de tu proyecto. Algunos, probablemente la mayoría de los proyectos, 50 líneas al día no serán suficientes, probablemente no sean suficientes. Sin embargo, en algunos proyectos, podemos tener un día excelente y productivo con solo producir 50 o 100 líneas.

Creo que una estadística de 50 a 100 líneas por día se asemeja más al tamaño del proyecto / tiempo empleado y sale con un número como ese, pero, por supuesto, tenemos que tener en cuenta las reuniones, el cambio de los objetivos del proyecto, la fatiga al final de un proyecto, cuando el entusiasmo es bajo y las correcciones de errores ya no son solo fruta fácil.

A veces solo necesitarás escribir 50 o 100 líneas en un día, pero tendrás que ser capaz de hacer un poco más.

Esta es la pregunta equivocada.

Los programadores no están trabajando en una fábrica donde manejan una máquina que tiene un rendimiento esperado. No tienen las materias primas dispuestas frente a ellos y tienen que producir una cierta cantidad de productos en un día y, si no lo hacen, tienen que justificar por qué no lo hicieron.

Sí, algunos programadores producen más código que otros durante un día.

Algunos días codificaré cientos (si no miles) de líneas de código.

Otros días escribiré menos de 50.

Otros días simplemente borraré el código o cambiaré los nombres de los parámetros, corregiré los errores que son simplemente errores lógicos, etc.

Es una métrica que no es importante. La métrica que debe analizar es cuántos objetivos han logrado en un día. ¿Lograron el objetivo que se les propuso o tuvieron problemas? Si no lograron el objetivo, ¿cuál fue la razón detrás de esto?

Concéntrese en los objetivos, no en el número de líneas de código que no es una métrica importante.

¡Honestamente, es tan estúpido pensar que la productividad de los programadores se puede medir en líneas de código!

Mi línea de código hoy: -20

Hoy hice una corrección de errores y algunas refactorizaciones, para hacer que un código sea más legible. Dejé caer / reemplacé varios métodos y al final del día el proyecto tenía aproximadamente 30 líneas menos.

Solo un consejo para todos los que piensan que necesitan producir una cierta cantidad de líneas:

Simplemente cambie la configuración del formateador y puede duplicar el recuento de líneas con

alt-cmd-L (IntelliJ) 😉

Al final del día, es mucho más importante que su código sea legible, robusto, escalable y libre de errores.

Aquellos que producen una gran cantidad de código podrían haber copiado el código de algún tutorial en línea sin siquiera comprenderlo por completo.

Desafortunadamente, no tengo ninguna referencia a mano, pero he oído hablar de algunos estudios que sugieren que en términos de código entregado en el producto final, la productividad promedio es del orden de 1-3 líneas de código por día por programador. Sí, eso es entre uno y tres.

Obviamente, todos escriben mucho más código que eso, pero gran parte de eso se reescribe tras reescrituras de reescrituras, por lo que el impacto real en el producto terminado es (también en mi propia experiencia) muy pequeño.

El problema de la programación es que cada pequeño detalle importa. Puede destruir un programa de línea multimillonaria de mil millones de dólares con un solo error tipográfico. Un ejemplo famoso fue un satélite anterior que se perdió en el espacio porque el programador había usado un punto en lugar de una coma en el lugar equivocado en un bucle FORTRAN do en el software de guía.

Además, una parte importante del problema de escribir un programa es averiguar qué debe hacer el programa. Como tal, la programación es mucho más un viaje de aprendizaje que una resolución de rompecabezas en la que intentas descubrir la única solución correcta. A medida que aprende más sobre el problema que está atacando, también se vuelve más sabio sobre cómo hacerlo y qué se supone que debe hacer el programa.

¿Es cierto que los ingenieros de software profesionales producen solo de 50 a 100 líneas de código por día?

Es completamente inútil medir la productividad de un ingeniero de software en líneas de código, simplemente porque las líneas de código varían demasiado con la complejidad de la tarea a resolver.

Si tiene que escribir un algoritmo complejo, horas de pensamiento pueden resultar en solo un puñado de líneas de código, mientras que si la tarea es simple pero extensa, escribirá cientos y cientos de líneas al mismo tiempo.

Entonces, no, eso no es generalmente cierto. Por supuesto, los ingenieros de software más eficientes podrán resolver una tarea con menos código que los menos eficientes, pero eso varía mucho con la tarea. Además, a veces los ingenieros de software optan por resolver una tarea en más líneas de código de las realmente necesarias para mejorar la legibilidad del código.

Por lo tanto, básicamente no existe una conexión generalmente válida entre las líneas de código en un momento determinado y la experiencia de un ingeniero de software.

A veces. Hay aproximadamente dos fases principales en la programación, construcción y mantenimiento. Cuando construyes, tiendes a escribir mucho código, porque sabes lo que estás haciendo. Cuando realiza el mantenimiento, tiende a escribir una pequeña cantidad de código, porque no sabe lo que está haciendo.

Cuando realiza el mantenimiento, esencialmente necesita ir a una montaña de código posiblemente desconocido y encontrar la lista de cosas que necesita cambiar, ya sea para agregar funcionalidad o corregir un error. El paso 1, por supuesto, es reproducir el error, si es un error. Eso no es necesariamente fácil de hacer, y puede requerir mucha configuración. El paso 2 suele ser tratar de entender el código. Por supuesto, el código es increíblemente complicado y, a menos que lo haya escrito usted mismo, no sabe cómo está estructurado. Entonces, con suerte, la persona que * escribió * ese código está disponible para que usted haga preguntas; de lo contrario, debería hablar con las personas que se ocupan de esa parte del código para obtener una vista general. Después de haber hecho todo eso, el Paso 3 es que debes rastrear el error en el código. A veces esto es fácil; puede detectar el problema de inmediato y agregar la solución necesaria. A veces necesitas cavar y cavar. Algunas veces el problema es estructural y requerirá mucha reescritura para solucionarlo; a veces el problema está en algún lugar casi completamente ajeno al lugar donde estás buscando. Tal vez pensó que el problema era profundo en el servidor REST, pero finalmente decide verificar el cliente del navegador y descubrir que la causa fue un error tipográfico. O bien, todas sus pruebas pasan un día, pero todas comienzan a fallar al siguiente, y finalmente se da cuenta de que los datos de muestra que ha estado utilizando durante todo el año en realidad tenían una fecha de finalización y simplemente la alcanzó. Luego, después de tres largos, largos pasos, el Paso 4 es codificar la maldita solución. El paso 5 es probar ese código, tanto manualmente como escribiendo / arreglando pruebas automatizadas. El paso 6 es enviar sus cambios. Esperemos que todo funcione ahora, porque de lo contrario volverá al paso 1, ¡aunque el paso 2 será mucho más fácil la segunda vez con la misma parte del código!

En todo esto, solo está escribiendo código en el paso 4 y quizás en el paso 5. Y la solución puede ser una solución de una línea. Es solo que te tomó mucho trabajo * encontrar * esa línea que necesitabas arreglar. Mientras tanto, tenía su reunión semanal del equipo, su scrum diario, varias personas se le acercaban para pedirle ayuda en * su * Paso 2, y así sucesivamente.

Esto se debe a que el desarrollo de software es esencialmente una tarea intelectual. La programación real es bastante simple. La parte difícil es descubrir qué hacer en primer lugar y cómo hacerlo funcionar. Una vez que comprenda eso, la solución podría ser simple, pero el aprendizaje que tuvo que tener lugar de antemano no fue tan simple.

Un día estaba arreglando otro error en el proyecto. No era dueño del código antes, ya que lo heredé de los programadores que abandonaron el proyecto (realmente me pregunto por qué). Para solucionarlo, he eliminado 500 líneas de código de la función, convirtiéndolo en 100 líneas en lugar de 600. ¿Eso cuenta como código “producido”? ¿O es más como ” reducido “?

Mira, cuanto más código escribes, más código necesitas mantener y es más fácil introducir un error porque, bueno, las personas no son robots. Si necesita copiar y pegar 500 líneas de código y cambiar 50 de ellas, sería más probable que se introduzca un error que si solo necesita copiar 10 líneas y editar un par de caracteres.

Entonces, refactorizar es muy importante. Y al refactorizar me refiero a eliminar el código antiguo, obsoleto y poco confiable.

Además, permítanme explicar cómo es centrarse en la cantidad de código en lugar de resolver los problemas.

El proyecto en el que estoy trabajando tiene más de 160,000 líneas de código (controladores: 22,000; modelos: 15,000; ver plantillas (html + javascript en línea): 95,000; javascript: 27,000) en este momento. Se inició hace unos 2 años. Me uní hace un año.

Hace 3 días me dieron la tarea de implementar una nueva barra lateral usando un tema de pago html5 genial y pagado que quería tener en su sitio web. El problema es que esta plantilla no se pudo agregar fácilmente porque todos los archivos de plantillas de vista que tenemos son en realidad páginas HTML completas con etiquetas y . Cada uno de ellos. Unas 210 vistas en total. Los desarrolladores simplemente copiaban los archivos y cambiaban las etiquetas , al crear una nueva página. Así que decidí terminar con esta locura y no hay otra forma de hacerlo, todavía tengo que cambiar cada plantilla. Entonces, para cambiar una página, necesito pasar 20–80 minutos porque tengo que:

1. Cree 3 archivos: encabezado, contenido, scripts, un par de segundos
2. Coloque el contenido de la etiqueta en la cabeza, en el contenido, el código de secuencia de comandos en línea en el archivo de secuencias de comandos – 3-5 minutos
3. Cambie el código del controlador para usar el sistema de diseños básicos que he implementado en 2–3 horas. – 1-3 minutos
4. Ejecute la página y vea si hay problemas de CSS / Javascript, realmente use la página y pruebe el comportamiento. Aparecerían porque, bueno, la nueva plantilla tiene CSS y alguna API de Javascript que entraría en conflicto con el código CSS existente y las bibliotecas JS. – 2 a 5 minutos
5. Solucione errores de CSS / JS: 10–70 minutos. Los cambios podrían ser desde la simple eliminación de la biblioteca existente del archivo de cabecera (como el complemento jquery datatables) para completar la reescritura de características.

Entonces, cuando le dije al cliente que tomaría 210 (plantillas) * 80 (minutos) = 280 horas (estimación superior) para implementar solo una nueva barra lateral + barra superior, ¡estaba realmente enojado y dijo “tiene que haber una manera más rápida”! Y no pude hacer nada porque el 90% del proyecto ya era así, antes de entrar en él. El cliente no quería pasar el tiempo “refactorizando” y no podía hacer esto con mi propio tiempo libre porque, bueno, yo también tengo una vida. Entonces, al final tuvimos que poner la función en espera.

La moraleja de la historia es que escribir más o menos líneas de código es absolutamente irrelevante. Lo que importa son sus decisiones sobre tomar este u otro camino. Algunos de ellos podrían ser bastante malos (como no usar ningún sistema de plantillas / diseños durante mucho tiempo desarrollando una aplicación web importante). Solo necesitas hacer tu trabajo. La refactorización iterativa y la escritura de código bueno y reutilizable (consulte la sección DRY – Don’t Repeat Yourself) es de lo que se trata el desarrollo profesional de software, no de la cantidad de líneas que escribe por día.

¡Depende mucho de dónde y cómo estés trabajando! Leí que en al menos una versión de Windows, los desarrolladores solo producían alrededor de 1000 líneas de código al año debido a la complejidad del producto y porque el nivel de proceso es muy alto. Pero hay unos pocos miles de desarrolladores, por lo que juntos todavía producen millones de líneas de código por año.

Pero comprenda que Windows es un caso extremo: un producto con miles de desarrolladores y una base de código que ya debe estar cerca de cien millones de líneas de código.

En el otro extremo, en un día y medio la semana pasada escribí 750 líneas de código en un divertido proyecto paralelo mío. No hubo gastos generales del proceso, ningún cliente cambió las cosas, no hubo compañeros de trabajo rompiendo la construcción.

Debe tener en cuenta que en un día determinado, al menos un buen día, podría eliminar más líneas de código de las que escribo. Durante una semana determinada, podría haber agregado aproximadamente 50 líneas por día, pero probablemente se eliminaron 2000 líneas, así que no. Esta no es una estimación correcta. En cualquier día, con suficientes tareas, escribo cientos de líneas de código todos los días, incluso mucho más que eso algunos días, y no soy lo que llamarías un programador rápido.

Historia divertida. Un gerente del grupo ealy Mac quería cuantificar cuán buenos eran sus programadores y el más productivo obtendría las mayores bonificaciones, etc. Bueno, si los programadores saben una cosa más que otra cosa, son los patrones. Rápidamente la gente vio que después de una semana muy agitada les pagaban más. Bueno, esto fue contraproducente una vez que descubrieron que estaba vinculado al número de líneas agregadas, por lo que comenzaron a hacer comentarios multilínea, rodeando los comentarios con líneas hechas de ***** y así sucesivamente. Entonces, un día, Bill Atkinson, quien escribió hypercard, dibujó rápidamente el marco para dibujar en la pantalla en Mac y Apple Lisa, entre otros, un súper programador, escribió en su informe “TPS”, eliminó 20 000 líneas de código hoy, bueno, después de eso se canceló el sistema de bonificación.

Medir líneas de código e igualar eso con lo productivo que es un programador es, con mucho, la forma más estúpida de hacerlo. ¿Primero escribe algo, luego lo hace más pequeño, mejor, más rápido, menos errores y le pagan menos?

Otra historia famosa sobre este tipo de estupidez, es cómo IBM quería pagarle a Microsoft por escribir OS / 2, por líneas de código, bueno, Microsoft hizo su misión de cancelar ese sistema, y ​​lo hicieron.

En los viejos tiempos me metí en problemas porque mi equipo estaba produciendo -200 líneas de código por semana mientras agregaba una funcionalidad significativa y eliminaba errores.

Además, ¿qué es una línea de código de todos modos? Escribe algo en ensamblador, básico o C.
Ahora reescríbalo en Python, Ruby, Javascript o Clojure.

Los lenguajes modernos requieren menos líneas de código para realizar grandes trabajos, y la mayoría del código que comprende un producto son bibliotecas importadas (generalmente de código abierto, a veces comercial o parte de la biblioteca estándar incorporada del lenguaje).

Puedo hacer más en una “línea” de comprensión de listas de lo que solía hacer en una página de C.

Entonces, esa pregunta es probablemente obsoleta, probablemente no tome tantos.
O, si es cierto, probablemente sea una pena: alguien está escribiendo MUCHO más código del necesario para hacer un trabajo y tendrá que mantener ese código durante años a un costo considerable.

Menos es mejor.

En lugar de contar las líneas de salida, ¿qué tal si todos nos concentramos en los resultados: personas ayudadas, trabajos más fáciles, errores evitados, industrias revitalizadas, cargas de trabajo gestionadas, decisiones mejor tomadas debido a los datos?

Creo que hoy encontrará más personas que se ven más afectadas positivamente por más software que nunca. Eso es productividad. Las líneas de código no tienen sentido.

Puede escribir mucho más si no planea optimizar, probar exhaustivamente o admitir el software.

Si el software no tiene un gran impacto, y es como una lista de muchos hechos, y usted tiene TOC, puede producir mucho.

Conozco a un tipo que dijo que escribió 100 mil líneas al año. Es una especie de TOC y deshonesto al mismo tiempo. Pero, se supone que es este genio que se graduó de Cal Tech. En algún momento de su vida, probablemente era bastante brillante.

Siempre puede subcontratar una compañía de mantenimiento para su código y culparlos con frecuencia cuando intenta mantener el contrato de soporte en su lugar. Esto es lo que hacen muchas empresas.

Escuché que son menos de 22 después de todo lo dicho y hecho.

Entonces, algunos algoritmos que las personas esperan medio siglo (porque tienen que ser descubiertos) tienen solo unas pocas líneas de código. Estos se usan muchas veces, es decir, tienen un gran impacto.

Algunas veces, he escrito un par de miles de líneas en una semana con la idea de que el software era una especie de borrador, primer prototipo. A partir de ese momento, el programa se hace pedazos, se teoriza, etc. Pero estoy seguro de que mantener esa tasa produciría grandes cantidades de basura.

(A menudo es difícil decirle a los gerentes que el código que escribió fue para destruirlo. No lo entienden. Piensan que debería funcionar como un nuevo Cadillac del distribuidor. Por supuesto, nadie gastó nada tiempo diseñando o construyendo el auto.)

He escuchado esos números antes que yo, ya en los años 80. Me interesaría ver la fuente de esa información, y si aún se aplica hoy o no. Las mejores herramientas han aumentado considerablemente la productividad del programador desde la década de 1980.

Digo esto porque una revisión rápida de mi copia de “The Mythical Man-Month” (Frederick P. Brooks, Jr. Copyright 1975 de Addison-Wesley Publishing Company) muestra que en la última mitad de la década de 1960 los estudios que cita el Sr. Brooks ¡muestra una productividad promedio del programador de 1200 a 2400 líneas de código por año!

Obviamente, hemos superado el tipo de productividad ahora (debido principalmente a las herramientas modernas), por lo que creo que las líneas “50 a 100” por día pueden haber aumentado en algunas áreas de aplicación, aunque cuando se trata de sistemas de “nivel muy bajo” código “50 a 100 líneas por día parece un número justo, probablemente más cerca de 50 que de 100.

Recuerde que esto no es simplemente escribir esas líneas de código. Este es un “promedio” en el transcurso de un proyecto e incluye todo lo que el programador debe hacer durante el curso del proyecto, como:

• Requisitos de estudio
• Diseño
• Codificación
• Pruebas
• Depuración
• Documentación
• Asistiendo a reuniones
• etcétera etcétera.

Sumando el tiempo total que le toma a un programador hacer todo lo que necesita para un proyecto de software, luego dividiendo eso por la cantidad de líneas de código que produjeron, una tasa de 50 líneas de código “entregable” por día es en realidad una muy buena número.