¿Existen usos válidos conocidos de SLOC para medir la productividad?

54

Tuve una conversación inusual y breve con un arquitecto muy experimentado sobre lenguajes dinámicos y estáticos. Dijo que los datos de la compañía muestran que hay evidencia de una mayor productividad cuando se usan lenguajes estáticos. Tenga en cuenta que es una gran empresa con una larga historia. Para mi sorpresa (y la de otros), la métrica que utilizó fue la adición de líneas de código.

Rápidamente descartó las objeciones con respecto a la métrica diciendo que dentro de una misma compañía, con una cultura, línea de negocio similar y con suficientes datos, las diferencias (en cuanto a situaciones y capacidades únicas de los individuos) se mezclan lo suficiente como para que la métrica SLOC sea útil para comparar la productividad de herramientas e idiomas.

Si bien no creo que esta afirmación esté respaldada por un riguroso análisis estadístico, ¿hay alguna evidencia en la industria que respalde esta línea de pensamiento?

sevo
fuente
25
La productividad es el término equivocado. Ese término se define como la cantidad de trabajo realizado en un período de tiempo, que no está relacionado con el código producido.
Frank Hileman el
25
Una persona sabia dijo que deberíamos considerar las líneas de código no como "construidas" sino como "gastadas"; en ingeniería física cuando consideramos el recuento de piezas y la longitud de la lista de materiales, menor es mejor.
pjc50
23
La comparación de diferentes idiomas (no importa si es estática o dinámica) anula la suposición de "dentro de una misma empresa, con una cultura, línea de negocio similar": las diferencias en los idiomas hacen que las comparaciones de SLOC no tengan sentido.
robar el
44
Este método es trágicamente defectuoso. Incluso dos desarrolladores diferentes en la misma compañía que usan el mismo entorno de desarrollo a menudo producirán SLOC drásticamente diferentes para implementar el mismo conjunto de características.
17 de 26
8
Usar SLOC para medir la productividad tiene tanto sentido como usar la contaminación emitida para medir la distancia recorrida cuando lo que debe preocuparse es la eficiencia del combustible. Las formas en que esto es correcto siguen siendo incorrectas. Usa esto .
candied_orange

Respuestas:

65

El argumento del arquitecto principal podría significar dos cosas.

  1. Puede significar que un desarrollador promedio en la compañía produce más líneas de código cuando usa lenguajes estáticos que cuando usa lenguajes dinámicos. Por ejemplo, si quince desarrolladores trabajan con Java durante seis meses, escribirán 100 KLOC, y si los mismos quince desarrolladores trabajan con Python durante seis meses, escribirán solo 50 KLOC.

    No hay correlación entre LOC y productividad aquí. ¿Qué sucede si se necesitan cuatro veces más líneas de código en Java para producir la misma característica que en Python? Si eso es cierto, el uso de Python daría como resultado el doble de productividad, según las métricas de KLOC anteriores.

  2. También puede significar que un desarrollador promedio en la compañía produce menos líneas de código cuando usa lenguajes estáticos que cuando usa los dinámicos: quince desarrolladores escribirían en seis meses 100 KLOC en Java, o 200 KLOC en Python.

    Si bien menos líneas de código suelen ser mejores (menos código para escribir, leer y mantener), todavía no está claro cuántas características produjeron los desarrolladores de Java en comparación con las de Python. ¿Quizás escribieron medias líneas de código en comparación con los desarrolladores de Python, pero también produjeron la mitad de la cantidad de características?

En ambos casos, LOC no es una métrica valiosa, porque la misma característica no se traduciría en la misma cantidad de líneas de código en diferentes idiomas . Algunos idiomas tienden a ser más detallados; otros, más compactos. Si bien en algunos casos, la compacidad es valiosa, no hay una regla general para eso. Un ejemplo extremo sería el lenguaje Brainfuck que tiene una compacidad extrema, pero que no es popular por su legibilidad. Comparar incluso lenguajes similares podría ser complicado: por ejemplo, cuando se trata de llaves, Java sigue el estilo K&R, mientras que en C #, la llave de apertura está en su propia línea en la mayoría de los casos cuando sigue el estilo oficial, lo que lleva a un estilo artificial aumento de LOC para C #. ¿Y qué sucede cuando uno compara un lenguaje de procedimiento con uno orientado a objetos, o con un lenguaje funcional?

