La productividad mal entendida: midiendo el número de líneas de código

A principios de 1982, en Apple tenían mucha prisa por sacar el Lisa, así que decidieron dar un empujón a sus programadores y a algún iluminado se le ocurrió medir el progreso de éstos basándose en el número de líneas de código producidas semanalmente.

Bill Atkinson, autor de Quickdraw y principal diseñador de interfaces para Lisa, era un detractor de esta métrica, pues pensaba que un programa debía ser tan pequeño y rápido como fuera posible, y que esa medida favorecería la aparición de código hinchado y descuidado con el único objetivo de aparentar haber trabajado más.

Precisamente, Atkinson se encontraba optimizando el motor de cálculo de regiones de Quickdraw, cuya eficiencia consiguió mejorar hasta hacerlo 6 veces más rápido. Y lo mejor es que esta optimización trajo además consigo una reducción del tamaño del programa de 2000 líneas de código. Así que, ni corto ni perezoso, al final de la semana cuantificó su productividad en -2000 líneas. Poco más tarde, dejaron de exigir ese informe.

Esta historia real viene a confirmar algo que la mayoría de programadores sabemos y que a los altos cargos les suele costar entender: nuestro trabajo no es cuantificable como el número de barras de pan que haga un panadero o el de ladrillos que ponga un albañil. El trabajo de un programador debe medirse en eficacia y eficiencia, y medir líneas de código puede ser tan absurdo como medir el trabajo de un médico por el número de recetas extendidas en lugar de por la calidad de vida de sus pacientes.

[...]

>>> Ver artículo original completo en: http://www.genbetadev.com