Es comun presenciar muchas discusiones acaloradas sobre el proceso del software, las prácticas de diseño y temas parecidos. Muchas de estas discusiones son imposibles de resolver porque la industria del software no tiene una forma de medir algunos de los elementos básicos sobre la efectividad del desarrollo de software. En particular, no existe una forma razonable para medir la productividad.
Por supuesto, la productividad es algo que se determina mirando la entrada de una actividad y su salida. Entonces para medir la productivdad del software deberíamos medir la salida del desarrollo de software - la razón por la que no podemos medir la productividad es porque no podemos medir la salida.
Claro que esto no significa que nadie intente. Una de las cosas que más me irritan son los estudios de productividad basados en las líneas de código. Para empezar, está todo el tema de las diferencias entre los lenguajes, los distintos estilos de contar líneas, y las diferencias por las convenciones de codificación. Pero incluso si usamos un estándar consistente para contar líneas en los programas de un mismo lenguaje, que está todo auto-formateado a un único estilo... incluso etnonces las líneas de código no miden la salida correctamente.
Cualquier buen desarrollador sabe que se puede codificar lo mismo con enormes variaciones en las líneas de código; de hecho un código que está bien diseñado y programado va a ser más corto porque elimina la duplicación. La programación basada en copiar-y-pegar lleva a enormes cantidades de Lineas De Código (LOC - Lines Of Code), y el diseño pobre genera duplicación.
A esta altura contar líneas de código debería ser algo obsoleto, y sin embargo todos los meses veo estudios de productividad basados en líneas de código - incluso en publicaciones de la IEEE, que se supone deberían conocer estos temas.
Ahora bien, esto no signifca que las LOC sean una medida completamente inutil, ya que sirven muy bien para sugerir el tamaño de un sistema. Puedo estar bastante seguro que un sistema con 100 KLOC es más grande que un sistema con 10 KLOC. Pero si yo escribo el sistema de 100 KLOC en un año, y José escribe el mismo sistema en 10 KLOC en este mismo tiempo, esto no signifca que yo soy más productivo. Debería concluir que nuestra productividad fue aproximadamente la misma, y que mi sistema está mucho peor diseñado.
Otro enfoque que se suele usar para medir la productividad son los Puntos de Función (FP). Les tengo algo más de simpatía, pero siguen sin convencerme. Conozco muchas historias donde el mismo sistema, contado por distintas personas, obtenía puntos que variaban por un factor de tres.
Incluso si encontrásemos una forma precisa de determinar la funcionalidad con Puntos de Función, creo que todavía estaríamos perdiendo el punto de la productividad. Podría decir que medir la funcionalidad es una forma de mirar la salida directa del desarrollo de software, pero la salida real es algo más. Asumiendo que usamos un sistema de FP preciso, si yo paso un año para entregar un sistema de 100 FP, y José pasa el mismo año en entregar un sistema de 50 FP, ¿podemos asumir que yo fui más productivo?. Diría que no. Podría resultar que de mis 100 FP sólo 30 son funcionalidad que le termina resultando útil al cliente, mientras que la funcionalidad de José es toda útil. Debería concluir que mi productividad directa es más alta, pero que la producitividad real de José es mejor.
Además hay factores internos que afectan la entrega de puntos de función. Mis 100 puntos de función podrían ser muy parecidos, y me lleva un año hacerlos porque no uso algún sistema para reutilizar código. Los 50 puntos de función de José son todos diferentes (malas noticias para él). Le resulta casi imposible reutilizar algo. Pero a pesar de que tiene que implementar 50 puntos completamente distintos, para los cuales no se puede reutilizar nada, José logra hacerlo en sólo un año.
Pero todo esto ignora el hecho de que incluso la funcionalidad útil no es la medición real. A medida que aprendo logro producir 30 FP útiles de funcionalidad, y José sólo logra hacer 15. Pero alguien se da cuenta que los 15 FP de José generan ganancias por $10 millones para el cliente, mientras que mi trabajo sólo logra ganacias por $5 millones. Nuevamente podría concluir que la productividad real de José es más alta porque logró entregar más valor de negocio - y recordemos que cualquier medición real de productividad en el desarrollo de software tiene que estar basada en el valor de negocio entregado.
Todo esto nos lleva a la tasa de éxitos. Podría decir que un proyecto exitoso es aquel que entrega más valor de negocio que el costo del proyecto. Veamos: si José y yo hacemos cinco proyectos cada uno, y yo tengo éxito en cuatro y José en uno, ¿finalmente hice un mejor trabajo que José? No necesariamente. Si mis cuatro proyectos exitosos generan $1 millón de ganancias cada uno, pero el único proyecto exitoso de José genera $10 millones más que el costo de todos sus proyectos combinados, entonces José es quien debería ser felicitado.
Hay quienes dicen "si no lo podés medir, no lo podés gestionar". Esto es esquivar responsabilidades. Los negocios gestionan cosas que no pueden medir todo el tiempo. ¿Cómo se mide la productividad de un estudio de abogados, de un departamento de marketing, de una institución educacional? No se puede - y sin embargo hay que gestionarlas igual.
Si es dificil medir la productividad de un equipo, más dificil es medir la contribución de cada individuo del equipo. Podemos tener una idea aproximada de la salida del equipo mirando cuántas funcionalidades pueden entregar en una iteración. Es una idea cruda, pero nos puede servir para ver si el equipo se está acelerando, o si es más productivo que otro. Pero la contribución individual es mucho más dificil de medir. Aunque algunas personas sean responsables de implementar ciertas características, otros pueden jugar el rol de apoyo - ayudando a otros a implementar sus características. Su contribución hace que aumente la productividad de todo el equipo - pero es dificil lograr saber la salida individual a menos que seamos un desarrollador en ese equipo.
Y si todo esto no era lo suficientemente complicado, el Economist (septiembre 13-19, 2003) publicó un artículo sobre las tendencias en la productividad. Parece ser que los economistas ahora están viendo aumentos en la productividad debido a inversiones en computadoras que hicieron en los años 90. El punto es que las mejoras aparecen mucho después de la inversión: "La inversión en computadoras no se traduce en un aumento automático en la productividad; las organizaciones necesitan reorganizar sus prácticas de negocio también". Esta misma demora ocurrió con la invención de la electricidad.
Así que no sólo es dificil medir el valor de negocio, sino que también hay una demora en el tiempo. Entonces no podemos medir la productividad de un equipo hasta pasados varios años de la entrega del software que construyeron.
Podemos ver porqué medir la productividad es tan seductor. De lograrlo podríamos medir al software de una manera mucho más facil y objetiva que en la actualidad. Pero las falsas mediciones sólo empeoran las cosas. Esta es un área en donde creo que debemos admitir nuestra ignorancia.