En lugar de utilizar una métrica propensa a errores, el arquitecto principal podría confiar en un grupo de métricas que miden la productividad cuando se usan juntas: la cantidad de características desarrolladas por mes, la cantidad de errores introducidos en la base del código y el tiempo dedicado a resolver esos errores , la evolución de la deuda técnica, etc. Esta comparación podría ser complicada al principio, ya que hay que tener en cuenta la falta de familiaridad del equipo con el nuevo lenguaje. Una vez que el equipo se familiarice con él, la elección debe basarse en las métricas estables, así como en la mayor parte en la preferencia de los miembros del equipo.

LOC tiene un valor en algunas situaciones estrechas. Por ejemplo, podría dar una pista sobre el tamaño del proyecto y las partes del proyecto (y en promedio se correlaciona con los puntos de función, aunque a menudo es más fácil de medir), o podría indicar los métodos y clases que pueden necesitar más atención porque de su gran tamaño. Sin embargo, el LOC debe usarse con cuidado, ya que es utilizado con demasiada frecuencia por personas que imaginan alguna correlación entre cosas no relacionadas. En el pasado, el uso más desastroso de los LOC fue el intento de medir la productividad de un desarrollador individual basado en los LOC escritos por mes.

Arseni Mourzenko
fuente
8
Sip. La única métrica en la que confío es la cantidad de tickets (características, errores, investigación, etc.) completados por unidad de tiempo. Varía según el equipo (diferentes equipos desglosan las entradas con diferente granularidad), pero dentro del mismo equipo o grupo de equipos surgirá una cultura para hacer que el tamaño de las entradas sea bastante preciso (siempre y cuando no las compare desde fuera de esa cultura)
slebetman
10
Lo que más me gusta: "Nunca confíes en una sola métrica"
Chococroc
30
@slebetman Estoy celoso de la precisión / consistencia de la persona que crea sus tickets, pero tengo que resolver problemas que van desde "Arreglar la escritura de 2 palabras" hasta "Agregar función X". La métrica de los tickets es aún menos útil para mí que LOC. El código de clase reducido en 20 LOC al menos me da una idea del trabajo realizado. Resolver 5 boletos puede ser una hora de trabajo, pero podría ser una semana.
R. Schmitz
3
@ R.Schmitz Esto es lo mismo en mi empresa, pero cada boleto también tiene un tamaño asociado, por lo que sumar el tamaño de los boletos funcionaría.
Nico Burns
1
Incluso tratar de usar esas métricas tiene problemas. ¿Qué pasa si las características agregadas son complejas y difíciles de implementar? O incluso podría ser una situación en la que las características específicas son particularmente fáciles o difíciles de implementar para un idioma, pero en general el idioma es más fácil / difícil de trabajar. La falta de productividad también podría deberse a que los empleados actuales no están familiarizados con un idioma al principio. Uno no debe confiar principalmente en las métricas para determinar qué idioma usar.
John Smith
26

Sobre productividad y SLOC

El problema con SLOC

El problema con la métrica SLOC es que mide una aproximación de la cantidad de código escrito, sin tener en cuenta:

  • la calidad del código (es decir, ¿qué pasa si por cada 100 SLOC tiene que agregar otros 90 SLOC debido a errores, pero que no sabe en el momento en que se entrega su código?)
  • los objetivos alcanzados con el código (es decir, ¿el 10K SLOC maneja todos los casos de uso esperados o historias de usuarios? ¿o solo un pequeño subconjunto?)
  • la capacidad de mantenimiento del código (es decir, ¿tendrá que agregar 1% o 50% más de código para ajustar el código a los requisitos de evolución esperados?).

De lo contrario, la producción de un código de espagueti que no se puede mantener propenso a errores con muchas partes copiadas se considerará más productivo que el código reutilizable diseñado cuidadosamente.

Por lo tanto, SLOC definitivamente no es la mejor manera de medir la productividad.

¿Qué productividad estamos considerando?

La productividad se mide para un proceso. Por lo tanto, SLOC podría ser un indicador perfectamente válido para el proceso de codificación solo.

