por Sergio Montoro Ten, 30 enero 06

Hace unos días hablaba con un responsable técnico de la empresa Tecsidel quien me decía “aquí odiamos los proyectos pajareros”. Quería decir esa clase de proyectos donde hay toneladas de requisitos sin orden ni concierto claros.

Los buenos programas hacen a los sumo dos o tres cosas muy bien y NADA MÃ?S. WinZip: Comprimir arcivos y punto. WinAmp: reproducir cualquier archivo de audio. Skype: hablar por Internet.

Hay una conocida regla en los proyectos que dice que “todas las aplicaciones crecen en funcionalidad hasta que enventualmente son capaces de enviar y recibir e-mails”.

En muchos casos este hipercrecimiento en funcionalidades es un gran error. Por cuatro motivos :

1º) El número de bugs de un programa es directamente proporcional al número de funcionalidades.
Por consiguiente, para que el programa tenga menos errores ¡Basta con quitarle cosas! Si uno lee los informes de errores de Apache de los últimos años, es fácil darse cuenta de que gran parte de los errores están localizados en oscuros módulos periféricos.
Otro ejemplo muy claro de la relación directa entre bugs y funcionalidad es el agujero de seguridad de los archivo Windows Meta File La historia de Windows sería probablemente la misma si el format WMF no existiera. Se trata de una funcionalidad que ha pasado sin pena ni gloria y que hubiese sido mejor para Microsoft que nunca hubiese existido.

2º) El coste total de desarrollo de una funcionalidad se extiende a toda la vida del producto.
Para ilustrar este hecho es muy interesante leer el artículo de Eric Lippert How many Microsoft employees does it take to change a lightbulb? en el que explica cuanta gente hace falta en Microsoft para añadir una hipotética función ChangeLightBulbWindowHandleEx al runtime de VBScript.

•Cinco minutos de un desarrollador para implementar ChangeLightBulbWindowHandleEx
•Un analista/programador para escribir la especificación
•Un experto en localización para escribir la especificación
de internacionalización
•Un experto en usabilidad para revisar la especificación de accesibilidad y usabilidad
•Un desarrollador, un técnico de testeo y un analista de seguridad para evaluar las posibles vulnerabilidades
•Un gerente de proyecto para escribir la especificación del modelo de seguridad
•Un especialista para escribir el plan de pruebas
•Un jefe de etsteo para organizar el plan de pruebas
•Un especialista para jecutar los casos de pruebas
•Tres o cuatro beta testers para hacer pruebas ad hoc
•Un documentalista técnico para escribir la documentación
•Un revisor estilístico para validar la documentación
•Un editor para formatear la documentación
•Un jefe de documentación para integrar la nueva documentación con la ya existente
•Veinticinco traductores para traducir la documentación a todos los idiomas
•Un gerente senior para coordinar a todas las personas anteriores, así como para justificar su coste ante el vicepresidente.

Y todo esto es sólo para implementar la funcionalidad. Cuando el producto crece mantener la funcionalidad es a veces más caro que escribirla. Sobre todo si se trabaja con un producto multiplataforma. Cada vez que se introduce una funcionalidad es preciso tener en cuenta que se está añadiendo un coste fijo adicional perpétuo al mantenimiento del programa.

3º) Los clientes no siempre pueden absorber el ritmo de innovación del desarrollador.
En la carrera por diferenciarse de sus competidores, los proveedores añaden frenéticamente funcionalidades a sus productos. Esto es porque si no las añaden, empiezan a recibir críticas de la competencia argumentando que su producto no hace suficientes cosas. Tomemos el ejemplo de Internet Explorer. Ahora existe cierta presión sobre Microsoft porque Firefox 1.5 incorpora tabbed browsing e Internet Explorer 6.0 no. ¿Qué debería hacer Microsoft? ¿Sacar a toda prisa una versión 6.1 que incorporase esta característica? Este fenómeno de exceso en el ritmo de producción de nuevas funcionalidades ocurre en casi todos los fabricantes. Oracle, por ejemplo, es uno de esos productos donde los clientes usan habitualmente el 20% de las funcionalidades y el restante 80% a duras penas saben si existe. Hubo un tiempo en que Oracle presumía de habar incorporado nuevas características de orientación a objetos en la base de datos, un sistema de colas de peticiones, o más recientemente Java ejecutable dentro de la base de datos como si fuese PL/SQL, pero ¿cuanta gente utiliza realmente esto? ¿son de veras ventajas competitivas para Oracle todas estas características?

4º) Las funcionalidades extra ralentizan el programa y añaden complejidad.
A mi me encantan los programas que caben en un diskette de 1,44Mb, si, ya sé, ningún programa actual cabe en 1,44Mb y de todas formas ya nadie usa diskettes de 3,5”. Por eso sigo fiel a tantos programas antiguos. Cada vez que un programa crece y lo complican, lo fastidian.