El Remedio o la Enfermedad

Un remedio, según su definición, es “Una medida que se toma para reparar un daño o para evitar un inconveniente”. En este contexto y, en línea con la definición anterior, si se decide remediar una situación, es fundamental intentar hacerlo sin incorporar un problema mayor o, como dice el dicho, haciendo peor el remedio que la enfermedad. Esto es algo que, obviamente, aplica a cualquier ámbito. A continuación, algunos ejemplos al respecto.

Ejemplo No. 1
En un supermercado me encontré con una situación como la que se puede apreciar en la foto siguiente:

En términos simples, lo que se puede apreciar acá es que se han tomado medidas para asegurar el uso de los estacionamientos para discapacitados por personas que realmente los requieren. Desde afuera, puedo interpretar que la pintura en el piso no es suficiente como mecanismo de demarcación y que muchas personas han de aludir a esta situación para estacionarse ahí “por error”. Por lo tanto, para evitar esta situación, se incorporaron los letreros en altura de manera de hacer más visible la situación, sin embargo, la pregunta es inmediata y obvia:

¿Será fácil para una persona con discapacidad estacionarse ahí?
¿Es razonable pensar que, para estacionarse, primero deba mover o pedir que muevan el letrero?

Ejemplo No. 2
En un control de asistencia de un lugar público, la puerta que se ubica al lado del cajero del control de acceso, tenía un letrero como el siguiente:

El letrero dice:

FUNCIONARIOS (CAJEROS)
POR RAZONES DE SEGURIDAD QUEDA EXTRICTAMENTE PROHIBIDO MANTENER LA PUERTA ABIERTA.

       LA ADMINISTRACIÓN.

Considerando la situación, las preguntas naturales son obvias:

¿El cajero no hace caso al aviso?
¿Nadie fiscaliza el cumplimiento del aviso de la Administración?

En los ejemplos anteriores, sin desmercer las buenas intenciones, no está claro si el remedio es mejor que la enfermedad.

En el mundo del software, pasa exactamente lo mismo, sin embargo, con mucha menor visibilidad. Son ejemplos típicos de esta situación, la incorporación de restricciones en el software para evitar condiciones determinadas, requeridas por cierto, pero, como resultado de esto, no se consideran correctamente las consecuencias ni las herramientas para la administración de tales restriccones en aquellos casos que se escapan del flujo normal. A continuación algunos ejemplos.

Ejemplo No. 3
En un modelo de operación determinado, se requiere que los documentos enviados por un cliente no sean enviados más de una vez al gobierno. Dado que los documentos del cliente poseen un identificador único, se decidió implementar la restricción considerando este hecho. En régimen, si los documentos del cliente estaban correctos, no había ningún problema, sin embargo, si un documento queda con error y el cliente requiere realizar el reenvío, no hay cómo hacerlo ya que:

• El sistema lo rechaza por la restricción del identificador único
• El sistema no tiene las interfaces para eliminar el documento malo y permitir el reenvío del documento correcto.

Ejemplo No. 4
En un modelo de operación similar al anterior, realizando una optimización de un proceso, se asumió que dada las condiciones de operación del sistema y del modelo, un elemento no podía llegar más de una vez (dado un identificador único). Dado esto, se implementó una validación que controlaba esta situación y, al momento de identficar un “caso duplicado”, símplemente se eliminaba el elemento. El problema fue que, como era de esperar, llegaron elementos con el mismo identificador pero que no eran equivalentes. El error acá no es la restricción asociada al identificador único, el error es decidir eliminar el elemento y no dejar un registro, mensaje, copia o respaldo para revisiones posteriores, por lo tanto, los errores son:

• El sistema elimina los elementos duplicados
• El sistema no deja un registro asociado a la decisión de eliminar un elemento duplicado
• El sistema no posee las herramientas/mecanismos de auditoría para revisión de estos casos.

Ejemplo No. 5
Este ejemplo no es real, es símplemente un ejercicio para comprender el proceso y no caer en el error de que el remedio sea peor que la enfermedad. Supongamos una aplicación con un sistema de autenticación de usuarios por medio de un login y una password. Esta es la versión inicial. A continuación, una secuencia de funcionalidades nuevas requeridas que surgen de hacerse las preguntas correctas (ver el El Plan B).

1. Cambio de Password. Se solicita que el sistema permita que el usuario cambie su clave. Como es lógico, se requiere que el usuario ingrese su clave anterior para poder cambiarla. Se habilita la opción pero… ¿Qué sucede si el usuario no recuerda su clave anterior?, entonces, si seguimos esta pregunta tenemos dos opciones:
   • Mecanismo de Reseteo de Clave.
     Se debe habilitar un mecanismo para resetear la clave por parte del usuario.
   • Herramienta de Administración.
     Se debe habilitar un ambiente para que el administrador pueda reingresar la clave de un usuario.
2. Bloqueo de Usuario. Se solicita que el sistema bloquee al usuario si falla los intentos de ingreso más de tres veces.
   • Mecanismo de Administración.
     Si se bloquea un usuario, al igual que en el caso anterior, se requiere habilitar las interfaces para permitir desbloquearlo.
   • Mecanismo de Configuración.
     Es algo obvio, sin embargo, qué sucede si se desea modificar el número de intentos previo al bloqueo de tres a cuatro. Por lo tanto, se requiere un mecanismo de configuración para permitir modificar este valor. De esto, obviamente, es necesario hacerse algunas preguntas para asegurar que la configurabilidad sea correcta.

El desarrollo de software tiene muchas dificultades y éstas son cada vez más complejas dada la dimensión de los sistemas y el alcance global de los mismos y, por lo tanto, la incorporación de nuevas funcionalidades y, en particular, de nuevas restricciones, requiere la habilitación de los mecanismos de revisión y de auditoría para poder asegurar que las restricciones se están aplicando correctamente. Y, más importante que lo anterior, es que alguien realice la revisión correspondiente. Pero, lo más importante, es asegurar que el remedio no va a ser peor que la enfermedad.

Tweet