Si, por ejemplo, no comprende bien los requisitos deficientes, pasa cinco meses para producir el software, se lo muestra al usuario, descubre que está completamente equivocado y pasa otros 5 meses para reescribirlo desde cero, tendría la misma productividad en SLOC / mes, que un equipo escriba el código correctamente la primera vez, por ejemplo, porque usaron un proceso ágil que reduce los malentendidos mediante la retroalimentación frecuente. Esta aparente igual productividad esconde grandes problemas.

Por lo tanto, la medición de la productividad del desarrollo de software debe tener en cuenta todo el proceso, incluido el análisis de requisitos, el diseño de qué codificar, codificar, probar, depurar y verificar que se cumplan las expectativas del usuario. Como todas estas actividades son muy diferentes, lo mejor es medir lo único que importa: el software de trabajo, es decir, lo que el software producido significa para el usuario .

¿Cómo medir los entregables de software?

Existen varios enfoques:

  • El enfoque típico en la ingeniería de software clásica es Function Points (FP). Los puntos de función se miden en función de los requisitos a cumplir (por ejemplo, número de formularios, número de campos en cada formulario, etc.). La productividad se mide en FP por unidad de tiempo y por persona. Algunas compañías incluso tienen datos que indican cuántos puntos de función puede producir un desarrollador por unidad de tiempo en un idioma determinado para un dominio determinado. El problema con FP es que requiere requisitos muy detallados por adelantado y lleva mucho tiempo.
  • Un enfoque más moderno y pragmático son los puntos de historia (SP). Estos se utilizan para evaluar la complejidad del código que se va a producir, y se utilizan de forma rutinaria para evaluar la velocidad de los equipos de desarrollo. Sin embargo, SP es una medida de estimación para el trabajo realizado antes de que se conozcan todos los detalles. No es una medida final de lo que realmente sucedió. Por lo tanto, se debe tener cuidado al usarlo como una medida de productividad porque podría ser contraproducente en el proceso de estimación .

Acerca de la productividad de la escritura estática frente a la dinámica

Tengo que confesar que personalmente soy un fanático de los lenguajes estáticamente tipados, porque en mi interior sé que es más confiable (años de codificación me lo demostraron).

Entonces, una cosa que estoy segura es que el lenguaje de tipo estático puede evitar muchos más errores / errores en el momento de la compilación (por ejemplo, errores tipográficos, falta de coincidencia en los tipos esperados, etc.) que los lenguajes de tipo no estático. Pero con toda objetividad, no me atrevería a generalizar esto abusivamente como una mayor productividad.

¿Tu arquitecto tiene razón?

Tal vez tal vez no.

Pero sus argumentos no parecen válidos: la ganancia de productividad del lenguaje tipado estáticamente proviene de un número significativo de errores que el compilador detecta por adelantado.

En consecuencia, no es posible descubrir esta ganancia de productividad "más alta" mirando SLOC solo sin mirar el reprocesamiento requerido para lenguajes escritos dinámicamente. Entonces su comparación no puede ser justa.

El argumento de circunstancias comparables tampoco es válido. Algunos lenguajes de tipo dinámico permiten algunas construcciones de nivel superior que requieren menos código que hacer lo mismo en uno de los lenguajes clásicos de tipo estático. Por lo tanto, podría necesitar menos tiempo, escribir menos código, pero agregar los mismos gastos generales de análisis, prueba y verificación. Por lo tanto, medir la productividad mediante el SLOC diluiría las ganancias potenciales de productividad, creando así un sesgo contra el lenguaje de tipo dinámico.

¿Algún estudio para apoyar esa afirmación?

Existen varios estudios académicos recientes sobre el tema. Aunque algunos de ellos ven una ventaja de la escritura estática, en general se limita a un propósito específico (documentación, reutilización de código o API mal documentados, etc.). La redacción prudente también se usa porque el IDE moderno ha reducido significativamente los riesgos relacionados con la escritura dinámica:

