por Sergio Montoro Ten, 3 enero 06

Un principio básico de cualquier estrategia es que implica renunciar a unas cosas para conseguir otras. Si no hay compromiso de renuncia, entonces no hay estrategia, sólo fuerza bruta.

Curiosamente, cuando se fabrica software rara vez se define explícitamente una estrategia para su desarrollo. Se elaboran especificaciones, se designan estándares, se imponen normas de codificación, se eligen herramientas de modelado y bug tracking… Pero es poco frecuente encontrar un apartado en el proyecto que diga qué estrategia se debe seguir al escribir el código.

La estrategia de codificación a la que me refiero consiste en fijar una serie de prioridades a la hora de tomar decisiones, por ejemplo:

1. Corrección
2. Usabilidad
3. Mantenibilidad
4. Portabilidad
5. Claridad
6. Consistencia
7. Testeabilidad
8. Eficiencia computacional
9. Tamaño del ejecutable
10. Uso de estándares

La lista anterior, por supuesto, debe cambiar en contenido y orden para cada proyecto. Lo importante es llegar a un acuerdo y que todos los programadores la conozcan.

Aunque las prioridades cambien, existe una, al menos, que debería ser siempre la estrella: que el programa funcione bien, en el sentido de que para todas las entradas aceptables proporcione salidas correctas.

Esto que parece obvio como primera prioridad, paradójicamente, no siempre se cumple. En el (ya algo vetusto) libro The Psychology of Computer Programming Gerald Weinberg expone un ejemplo de ello. Cuenta el caso de un programa para hacer la lista de componentes de un automóvil a partir de los extras solicitados por el cliente: aire acondicionado, elevalunas eléctrico, etc. Dicho programa se había ido codificando manualmente hasta convertirse en un spaghetti cuyo mantenimiento era una pesadilla. Llegado un punto el equipo decidió substituir la monstruosa complejidad ciclométrica del viejo programa por un nuevo sistema de decisión basado en matrices externas al código. Las reglas codificadas a fuego en el programa se re-escribieron con matrices. El problema era que el nuevo programa era muchísimo más lento que el anterior, y, peor aún, no se habían trasladado bien todas las intrincadas reglas del código a las matrices y el nuevo sistema sencillamente producía escandallos incorrectos. Esto producía conflictos entre los programadores, partidarios de seguir invirtiendo en el nuevo sistema, y los usuarios, que preferían continuar con el antiguo, porque en último término la calidad es lo que percibe el usuario final.

Otro error estratégico común es la falta de foco en lo que se está haciendo. Muchas veces he escuchado a programadores que describen sus programas en términos de cómo están hechos, o de lo que puedes hacer con ellos, pero no en términos de lo que hacen realmente. No hay que olvidar que una de las causas principales de que fracasen tantos proyectos informáticos es que los programadores, y sus jefes, son incapaces de acotar y priorizar las funcionalidades requeridas. Para ilustrar esto gráficamente, en una etapa de mi carrera trabajé para un empleador que fabricaba un ambicioso ERP. Era un sistema parametrizable y con su propio lenguaje de programación. Tenía tantas herramientas que, al final, el primer año de producción de la nueva versión había transcurrido desarrollando los kits de desarrollo mientras que la funcionalidad real que debía tener el ERP estaba prácticamente sin hacer.