Desarrollo de software. Antipatrón. Con la mitad es suficiente

Nos encontramos con este antipatrón cuando ante un sistema de información de complejidad y tamaño medio/alto, con una deuda técnica alta, se solicita la realización de tareas de mantenimiento, generalmente evolutivo, de cierta envergadura, las cuáles deberían ejecutarse en un plazo de tiempo muy ajustado y se centran los esfuerzos en intentar conseguir ese objetivo, independientemente de que el producto vea incrementada su deuda técnica y complejidad.
El primer problema que nos encontramos es la existencia de una restricción temporal que condiciona los trabajos, lo que hace que se enfoquen los esfuerzos en “apagar el incendio”, dejando de lado la aplicación de determinadas buenas prácticas y controles de calidad del software si estos pudieran frenar el avance de la ejecución de las tareas.
Esto hace que el plan de proyecto se centre en dar una respuesta a la situación, dejando para el final la realización de tareas que mitiguen la deuda técnica y la simplificación de funcionalidades eliminando funcionalidades o código que no ya no tienen utilidad (ver antipatrones lava seca y ancla de barco). ¿Qué es lo que suele pasar? Pues que al final no haya tiempo para realizar esos ajustes, ya sea porque nos hemos quedado sin presupuesto y/o aparecen nuevos fuegos que ir mitigando.
Esa restricción temporal puede estar justificada ante la necesidad de adaptar un sistema de información a una normativa o para adaptar el sistema a un cambio en procesos o a un nuevo proceso que resultan esenciales para el funcionamiento de la organización y que de no estar en los plazos fijados podría suponer un importante perjuicio económico que podría incluso afectar seriamente no solo a los balances, sino incluso a la propia viabilidad de la compañía.
Otras veces la restricción temporal, pese a que pueda estar sustentada por ciertos criterios objetivos, no deja de ser un capricho de cierto personal directivo a los que un día en un “alarde de creatividad” deciden que es necesario realizar ajustes en un sistema o incluirle nuevos módulos.
El siguiente problema es la realización de cambios de cierta magnitud en un sistema con una deuda técnica elevada, que implican que cualquier tarea de desarrollo sobre el mismo (sobre todo aquellas que supongan modificaciones en módulos ya implementados) cueste muchísimo más esfuerzo (como correr con un vendaval de viento en contra, con carga en una mochila y con pegamento en la suela de las zapatillas), además de incrementarse la probabilidad de errores, tanto por posibles efectos colaterales como por la presión de ejecutar trabajo rápidamente, dejando de lado la realización de determinadas prácticas de aseguramiento de la calidad del software.
Al final, en el caso de que cumplamos el hito temporal (algo que en aquellos casos donde los plazos sean muy ajustados solo será posible priorizando tareas, teniendo a todos los stakeholders muy implicados y acertando mucho), tendremos un producto más complejo, más costoso de mantener (si cabe) y bastante más inestable.

http://jummp.wordpress.com/2012/01/21/desarrollo-de-software-antipatron-con-la-mitad-es-suficiente/