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)
 

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.

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

  1. Pingback: Bitacoras.com

  2. Hola Javier,
    Lamentablemente esa frase la estoy oyendo demasiadas veces en estas últimas semanas… La deuda técnica de un mal diseño puede llevar a la bancarrota (el equivalente a rehacerlo de cero) a un proyecto de software.
    El problema es que mientras esa «bancarrota» la paguen otros y no los que han creado el software pues siempre habrá gente que siga pensando eso (desafortunadamente estos días tenemos un caso claro equivalente en el mundo financiero).
    Pero bueno, para eso estamos, para conseguir mentalizar a clientes y proveedores y conseguir que el desarrollo de software sea sostenible 🙂
    ¿Conoces el método SQALE para gestionar la deuda técnica? Hace poco escribí un artículo en nuestro blog sobre el tema:
    http://opinion.excentia.es/2012/03/la-deuda-tecnica-y-el-metodo-sqale.html
    A ver si poco a poco conseguimos que estos conceptos que son más fáciles de entender se trasladen al mundo del software 🙂

    1. Muy buen articulo, gracias por compartirlo, esta situacion esta ahogando a muchos proyectos y todavia no se incluye la calidad como base fundamental del desarrollo. Saludos

  3. Pingback: 5 mentiras de moda sobre la calidad software - Javier Garzás, sobre calidad software y otros temas relacionados

  4. Pingback: El software de calidad lo hace el equipo de desarrollo, no el departamento de calidad - Javier Garzás | Javier Garzás

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *