¿Cuántas líneas de código puede producir un desarrollador de C # por mes? [cerrado]

Un ejecutivo de mi lugar de trabajo me preguntó a mí y a mi grupo de desarrolladores la pregunta:

¿Cuántas líneas de código puede producir un desarrollador de C # por mes?

Un antiguo sistema debía ser portado a C # y le gustaría esta medida como parte de la planificación del proyecto.

De alguna fuente (aparentemente acreditable) recibió la respuesta de "10 SLOC / mes " pero no estaba contento con eso.

El grupo acordó que esto era casi imposible de especificar porque dependería de una larga lista de circunstancias. Pero podríamos decir que el hombre no se iría (o estaría muy decepcionado con nosotros) si no se nos ocurre una respuesta que lo satisfaga mejor. Así que se fue con la respuesta muchas veces mejor de "10 SLOC / día "

¿Se puede responder esta pregunta? (de improviso o incluso con algún análisis)

Pregúntele a su ejecutivo cuántas páginas de contrato puede escribir su abogado por mes. Luego (con suerte) se dará cuenta de que hay una gran diferencia entre escribir un contrato de una sola página y escribir un contrato de 300 páginas sin lagunas ni contradicciones. O entre escribir un nuevo contrato y cambiar uno existente. O entre escribir un nuevo contrato y traducirlo a un idioma diferente. O a un sistema legal diferente. Quizás incluso esté de acuerdo en que "páginas de contrato por unidad de tiempo" no es una muy buena medida para la productividad de los abogados.

Pero para darle una respuesta a su pregunta real: en mi experiencia, para un nuevo proyecto, unos pocos cientos de SLOC por día y desarrolladores no son infrecuentes. Pero tan pronto como aparezcan los primeros errores, este número disminuirá considerablemente.

¿Cuántas líneas de código puede producir un desarrollador de C # por mes?

Si son buenos, menos de cero.

Corre hacia el otro lado ... Ahora.

LoC es una de las peores métricas que puedes usar.

Los malos desarrolladores pueden potencialmente escribir más LoC al día que los buenos desarrolladores, pero producen código basura.

Dependiendo de la complejidad del código, la portabilidad se puede realizar mediante procesos de automatización que darían como resultado grandes cambios de más de mil + LoC por día, mientras que las secciones más difíciles donde las construcciones de lenguaje son códigos muy diferentes se pueden portar a 100LoC por día.

Envíelo a leer la página de Wikipedia en SLOC . Si da algunos ejemplos agradables y simples de por qué es una métrica tan pobre.

La respuesta correcta: no ...

Este ejecutivo debe ser educado, que SLOC no es una medida válida para el progreso del análisis.

La respuesta descuidada: cualquier número que pueda hacer.

Solo dale un número, tú y tu equipo pueden fácilmente hacer ese número de todos modos. (Al poner a menos línea, líneas vacías, comentarios, etc., solo para permitir que este tipo continúe viviendo en su mundo de fantasía, persiga a otro equipo y continúe el ciclo reforzado de la miseria que hace una historia para todos los días.

No es agradable, pero factible.

A primera vista, esta pregunta parece absolutamente estúpida, y todos aquí respondieron a la estúpida parte de C # LoC solo. Pero hay un matiz importante: se trata de un rendimiento de portabilidad . La forma correcta de hacer esta pregunta es preguntar cuántas líneas de código del proyecto fuente (el que se está transfiriendo) puede manejar un desarrollador dentro de una unidad de tiempo determinada. Es una pregunta perfectamente justificada, ya que se conoce el número total de líneas de código, y es exactamente la cantidad de trabajo por hacer. Y la forma correcta de responder a esta pregunta es recopilar un poco de datos históricos: trabajar durante, por ejemplo, una semana y medir el rendimiento de cada uno de los desarrolladores.

Solo tengo una cosa que decir:

"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

Después de eso, puede argumentar que Bill Gates no sabía cómo hacer un software exitoso;)

Nota: ¡SLOC es una muy buena medida de la complejidad de la base de código!

I 
can
write
large
numbers
of
lines
of
code
per
month.

Proporcional al número de palabras, de hecho.

¿Ves mi punto?

Podría tener una postura ligeramente diferente al respecto, pero creo que podría entender por qué el ejecutivo buscaba esta información si actualmente está haciendo la planificación del proyecto. Dado que es difícil estimar cuánto tiempo llevará un proyecto, uno de los métodos que se utilizan (ver: Estimación de software: desmitificar el arte negro ) es estimar cuánto tiempo llevará el proyecto en función del número de SLOC en proyectos similares y ahora los desarrolladores pueden producir en promedio. En la práctica, esto se debe hacer utilizando registros históricos que el grupo tiene a mano para proyectos similares con los mismos desarrolladores o desarrolladores similares.

Sin embargo, no vale nada que estas estimaciones estén destinadas solo a la planificación básica del proyecto y en realidad no pretenden establecer el ritmo de los desarrolladores en el proyecto porque las cosas cambian de un día a otro. Por lo tanto, la mayor parte de lo que lee sobre el uso de SLOC como herramienta de estimación es que son buenos a largo plazo si ya tiene un buen conjunto de conocimientos, pero pésimo para el uso diario.

