No tener un diseño de calidad cuesta dinero (si lees esto no me creo que sigas gastando en malos diseños)

Quién no ha escuchado esto: “ahora invertir en calidad es un gasto económico y de recursos que no nos podemos permitir (más aún hoy con la crisis)”. Cuando uno escucha lo anterior llega a pensar que, como comenta Fowler, quien lo dice cree que la calidad es algo que se puede poner o quitar libre o alegremente.
Aunque en muchas ocasiones es cierto, no pasa nada si no se aplica calidad, normalmente en pequeños desarrollos. Pero en desarrollos software medianos o grandes saltarse la calidad implica que llega un momento en que… no se puede aumentar la funcionalidad de la aplicación. O que aumentar la funcionalidad pasa por un gasto extremo en tiempo y recursos. Y en estos casos seguir pensando que “invertir en calidad es un gasto económico y de recursos que no nos podemos permitir” carece de sentido, porque te estás gastando más al no poder evolucionar la aplicación, o al tener 10 personas demás en el equipo. Sobrecostes que te hubieses ahorrado invirtiendo en un diseño de calidad (sin copy paste –te dejo este post-, sin espagueti code –te dejo este otro post-, con buena modularidad, poco acoplado, y sin otros malos olores del diseño) .
¿Hay alguien que no se haya encontrado con esta situación? Porque yo recuerdo más de 6 y 7 organizaciones bloqueadas, con aplicaciones que ya no podían evolucionar si no era con excesivos tiempos de desarrollo para incorporar funcionalidades simples y con enormes equipos para ello. Y con el cliente presionando, porque, lógicamente, no entiende como puede tardar, y costar, tanto incorporar esa funcionalidad.

Existen muchos argumentos técnicos, además del sentido común, que explican porque sucede esto, porque si no invertimos en un diseño de calidad acabamos pagándolo económicamente. Casi todos estos argumentos se basan en el concepto de deuda técnica de Cunnninghan (dejo aquí este post sobre la deuda técnica), destacando la explicación que hizo Fowler sobre este fenómeno, para explicar el coste de un mal diseño, y que llamó la “Stamina Hypothesis”.
En el anterior dibujo podéis ver una explicación. Una aplicación software desarrollada con un mal diseño, al principio, a la hora de incorporar las primeras funcionalidades, evoluciona más rápido. Pero llega un momento en que debido a las malas prácticas incorporadas cuesta cada vez más incorporar nueva funcionalidad, mientras que en la aplicación bien diseñada el coste es mucho menor. Cada vez que incorporas una mala práctica al diseño vas acumulando una deuda que tendrás que pagar con productividad más tarde.
¿Alguna experiencia similar? Lo comentamos aquí o en twitter (@jgarzas)
 

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023