Blog de Miguel Llopis

Por qué no me gusta la métrica LOC (Lines Of Code)

[ Aprovechando las vacaciones navideñas y las 15 horas de vuelos desde Seattle hasta España para redactar unos cuantos posts que tenía en mente desde hace tiempo… ]

Hoy os hablaré sobre por qué considero que LOC no es una métrica de código demasiado útil (por decirlo eufemísticamente), algo sobre lo que estoy seguro de que habréis leído ya en bastantes ocasiones pero me gustaría aportar mi visión particular.

De vez en cuando me he encontrado con gente que me realiza preguntas del tipo: “¿Cuántas líneas de código tiene el proyecto Oslo SQL Server Modeling Services?" (cambiad esta última parte por Windows 7, o Visual Studio 2010, o SQL Server 2008, etc), o también “Miguel, ¿cuantas líneas de código escribes al día?”…

En el caso de la segunda pregunta, mi respuesta suele ser: “En algunos de los mejores días de mi vida como desarrollador, mi LOC ha sido un valor negativo. Afortunadamente, LOC no es directamente proporcional a mi productividad”.   : )

Hay dos matices que considero bastante descriptivos en cuanto a LOC:

  1. Para lo único que LOC es una medida válida es para medir el tamaño de la base de código de un proyecto.
  2. Un valor de LOC enorme en nuestra codebase no resulta ser, en muchas ocasiones, algo bueno.

Mi opinión personal es que LOC es prácticamente inútil para gestión de proyectos, para lo único que nos sirve es para hacer análisis del tipo:

  1. El módulo A es el doble de grande que el módulo B. (considerando que ambos están escritos en el mismo lenguaje (aunque esto sería también discutible, hay estudios que afirman que LOC es independiente del lenguaje empleado, pero no estoy de acuerdo en la mayoría de casos), que las coding guidelines son las mismas para ambos, etc… En cualquier otro caso, ni siquiera serían comparables)
  2. El módulo C ha crecido un 25% en los últimos 6 meses.
  3. Podemos ver cómo el módulo D tiene un elevado número de bugs, debido a su gran tamaño.

Para cuestiones relacionadas con el análisis del crecimiento/progreso en un determinado proyecto, es claramente mejor fijarse en otras métricas diferentes a LOC, como por ejemplo el número de features completadas/pendientes, etc. Si empleáramos LOC, el análisis sería incorrecto ya que alguien podría añadir 1.000 líneas de código a un proyecto sin completar una feature concreta, de igual forma que alguien podría eliminar 1.000 líneas de código y ser capaz de completar tres features.

Respecto a este último ejemplo, comentar que un índice LOC negativo es en bastantes casos el resultado de un trabajo de refactorización de código realizado como parte de la implementación de una nueva feature y puede tener un impacto significativo en el tamaño global de nuestra base de código.

Ahora que ya os he dado mi opinión personal, veamos qué dicen otras fuentes más documentadas que yo al respecto. Por ejemplo, la siguiente tabla (extraída del libro “Code Complete”) nos muestra la relación entre el tamaño del proyecto y el LOC por persona/año:

Tamaño del proyecto (LOC) LOC por persona/año
1.000 2.5K - 25K
10.000 2K - 25K
100.000 1K - 20K
1.000.000 0.7K - 10K
10.000.000 0.3K - 5K

El aspecto a destacar en esta tabla es que la cantidad de líneas de código que un desarrollador es capaz de escribir disminuye a medida que el proyecto aumenta de tamaño. Esto se debe a diversos factores, como son el hecho de que la complejidad aumenta, el impacto de las modificaciones realizadas es mucho mayor en otras partes del proyecto, el esfuerzo de testing necesario aumenta, el número de bugs aumenta, etc.