En general, es una mala idea llamar a su jefe un idiota, por lo que mis sugerencias comienzan con la comprensión y la discusión de las métricas, en lugar de rechazarlas.

Algunas personas que en realidad no se consideran idiotas han utilizado métricas basadas en líneas de código. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan y Steve McConnell los usaron. Probablemente los haya usado, aunque solo sea para decirle a un colega, este módulo de Dios tiene 4000 líneas, debe dividirse en clases más pequeñas.

Hay datos específicos relacionados con esta pregunta de una fuente que muchos de nosotros respetamos.

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

Sospecho que el mejor uso de la línea de código por hora de programador es mostrar que durante la vida del proyecto, este valor comenzará bastante alto, pero a medida que se encuentren y arreglen los defectos, se agregarán nuevas líneas de código para resolver problemas que no formaban parte de las estimaciones originales, y las líneas de código eliminadas para eliminar la duplicación y mejorar la eficiencia mostrarán que LOC / hr indica otras cosas además de la productividad.

• Cuando el código se escribe rápido, descuidado, hinchado y sin ningún intento de refactorización, la eficiencia aparente será máxima. La moraleja aquí será que debes tener cuidado con lo que mides.
• Para un desarrollador en particular, si está agregando o tocando una gran cantidad de código esta semana, la próxima semana puede haber una deuda técnica que pagar en términos de revisión de código, prueba, depuración y retrabajo.
• Algunos desarrolladores trabajarán a una tasa de producción más consistente que otros. Se puede descubrir que pasan la mayor parte del tiempo obteniendo buenas historias de usuarios, se dan la vuelta muy rápidamente y hacen las pruebas unitarias correspondientes, y luego se dan la vuelta y hacen rápidamente un código que se centra solo en las historias de los usuarios. La conclusión aquí es que los desarrolladores metódicos probablemente tendrán un cambio rápido, escribirán código compacto y tendrán un bajo nivel de retrabajo porque entienden el problema y la solución muy bien antes de comenzar a codificar. Parece razonable que codifiquen menos porque codifican solo después de pensarlo bien, en lugar de antes y después.
• Cuando se evalúa el código por su densidad de defectos, se encontrará que es menos que uniforme. Algún código explicará la mayoría de los problemas y defectos. Será un candidato para reescribir. Cuando eso suceda, se convertirá en el código más costoso debido a su alto grado de retrabajo. Tendrá las líneas brutas más altas de recuentos de código (agregados, eliminados, modificados, como se podría informar de una herramienta como CVS o SVN), pero las líneas netas más bajas de código por hora invertidas. Esto puede terminar siendo una combinación del código, ya sea implementando el problema más complejo o la solución más complicada.

Independientemente de cómo resulte el debate sobre la productividad del programador en líneas de código, encontrará que necesita más mano de obra de la que puede permitirse y el sistema nunca se completará a tiempo. Sus herramientas reales no son métricas. Son el uso de una metodología superior, los mejores desarrolladores que puede contratar o capacitar, y el control del alcance y el riesgo (probablemente con métodos ágiles).

Dale una mejor métrica para trabajar

En lugar de LOC , explique que esta es la peor métrica para usar. Entonces dale una alternativa:

Número de funciones / características por función / solicitudes de función -> NOFF / RFF

Es posible que deba agregar una ponderación / normalización además de NOFF / RFF, para atender las cantidades de solicitudes por semana.

:) claramente lo anterior está hecho, pero cualquier cosa, es mejor que SLOC ...

Les puedo decir que una carga de contratistas para un gran proyecto escribió 15000 LOC (cada uno) en un año. Esa es una respuesta increíblemente aproximada, pero fue útil para nosotros ya que tenemos 400,000 C ++ LoC existentes y podríamos descubrir que convertirlo todo a C # nos llevaría unos 26 años-hombre completar. Da o toma.

Entonces, ahora que conocemos el orden aproximado de magnitud, podemos planearlo mejor: obtener 20 desarrolladores y estimar un año de trabajo para ellos sería lo correcto. Antes de contar, no teníamos idea de cuánto tiempo llevaría migrar.

Entonces, mi consejo para usted es que revise todo el código que ha escrito en un período de tiempo específico (tuve la suerte de tener un proyecto nuevo con el que trabajar), luego ejecute una de las muchas herramientas de métricas de código en él. Divide el número por el tiempo y puedes darle una respuesta precisa: cuánto LOC escribes realmente por día. ¡Para nosotros, eso salió a 90 LOC por día! Supongo que tuvimos muchas reuniones y documentación sobre ese proyecto, pero creo que también tendremos muchas reuniones y documentación sobre el próximo :)

Suena correcto.

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Si tiene en cuenta la depuración, la documentación, la planificación, etc. Tiene un promedio de aproximadamente 10 líneas de código por día. En realidad, calificaría 10 líneas por día en el lado alto (es decir, un desarrollador muy productivo).