Christophe
fuente
3
Sus puntos de crítica ya se abordaron en la pregunta: " dentro de una misma compañía, con una cultura, línea de negocio y datos suficientes, las diferencias (en cuanto a situaciones y capacidades únicas de las personas) se mezclan lo suficiente como para que la métrica SLOC sea útil ". Es decir, el argumento era que a esta escala, todas las bases de código serían de calidad comparable. Aunque personalmente, dudo mucho que sea cierto.
amon
Utilizamos gitprime ( gitprime.com ) para mediciones concretas, y una de las cosas que hace es rastrear cuántas veces un desarrollador reescribe las mismas líneas de código. Entonces, si escribe algún código, obtiene un informe de error y vuelve a escribir el código, en realidad mide su eficiencia e informa su productividad neta. En resumen, no creo que sus comentarios sean problemas inherentes al usar SLoC como medida de productividad. Más bien, creo que sus quejas son con sistemas que no miden SLoC "correctamente".
Conor Mancone
8
@ConorMancone A nadie se le paga por escribir código. Se les paga para crear soluciones. Una analogía sería medir a un carpintero por la cantidad de clavos y tablas que usa. Un payaso que corta las tablas en corto y dobla más clavos que conduce a casa será más productivo que un maestro carpintero con esta métrica.
JimmyJames
1
@Christophe He estado experimentando con la medición de entregables a la producción como la principal métrica de productividad. La única parte difícil es que algunas cosas pueden ser más trabajo que otras, pero por lo que puedo decir, con el tiempo, las cosas tienden a un rendimiento bastante (estadísticamente) consistente en función del tamaño y la composición del equipo. Por supuesto, entra mucho en eso, por lo que la atribución puede ser un desafío, pero es el ancla para cualquier otra medición de la productividad del desarrollo.
JimmyJames
2
Hace años, en al menos una tienda de programación, algunas personas escribieron diagramas lógicos y otras personas convirtieron esos diagramas lógicos en código compilable. En esencia, el compilador de esa tienda tenía preprocesadores humanos. Sería justo utilizar SLoC / mes para medir la productividad de uno de esos preprocesadores humanos; eso es análogo a cuántos tornillos puede instalar un trabajador de línea de montaje en los agujeros donde los ingenieros dijeron que deberían ir. El ingeniero que especifica 100 tornillos cuando 15 son lo que requiere el trabajo está bajando la productividad de la empresa. (Del mismo modo si especifican 5 tornillos!)
David K
7

Aquí hay un contraejemplo para su arquitecto principal: Suponga que quiero escribir una jerarquía de tres clases, dos de las cuales se derivan de la tercera, implementando algunas funciones virtuales que define la clase base.

Si escribo estas tres clases en C ++, es bastante sencillo. Declaro las clases, uso virtual en los lugares correctos, y listo.

Si escribo estas tres clases en C, necesitaré agregar bastante código: necesito definir structs para las tablas v, necesito agregar un puntero de tabla v a la clase base, necesito agregar código para los constructores para establecer realmente los punteros de la tabla v, necesito agregar código a los constructores para llamar realmente al constructor de la clase base, necesito agregar código para realizar la asignación de memoria explícitamente antes de llamar a un constructor (que C ++ newhace en un solo paso ), del mismo modo, necesito separar la destrucción de la free()llamada posterior , y así sucesivamente.

El punto es que todas estas cosas adicionales son bastante insensatas. Puedo hacerlos muy rápido. Por lo tanto, no tardaré mucho más en escribir la versión C de lo que necesito para escribir la versión C ++. Sin embargo, he producido muchas más líneas de código C que código C ++. Tanto es así, que parecería haber sido más productivo en C en términos de SLOC.

Cualquier idioma que requiera una cierta cantidad de código repetitivo parecerá más productivo en términos de SLOC que un idioma que no requiera la misma cantidad de código repetitivo.

Verá, el argumento SLOC es tan fundamentalmente defectuoso, que en realidad lo vería al revés: tomaría la afirmación "los programadores tienden a producir más SLOC en lenguajes estáticos" que significa: "parece que los lenguajes estáticos requieren más código repetitivo, y así reducir la productividad ".

cmaster
fuente
1
Me gusta tu ultima frase.
Peter - Restablece a Mónica el
1
"Parece que los lenguajes estáticos requieren más código repetitivo y, por lo tanto, reducen la productividad": Esto muestra nuevamente cuán defectuoso es la métrica SLOC. El número final de líneas no considera (1) cuántas veces se necesita reescribir el código antes de obtener la solución final (2) cuántas líneas de código adicionales en forma de pruebas unitarias se requieren (los lenguajes escritos dinámicamente requieren en promedio más pruebas unitarias para tener una confianza comparable en la exactitud del código de producción). La métrica SLOC es definitivamente defectuosa.
Giorgio
6

Yo seré el contrario.

Hacemos un seguimiento de SLoC en nuestro trabajo (aunque no lo usamos directamente en las decisiones de personal), y he tenido personas que discuten lo que la mayoría de la gente dice en sus respuestas. En efecto, "LoC no importa porque la tecnología X nos permite hacer más con menos código" o "Mejores desarrolladores escriben mejor, código más corto, por lo que no escriben más que nadie". En mi experiencia (aunque no tengo ningún número difícil para respaldar estas cosas), estas objeciones simplemente no son correctas. En mi propio tiempo, he visto una correlación clara tanto en la velocidad como en la calidad de la producción de código para nuestros desarrolladores, en comparación con todas las otras mediciones significativas de su "competencia" general como ingeniero. Para dar algunos contraejemplos a los tipos de argumentos presentados anteriormente:

  1. Sí, algunos idiomas pueden hacer más con menos código. De hecho, tenemos un marco completo que hemos construido que "automatiza" grandes porciones del desarrollo para nuestros problemas comerciales particulares (solo back-end). El resultado de todo esto no es que las personas escriban menos código, sino simplemente que tenemos más tiempo para escribir código. Como resultado, en nuestra empresa, la tasa general de escritura de código es bastante constante en todas las tecnologías y depende principalmente del nivel de competencia del ingeniero.
  2. La idea de que un mejor desarrollador producirá menos código porque está escribiendo de manera más inteligente definitivamente no es verdad. Sí, un programa mejor diseñado podría ocupar menos líneas de código. Sin embargo, personalmente he descubierto que los "mejores" desarrolladores que escriben código más eficiente no tardan más en planificarlo que un desarrollador más joven que escribe cosas a largo plazo. Como resultado, el desarrollador más experimentado completará sus tareas de codificación más rápido y pasará a escribir código diferente a la misma velocidad.

Esa última parte es mi resumen general, por cierto. Lo que he encontrado es que, independientemente de la pila tecnológica o el tipo de proyecto, la mayoría de los desarrolladores tienen su propio ritmo, que es el ritmo al que operan. Si un lenguaje tiene muchas características que hacen que el código de los desarrolladores sea más efectivo, entonces eso es una gran ayuda para el negocio, pero eso no significa que escribirán menos código como resultado. En cambio, obtienen funciones más rápidamente y pasan rápidamente a un nuevo código. Una vez más, el resultado final es que la tasa a la que codifican depende principalmente de su habilidad y menos de su pila de tecnología. De hecho, debido a esto, generalmente esperaría que la tecnología apunte más a la velocidad a la que se desarrollan los tickets y las características que a la velocidad a la que las personas codifican.

Dicho esto, ni la tasa de escritura de códigos ni la tasa de cierre de tickets es una medida perfecta de productividad, por lo que no tomamos decisiones de personal directamente sobre la base de SLoC. En cambio, es parte del proceso, y las evaluaciones de los empleados se realizan utilizando tantos puntos de datos como sea posible. Sin embargo, diría que su arquitecto ciertamente no está loco.

Una excepción

La única excepción con la que estoy de acuerdo es la posibilidad del código de placa de caldera. Si hay una gran cantidad de copiar y pegar de una clase (o lo que sea) a otra para ponerlo en funcionamiento, entonces eso obviamente va a sesgar las métricas. Esto también es cierto si tiene herramientas que pueden generar automáticamente grandes cantidades de código para usted. Sin embargo, creo que a menudo serán la excepción y no la regla. Si sus desarrolladores pasan algún tiempo copiando el código de la placa de caldera para comenzar, entonces está utilizando el conjunto de tecnología incorrecto. Si realmente están escribiendo el código, incluso si es bastante repetitivo, entonces espero que esto distorsione cualquier medida solo una pequeña cantidad: al escribir código, la mayoría de las veces estamos limitados por la rapidez con la que podemos pensar en el problema. de lo rápido que podemos escribir. Incluso al escribir código relativamente repetitivo,

Obviamente, todo lo anterior se basa en mi propia experiencia personal. Su kilometraje puede variar, y obviamente estoy en minoría. Siéntase libre de estar en desacuerdo. En resumen, sin embargo:

Creo que la tasa de codificación depende más de la rapidez con la que puede pensar en sus problemas que cualquier otra cosa. Como resultado, descubrí que la tasa de codificación es una medida decente de la productividad, incluso entre conjuntos tecnológicos, con solo algunas excepciones posibles.

Conor Mancone
fuente
44
También hay otra excepción: la búsqueda de errores. La búsqueda de errores para errores especialmente desagradables puede llevar mucho tiempo, pero generalmente da como resultado una sola línea de cambio de código.
Nathan Merrill
@NathanMerrill Ese es un buen punto para, aunque menos relevante para el OP: la depuración es la depuración en todos los idiomas y (fuera de mi cabeza), no veo ninguna razón por la que sería mucho más fácil o más difícil de un paquete de tecnología a otro. Dicho esto, esa es una razón por la cual, en general, no puede juzgar la productividad exclusivamente en el código escrito, más de lo que puede hacerlo en cualquier otra métrica.
Conor Mancone
Usamos gitprime ( gitprime.com ) en nuestra empresa, y como gerente e ingeniero, creo que se trata de lo mejor del mundo. Nuevamente, es solo una parte de la imagen para nosotros, pero ha sido extremadamente útil para identificar posibles problemas con los ingenieros mucho antes de que hubiera un problema real. La transparencia es increíble, y todo lo que hacen se reduce a SLoC. Dada la cantidad de valor y perspicacia que agrega, siempre tengo dudas acerca de la tendencia de algunos ingenieros a descartar el SLoC sin control. Cualquiera es bienvenido a su opinión, pero definitivamente funciona
Conor Mancone
La pregunta es si LoC se puede usar para comparar herramientas e idiomas, en el contexto del desarrollador principal que dice que muestra una mayor productividad en lenguajes "estáticos". Parece que está respondiendo una pregunta diferente: LoC se puede usar para comparar desarrolladores, pero aún así acepta que no se puede usar para comparar idiomas porque un desarrollador determinado escribe la misma cantidad de LoC independientemente de la herramienta / idioma. ¿Dices que eres contrario a las otras respuestas aquí, pero parece que estás de acuerdo?
TessellatingHeckler
Como desarrollador, puedo pensar en muchas veces que tomé un montón de código no SECO y lo reemplacé con un pequeño conjunto de funcionalidades reutilizables. Luego agregué una cantidad significativa de nueva funcionalidad. Reducir la cantidad de código al agregar un múltiplo de valor real es algo bueno en mi libro. En mi experiencia, los mejores ingenieros escriben la menor cantidad de líneas de código y las peores escriben más.
JimmyJames
6

Aunque me estoy subiendo al carro. Creo que hay que destacar el impacto en el comportamiento de los programadores.

El uso de SLOC como medida productiva tiene un efecto tóxico en la moral del programador. En el momento en que cualquier ingeniero de su equipo / empresa se da cuenta de que se miden en SLOC, suceden varias cosas:

  1. Comienzan a escribir código mucho más largo para hacer la misma función
  2. les importará menos la calidad de su código
  3. dejarán de hacer otras cosas que ayuden a su equipo (reclutar, depurar, ayudar a los juniors)
  4. odiarán su trabajo y probablemente se irán

No puedo enfatizar lo suficiente lo corrosivo que es diseñar la moral, como lo he visto suceder dos veces en 2 compañías diferentes. Independientemente de los casos de uso aparentemente válidos que tenga para él, sostengo que es poco probable que valga la pena el impacto en su equipo / empresa, incluso si hay una pequeña posibilidad de que se descubra su uso. Aunque en algunos casos puede haber una correlación entre el número de líneas escritas y la cantidad de características útiles, fomenta todos los comportamientos incorrectos en sus programadores y envía el mensaje de que la calidad no es importante.

Nath
fuente
De hecho ... cualquier métrica que desincentiva a alguien a eliminar el código redundante ("¡has tenido una métrica de SLoC negativa esta semana!" Está mal, simplemente mal!
Andrew
1

Generalmente no se considera una forma válida de medir la productividad. El código más pequeño generalmente es mejor que el código más grande, por lo que un desarrollador más productivo generalmente produce menos código. La productividad tiene su mayor éxito en la depuración; Los desarrolladores eficientes dedican poco tiempo a la depuración.

Los idiomas estáticamente tipados son más productivos (si controla todas las demás diferencias entre idiomas), porque cuando se usan con prudencia, reducen el tiempo de depuración, detectando errores en la fase de compilación, donde son más rápidos de corregir.

Frank Hileman
fuente
1
Este podría ser un punto válido si estuviéramos comparando la productividad de los desarrolladores individuales. Sin embargo, la pregunta es sobre la comparación entre idiomas, por lo que el contexto es muy diferente. Esto también significa, por ejemplo, que un código más pequeño no es mejor o peor que un código más grande; compare la LOC del código escrito en Brainfuck con el código escrito en, por ejemplo, Ruby.
Arseni Mourzenko
1
@ArseniMourzenko Además de bromas como Brainfuck, los lenguajes bien diseñados se comparan realmente en función de la cantidad de código necesario para resolver una tarea. Por lo general, tal comparación se llama expresividad. Sin embargo, es cierto, estaba hablando de LOC en un solo idioma, no en todos los idiomas. La productividad generalmente se define como el tiempo que lleva realizar una tarea; eso no es específico de la programación.
Frank Hileman el
0

La única métrica que puede usar para comparar la productividad de los desarrolladores entre idiomas es una métrica que no compara el código entre los idiomas. Algunos lenguajes son notoriamente detallados (COBOL para el legado ganador), y otros requieren varios pasos para hacer algo que puede hacer en una línea de código (ensamblado vs. casi todo lo demás). Incluso si compara solo líneas de código activas (es decir, no cuente las declaraciones y solo cuente el código que tiene alguna acción involucrada), aún puede sesgar sus resultados.

Es posible que pueda argumentar a favor de las tasas de cambio. Es decir, se agregaron líneas de código que comparaban la pendiente de la productividad durante el mismo período de tiempo. Sin embargo, eso no tiene en cuenta los cambios negativos en las líneas de código. Por ejemplo, hereda un proyecto que tiene código de copiar y pegar en todas partes. Realiza algunas refactorizaciones rápidas y fáciles para reducir la cantidad de bloques de código repetidos; por definición, tiene una pendiente negativa.

Con toda seriedad, comparar la productividad de los equipos / idiomas no tiene sentido porque hay tantos factores adicionales que afectan la productividad de un equipo que no se pueden sacar conclusiones significativas de él.

Trabajé en un proyecto donde la infraestructura era muy frágil y las herramientas estaban desactualizadas. El proyecto se creó en Java con una aplicación de página única, pero se alojó en un contenedor de portlet sin ningún beneficio aparente. El tiempo que tardó en hacer incluso cambios simples fue ridículamente largo. Si tuviera que basar todas sus conclusiones en ese proyecto en particular, podría concluir que Java era malo o que las aplicaciones de una sola página eran malas. Tampoco son ciertas. El sistema que se suponía que el feo proyecto debía reemplazar se creó en C # y WebForms. Cuando presentamos el argumento comercial para ampliar la aplicación existente para manejar las necesidades de los clientes, nuestra productividad se disparó. ¿Eso significa que una aplicación de WebForms estrechamente acoplada es superior? Solo puede hacer esa conclusión para este caso particulary no se extiende al mundo en general. Y solo tiene sentido porque había una aplicación existente con madurez suficiente para extenderse.

Incluso comparar las tasas de resolución de elementos en el sistema de seguimiento de problemas es erróneo en el sentido de que está comparando las infraestructuras completas del proyecto entre sí. Las bibliotecas y los marcos utilizados pueden acelerar o ralentizar el progreso. Es posible que se encuentre en la fase de inicio con muy poca inercia que superar, donde el proyecto en el que está "mejor que" se encuentra en una fase de mantenimiento donde el número de tickets nuevos es relativamente bajo. Nunca se trata de comparar cosas similares.

Berin Loritsch
fuente