Por tanto, idealmente, un buen desarrollador no es aquel con mayor LOC, sino con mayor ratio Feature/LOC ya que eso significaría que el desarrollador está implementando nuevas funcionalidades (y por tanto aportando valor añadido para el cliente) a la vez que mantiene el tamaño de code base en unos límites razonables, lo cual permite incrementar la productividad de él mismo y del resto de compañeros en el equipo de desarrollo del proyecto.

Otros factores negativos sobre LOC los podemos encontrar en el libro “Applied Software Measurement” de Capers Jones, entre los que destacaré los siguientes:

  1. Las métricas LOC penalizan a los lenguajes de programación de alto nivel.
  2. Análisis comparativos de proyectos en los que se ha empleado más de un lenguaje de programación y que se fundamenten en LOC deberán ser considerados una mala práctica profesional.
  3. Las métricas de “Coste por bug” penalizan la calidad y hacen que un software lleno de bugs pueda parecer mejor de lo que en realidad es, a juzgar por los resultados de un estudio basado en LOC. Para este tipo de estudios, es mejor emplear métricas de Puntos de Función.

Por último, me gustaría recomendar otro libro bastante interesante “Measuring and Managing Performance in Organizations”, de Robert Austin. En este libro, Austin entrevista a varios expertos de la industria del software que aportan su opinión acerca de qué cosas conviene (o no) medir. Al final, casi todos ellos coinciden en que medir todo aquello que convendría medir en el desarrollo software es prácticamente imposible…

Merry Christmas!

Posted: 21/12/2009 20:15 por Miguel LLopis | con 3 comment(s)
Archivado en:
Comparte este post:

Comentarios

Miguel Sierra ha opinado:

Estoy muy de acuerdo contigo Miguel, en cuanto a está métrica en concreto, que por si sola no aporta mucho valor, pero por otro lado la veo imprescindible, ya que al combinarse con otras métricas (por ejemplo porcentaje de líneas de comentarios por LOC) aportan mucho valor para medir la calidad interna del proyecto (mantenibilidad, complejidad ciclomática,...).

Otro apunte importante que haces es que las métricas no sirven para medir a las personas, porque las personas son mas listas y las sesgan (esta frase es del gran RC ;) )

Un saludo!!

# December 22, 2009 3:41 PM

Rodrigo Corral ha opinado:

Interesante tema Miguel:

Hay una cita de Bill Gates sobre el tema que viene al pelo:

'Medir el progreso de un proyecto de software en líneas de código es como medir el progreso de la construcción de un avión en toneladas.'

Otra anecdota sobre el tema. En una empresa que no citaré, un director de proyecto propuso usar LOC como métrica para medir, ni más ni menos, que la productividad de los programadores. En su vida había tirado una línea de código, lo que da una idea de su propia productividad.

Yo le replique que ese mes me pusiese una productividad negativa, de menos 3000 líneas más o menos. Después de una refactorización para que usasen las clases de ATL todas las escrituras y lecturas que se hacian en el registro usando el API de Windows, había quitado muchísimas líneas de código. Aun recuerdo la cara de bobo que se le quedo.

Comparto lo que dice Miguel Sierra, una métrica aislada es dificil de interpretar. Solo la velocidad de desarrollo (y no siempre) da información significativa por si misma. Todas las demás métricas, observadas de manera aislada, son subceptibles de ser sesgadas o de hacernos caen en la búsqueda de máximos locales.

Un saludo.

# December 22, 2009 8:25 PM

Miguel LLopis ha opinado:

Miguel y Rodrigo, muchas gracias por vuestros comentarios.

Veo que en general estamos de acuerdo prácticamente en todo. Puesto que ambos lo comentáis, aclarar algo acerca del post y es que me faltó matizar lo de "por si sola", esto también se podría aplicar a otras tantas métricas, pero generalmente la gente suele preguntar por LOC cuando lo hacen "por curiosidad". Es por ello por lo que estaba un poco quemado con esta métrica, o con la pregunta en sí...  : )

Saludos,

M.

# December 23, 2009 1:40 AM