El sistema de valores

Nos gustaría comenzar esta sección con una tesis aparentemente provocadora:

No hay mantenimiento de software.

El mantenimiento es un proceso proactivo. En los sistemas de producción, las piezas se sustituyen periódicamente antes de que se rompan. Se sustituyen porque la experiencia ha demostrado que la fiabilidad caería por debajo de un valor crítico si continuara el funcionamiento. Así, antes de que todo el sistema se detenga, las piezas críticas se sustituyen a tiempo. Todo automovilista sabe que debe cambiar el aceite con regularidad. No porque el aceite se haya gastado en ese momento, ni siquiera porque el aceite ya sea completamente ineficaz en ese momento. No, se cambia porque la experiencia del fabricante demuestra que el motor está protegido cambiando el aceite a tiempo y, por tanto, dura más.

Nada de esto existe con el software. El software es lo que es. Suele contener errores. Pero incluso estos errores son como son. No se puede hacer nada de forma proactiva para mejorar el estado del software.

Por supuesto, hay acciones proactivas cuando se opera el software. Por ejemplo, puede ser necesario comprobar periódicamente si los archivos de registro aún tienen suficiente espacio libre en el disco duro, si una base de datos está desbordada o si la memoria se está llenando. Pero el propio software no se puede mantener de forma proactiva. Cada cambio o ampliación se hace para eliminar un error o aplicar requisitos nuevos o modificados.

Para que los cambios sean posibles, el software debe tener una estructura interna que favorezca dichos cambios. Es lo que llamamos "capacidad de cambio". Los programas informáticos suelen utilizarse durante largos periodos de tiempo. Durante este tiempo, las condiciones marco cambian y es necesario añadir características. Lo ideal es que la implementación de una función cueste una cantidad fija que sea independiente del momento en que se realice la función.

En la práctica, sin embargo, el precio de una característica aumenta cuanto más tarde se realiza. Al principio, las funciones son baratas, pero al final ya no es posible añadirlas porque nadie puede verlas. El software se tira y se vuelve a desarrollar. Hasta llegar a este punto, los costes aumentan exponencialmente. Hay dos cosas comunes en el crecimiento exponencial: 1) Al principio, apenas se reconoce que los costes aumentan. Los aumentos son moderados. 2) Cuando te das cuenta de que los costes están aumentando, ya es demasiado tarde. De repente, el aumento avanza tan rápido que ya no es posible contrarrestarlo.

Cuanto más fácil sea adaptar el software a las condiciones cambiantes, mayor será su adaptabilidad. Pero la adaptabilidad no puede lograrse a posteriori. Hay que tenerla en cuenta desde el principio. El software debe diseñarse para ello.

He aquí un ejemplo: las clases deben tener exactamente una responsabilidad. Si una clase es responsable de más de una cosa, es más difícil seguirle la pista. Esto dificulta los cambios, ya que requieren una comprensión del código fuente que se va a modificar. Además, aumenta el acoplamiento entre las clases. De repente, todo está conectado con todo lo demás. Esto sólo puede evitarse si las unidades funcionales tienen responsabilidades claramente definidas y el acoplamiento se mantiene a la vista. Si en un sistema de software se han acumulado varias clases, cada una de las cuales es responsable de varias cosas, es difícil eliminar esta situación a posteriori. El acoplamiento es tan grande que resulta difícil separar las unidades funcionales individuales. Si hay que realizar nuevas funciones en esta espesura, se tarda mucho tiempo. Si no se empieza a tiempo a despejar la espesura, la situación empeora cada vez más. Llega un momento en que resulta casi imposible añadir nuevas funciones. El super-GAU del desarrollo de software.

Creemos que no tiene por qué ser así. Si se tiene en cuenta la capacidad de cambio desde el principio, el software puede seguir desarrollándose durante largos periodos de tiempo. Los costes por función pueden aumentar ligeramente con el tiempo. Pero en ningún caso exponencialmente.