archivo

Archivos diarios: diciembre 19, 2012

En sistemas donde la deuda técnica es alta la definición y ejecución de pruebas de regresión resulta esencial. Cuando la situación del código y la arquitectura es tan mala no es suficiente con tener la sensación de que se tiene controlado todo lo que se modifica sino que además es necesario verificar que el sistema sigue funcionando de manera adecuada, incluso en aquellas partes del mismo donde se piensa que es imposible que tengan efecto los cambios realizados.

Sin pruebas de regresión estamos prácticamente jugando a los dados en cada paso a producción y un sistema en producción es demasiado serio como para esperar que la suerte siempre esté de nuestro lado.

Nada es infalible, las pruebas de regresión tampoco (lo más probable es que en sistemas con un tamaño moderado no exista la posibilidad de invertir el esfuerzo necesario para definirlas y/o ejecutarlas pero siempre se debe llegar al mínimo de probar todas las funcionalidades esenciales y críticas del sistema) pero cuanto más precavidos seamos menos sorpresas desagradables nos encontraremos después.

Llegado un punto resulta más costoso seguir mejorando un sistema de información que los beneficios que realmente produce esa mejora.

Si el producto está consolidado los cambios serán cada vez más complejos (rizar el rizo) y responderán generalmente más a caprichos que a necesidades reales. No se trata de oponerse a la evolución sino de entender cuándo produce beneficios y cuando no.

Cuanto más grande sea el producto más complejo será mantenerlo, probablemente mayor será su deuda técnica y más complicado será para el usuario (y eso es un problema).

Cuanto más cambios hagamos más posibilidad hay de que introduzcamos errores graves en la aplicación, los cuales pueden tener un efecto bola de nieve en el sistema porque si la aplicación ha tenido éxito y tiene un amplio grado de implantación se requerirá una rápida solución y todos sabemos qué pasa cuando se va demasiado deprisa: posiblemente no se corrigen todos los errores, se introducen otros y el código no tiene toda la calidad que debería.

Desde el punto de vista del usuario nunca vas a encontrar la perfección en un software, cuando creas que al usuario no se va a ocurrir nada nuevo le surgirá una nueva idea y cuando realmente se quede sin ideas aparecerá otro con un listado sin fin (cada persona tiene percepciones y necesidades distintas).

Tampoco la vas a encontrar desde el punto de vista del desarrollador, siempre tendremos la oportunidad de mejorar el código o la arquitectura, de automatizar nuevos tests, de abstraer funcionalidades, de modificar el comportamiento de una funcionalidad o de hacer nuevas propuestas.

Donald Norman realizó una reflexión que viene a refrendar lo que comento en el artículo: “Una vez que se ha alcanzado un producto satisfactorio, realizar más cambios puede ser contraproducente, especialmente si el producto tiene éxito. Tienes que saber cuándo parar”.