Rápido y sucio

Por qué la excepción no debe hacerse regla.

Hubo una vez un maestro programador que escribía programas no estructurados. Un programador novicio, buscando imitarlo, también comenzó a escribir programas no estructurados. Cuando el novicio le pidió al maestro evaluar su progreso, el maestro lo criticó por escribir programas no estructurados diciendo: “lo que es apropiado para el maestro no es apropiado para el novicio. Debes entender el Tao antes de trascender la estructura”.

Tao del programador, 3.1

Una solución rápida y sucia es modificar una funcionalidad para salir del paso. Esto tiene el beneficio de que se soluciona el problema en el momento, pero, siendo una medida temporal, no corrige el problema de fondo. Esto es conocido como anti patrón de diseño de software.

Dado que es un último recurso, quick-and-dirty debe considerarse cuando:

• Es una emergencia. Una medida de excepción. Una corrección imprescindible.
• Se tiene un equipo que conoce muy bien su producto así como las consecuencias de cambios rápidos en la experiencia de uso.
• Se cuenta con una metodología ágil que permita aplicar estos cambios rápidamente, sin sacrificar calidad y seguridad.

Pero hay que tener en cuenta que esto será tan alegre como jugar con el jabón en el baño de la prisión: es divertido hasta que se te cae. Si esto no se hace con cuidado, se pueden empeorar las cosas.

Además, este tipo de soluciones tiene desventajas adicionales: una es que, dada la velocidad de la implementación, se tiene la impresión de que esta solución es permanente y lo recursos luego se asignan a otras prioridades. Así se deja de lado implementar la real solución y se acumula deuda técnica.

La otra desventaja es que esto puede volverse una mala costumbre. Es decir, una vez hubo una solución rápida. Como fue rápida, seguro fue fácil. O sea, ¿podríamos hacerlo de nuevo, no? Estas falsas impresiones son peligrosas y terminan destruyendo sistemas enteros.

Aplicar soluciones de este tipo no tiene que ver con la agilidad. Una solución de emergencia es eso, de emergencia.

Una buena manera de evitar esto es evaluar el origen de los últimos cambios del producto: ¿tienes cambios de emergencia todas semanas (o días)? ¿son diversos los orígenes o son de una misma área? ¿es una necesidad interna o externa?

Si pasa demasiadas veces, hay un problema más grande y no necesariamente de software.

—

> Photo by Marc Kleen on Unsplash