El enemigo de la mantenibilidad

El principio y fin de cualquier aplicación software es prestar un servicio o cubrir una necesidad de negocio, como comúnmente es llamado el área funcional. Pero esa necesidad no es estática, evoluciona con el tiempo y, por tanto, el software que tiene que satisfacerla debe adaptarse.

Resulta paradójico pensar que el coste del software no se puede calcular a priori porque la fase más larga de su ciclo de vida (el mantenimiento) es, casi siempre, impredecible. Por hacer un símil, desarrollar un software a medida es como comprase un coche. Si lo miramos con una perspectiva de 5 años lo más económico es el precio del coche, lo mas caro es el mantenimiento: seguro, impuestos, revisiones, gasolina, limpieza, cambio de aceite… Con el software sucede lo mismo, sabemos qué queremos que haga en la primera versión, pero las futuras necesidades serán fruto de nuestra experiencia con él y, por tanto, son todavía desconocidas.

El principal enemigo de la mantenibilidad: la funcionalidad

Nunca debemos olvidar que el fin de todo software es ser puesto en producción y cumplir con sus requisitos, es decir, con su área funcional: con negocio. Una vez que el software esta en producción su compromiso funcional con los usuarios es mas fuerte porque hay personas usándolo. Por este motivo resulta muy difícil justificar cualquier cambio que no tenga un impacto directo en su funcionalidad. Sobretodo aquellos cambios que no aportan ninguna funcionalidad nueva y pueden estropea la ya existente.

Es por todo esto que un buen diseño acompañado de una buena implementación tiene que acometerse desde el principio. Al menos la mantenibilidad tiene que cuidarse mucho porque casi seguro que la aplicación cambiará. Después no sabremos si tendremos la oportunidad para mejorarla, porque implicará un esfuerzo que seguro será mucho mayor que haber prestado atención poco a poco a medida que se desarrollaba desde su comienzo.
Pero negocio es impaciente y, casi siempre, los plazos son muy apretados, por ese motivo (entre otros) las cosas no se hacen tan bien desde el primer momento. Esto hace que a futuro nos podamos encontrar ante dos situaciones:

  • Un cambio simple es mas costoso porque la complejidad del software es mayor de lo que debería, fruto de hacer las cosas rápido, sin pensar.
  • Un cambio simple es mas costoso porque el modo en que fue implementado el software no preveía futuros cambios.

Como podemos ver ambos casos describen una carencia en el software, algo que se debería haber hecho y no se hizo y, claro está, se paga a futuro. Esto es lo que la gente llama: deuda técnica.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>