Pages Menu
Categories Menu

Posted by on Sep 12, 2013 in General | 3 comments

Si eres responsable de un software ten muy claros los peligros de medir líneas de código

El que el tema que voy a tratar en este post debería ya estar superado. Pero no es así. Aun sigo viendo grandes errores en proyectos, errores que afectan mucho, derivados de no conocer una de las métricas más populares (y mal aplicada) del software: el número de  líneas de código. Y por ello voy a aportar mi pequeño granito de arena en el desierto.

Se que para los “no-técnicos” es difícil de entender que el software no sigue leyes físicas, y para ellos es fácil, erróneo, deducir que si un edificio a más ladrillos colocados… más avanzada va la obra, pues en un software  a más líneas de código… más avanzado va el proyecto. Error.

Los “no técnicos” pueden tener dudas sobre esto, pero un ingeniero software no. Ninguna duda. Cero. Y al igual que un físico conoce y maneja con soltura medidas como la temperatura, la presión, etc., un ingeniero software debe manejar (conocer, saber sus pros y contras, etc.) con soltura las “cuatro” medidas básicas del software: líneas de código, complejidad ciclomática, punto función, etc.

Mucho responsable de proyecto asume que si un sistema es 10 veces más grande que otro… este requerirá 10 veces más esfuerzo para ser construido. Pero el esfuerzo para un construir un sistema de 1.000.000 de líneas de código es mas de un x10 que el esfuerzo para construir un sistema de 100.000.

En un breve estudio que puedes encontrar en el muy recomendable Software Estimation: Demystifying the Black Art (y que se basa en los trabajos de Putnam, Meyers, Boehm y Cusumano), se muestra un estudio de cómo a más líneas de código menor es la productividad:

Tamaño del software en LDC

Número de líneas de código desarrolladas por el equipo cada año

10.000 2.000 – 25.000
100.000 1.000 – 20.000
1.000.000 700 – 10.000
10.000.000 300 – 5.000

Hay muchas cosas erróneas a conocer del uso de las líneas de código, pero si eres el responsable de un proyecto, por favor, ten claro los siguientes.

1 – No asumas que el esfuerzo aumenta linealmente según crece el tamaño del proyecto. El esfuerzo crece de manera exponencial.

2 – Cuanto mayor es el software (en número de líneas de código) más cuesta mantener cada línea de código.

3 – A más líneas de código menor es la productividad por desarrollador.

4 – Por lo anterior, tu objetivo como responsable de un proyecto es mantener el número de líneas de código en el mínimo posible (esto deja fuera ideas absurdas como medir la productividad o el avance en función de la creación de líneas de código)

 

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

3 Comments

  1. Hola Javier.

    Interesante reflexión, la complejidad del sw crece exponencialmente con el tamaño físico construido.

    De todos modos, no entiendo los títulos de las columnas de la tabla que has publicado. La primera ¿se trata de las LOC del sw desarrollado, o del tamaño del sistema? La segunda ¿se refiere a las LOC escritas por todo el equipo en un año? ¿de cuanto gente se compone el equipo? Me he perdido.

    Gracias de antemano por las aclaraciones

    • Hola Luis,

      La primera columna es el tamaño del software en líneas de código (LDC), la segunda es la productividad me dida en LDC (literalmente es Lines of Code per Staff Year) calibrado con equipo del mismo número de personas.

      Saludos

  2. Igualmente a mayor número de LDC, mayor probabilidad de inyectar errores.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This