Aunque puede producir un par de cientos de líneas en un solo día (esto no es sostenible). No será un código de calidad hasta que haya agregado toda la documentación de prueba de la unidad y, por supuesto, haya depurado el código después de que la prueba de la unidad muestre los errores. Después de todo lo que has hecho, estás de vuelta en 10.

Supongo que un desarrollador que trabaje con un lenguaje como C # debería poder escribir / generar alrededor de 10K LoC / día. Supongo que podría hacer eso. Yo nunca lo haría.

Lo que quieres de un desarrollador es hacer su trabajo en 10 LoC / día. Menos código siempre es mejor. Muchas veces empiezo produciendo una gran cantidad de código y luego cortando hasta alcanzar la máxima simplicidad, por lo que realmente tengo días con LoC negativos.

En cierto sentido, la codificación es como la poesía. La pregunta no es cuántas líneas puede escribir un poeta, sino cuánto puede transmitir en las 14 líneas de un soneto.

Deje que su gerente lo maneje o comience a buscar trabajo.

Con toda seriedad, podría dedicarle tiempo, lo que puede terminar siendo un esfuerzo inútil al explicarle al ejecutivo los métodos adecuados e inadecuados para medir el progreso de un proyecto hacia su finalización. Sin embargo, en realidad, para qué son los gerentes de ingeniería y proyectos.

Por otro lado, las circunstancias son tales que el ejecutivo en cuestión ES su ingeniero y / o gerente de proyecto. Tienes problemas mucho más grandes y más básicos con los que lidiar, incluso si aún no se han revelado. En este caso, un problema como este puede servir como un "disparo de advertencia" para problemas mayores por venir.

Otras respuestas son correctas, es una pregunta tonta y la respuesta no significa nada. Todo es cierto, pero sé cuántas líneas de código produje en aproximadamente un mes.

Se trata de 3000 líneas de código C # sin XML-doc. Estaba implementando una nueva funcionalidad y terminé con esta cantidad en un mes o un mes y una semana. Es todo lo que terminó en el control de la fuente, se escribió mucho código y luego se refactorizó o eliminó.

Soy un desarrollador de C # y trato de ser bueno en eso, pero no puedo decirte cuán objetivamente bueno soy. Traté de escribir un buen código y puse mucho esfuerzo para que sea fácil de mantener. Solo pongo comentarios una o dos veces en este código.

No sé si son demasiadas o muy pocas líneas de código y debo decir que realmente no me importa. Es un dato sin sentido y no se puede utilizar de forma segura para la extrapolación de ninguna manera. Pero resulta que conozco estos datos, así que decidí compartirlos.

Bueno, llego un poco tarde a esta fiesta, como siempre, pero esta es realmente interesante. Inicialmente tuve el mismo pensamiento que la mayoría de que la pregunta del ejecutivo es tonta. Sin embargo, leí la respuesta de SK-logic y me di cuenta de que es una pregunta sensata formulada sin sentido. O, dicho de otra manera, hay un problema válido detrás de la pregunta.

Los gerentes a menudo deben intentar determinar la viabilidad, la financiación, la dotación de personal, etc. para un proyecto. Este es un problema sensible. Para un puerto directo, una estimación basada en líneas de código de puerto divididas por las líneas de código promedio estimadas por desarrollador por día es atractiva en simplicidad, pero está condenada al fracaso por todas las razones dadas en esta página.

Un enfoque más sensato sería: -

1. Para obtener una estimación inmediata, solicite a los desarrolladores con más experiencia con el código una estimación completa de cuánto tiempo llevará. Es probable que esto sea incorrecto por muchas razones por las que no voy a entrar aquí, pero es lo mejor que podrán hacer desde el principio. Al menos deberían tener una idea de si será fácil en una semana o años, incluso con recursos adicionales. Si se han realizado puertos o trabajos de tamaño similar, podrían usar esto como guía.
2. Estime el puerto por componente para obtener un tamaño total. Deben incluirse tareas que no estén directamente relacionadas con el puerto, como la configuración de infraestructura (máquinas, sistemas de construcción, etc.), la investigación y compra de software, etc.
3. Identifique los componentes más riesgosos del puerto y comience con los primeros. Es probable que estos aumenten la estimación más, por lo que debe hacerse por adelantado si es posible para que haya sorpresas limitadas tarde en el puerto.
4. Realice un seguimiento del progreso con respecto al tamaño realizado en el paso 2 para calcular continuamente la duración esperada del puerto. A medida que el proyecto avanza, esto debería ser más preciso. Por supuesto, el número de líneas de código que se han portado (características en la base de código original que ahora están en el código portado) también se puede usar como una métrica y es realmente útil para garantizar que el producto original se esté portando en lugar de Se agregaron un montón de nuevas funcionalidades geniales sin abordar el puerto real.

Estos serían los pasos básicos, por supuesto, hay muchas otras actividades en torno a esto que son útiles, como investigar herramientas de portabilidad y marcos conectables, crear prototipos, determinar lo que realmente se necesita portar, reutilizar herramientas de prueba e infraestructura, etc.