HypótesisDeResistenciaAlDiseño

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

¿Merece la pena el esfuerzo para diseñar el software bien?

De vez en cuando tengo conversaciones indirectas sobre si el diseño de buen software es una actividad que vale la pena. Digo que estas conversaciones son indirectas porque no creo que me haya encontrado a nadie diciendo que el diseño de software no tiene importancia. Por lo general es expresado de la forma " realmente tenemos que ir rápido para cumplir nuestro objetivo el próximo año y entonces reducimos ".

Existe la noción de que el diseño es algo que se puede comerciar para conseguir una mayor velocidad. De hecho he tenido la impresión un par de veces de que el esfuerzo de diseño es aceptado para mantener a los programadores felices aun cuando esto reduzca la velocidad.

Si fuera cierto que dedicar esfuerzo en el diseño reduce la eficacia de la programación, yo estaría en contra de ello. De hecho pienso que la mayor parte de los desarrolladores de software estarían contra el diseño si fuera cierto. Los desarrolladores pueden discrepar sobre qué exactamente es un bueno diseño, pero están a favor de cualquier tipo de buen diseño que les favorezca porque crean que mejora su productividad. (Y por "diseño" aquí quiero decir diseño Up-Front( previo a la programación y pruebas) o el acercamiento ágil, esto es el diseño planificado o evolutivo.)

Las actividades de diseño ciertamente consumen tiempo y esfuerzo, pero se rentabiliza porque hacen más fácil desarrollar el software en el futuro. Se puede ahorrar tiempo a corto plazo descuidando el diseño, pero esto acumula
TechnicalDebt que reducirá la productividad más tarde. Dedicar esfuerzo en al diseño de software mejora la resistencia de su proyecto, permitiéndole ir más rápido durante más tiempo.

Un modo de visualizar esto es el pseudográfico
siguiente.

El pseudográfico traza la funcionalidad entregada (acumulativa) frente al tiempo para dos proyectos imaginarios estereotipo: uno con buen diseño y otro sin diseño. El proyecto que no hace diseño no gasta esfuerzo en estas actividades, como lo hay en diseño Up-Front o en técnicas ágiles. Como no hay ningún esfuerzo dedicado en estas actividades el proyecto produce funciones más rápido al principio.

El problema con sin diseño, es que por no dedicar esfuerzo al diseño, el código base se deteriora y se hace más difícil de modificar, lo que baja la productividad, que es el gradiente de la línea. El diseño bueno mantiene su productividad más constantemente, de modo que en algún punto (la línea de rentabilidad de diseño) se alcanza la funcionalidad acumulada del proyecto sin diseño y seguirá haciendolo mejor.

Llamo a esto una hipótesis porque es una conjetura, no hay ninguna prueba objetiva de que este fenómeno en realidad ocurra. En términos científicos no es una hipótesis muy buena porque es difícil de probar. Nosotros no podemos medir la productividad ( CannotMeasureProductivity) ni podemos medir la calidad de diseño.

Pero a pesar de ser sólo una hipótesis, esto es también un axioma para muchas personas, incluyéndome a mí. No podemos tener la prueba objetiva de que este efecto ocurre pero muchos de nosotros sentimos que esto explica lo que nosotros vemos cualitativamente en el campo. Esto es un axioma para mí al igual que es la suposición que sostiene mi carrera entera como escritor sobre diseño de software. Si el diseño en realidad no mejora la productividad de algún modo, la mayor parte de mis escritos no tienen valor.
Estoy seguro de que suena extraño a mucha gente tratar una hipótesis como un axioma, pero es algo habitual de hacer. Lo considero como que uso mi juicio para evaluar que la hipótesis es verdadera, pero no lo puede hacer sin considerar la debilidad objetiva de la hipótesis. Me gustaría encontrar una forma de demostrarlo y casi tanto como para refutarlo.

La hipótesis tiene un corolario, que viene de la línea de rentabilidad de diseño. Si la funcionalidad para su liberación inicial está por debajo de la línea de rentabilidad de diseño, entonces puede valer la pena intercambiar la calidad de diseño por la velocidad; pero si está por encima de la línea entonces la compensación es ilusoria. Cuando su entrega está por encima de la línea de rentabilidad de diseño, descuidar el diseño siempre hace llegar más tarde. En los términos usados en la deuda técnica decidos que esto es como obtener un préstamo, pero no utilizar el principal durante tanto tiempo, que cuando se usa se ha gastado más en pagos de interés.

Esto genera la pregunta de donde está la línea. Incluso con la gente que acepta la hipótesis de resistencia de diseño hay sustanciales e importantes diferencias sobre dónde está la línea de rentabilidad. Opino que está muy por debajo de lo que la mayoría de la gente piensa: por lo general semanas no meses. Pero otra vez esto sólo puede ser un juicio.

Esto conduce a una consecuencia para la Deuda Técnica. La Deuda Técnica es una analogía fantástica y lo uso con frecuencia. Pero la línea de rentabilidad de diseño nos recuerda que el obtener una Deuda Técnica sólo merece la pena hasta cierto punto. No solamente tenemos que considerar si el valor entregado es mayor que los pagos de interés, también tenemos que juzgar en primer lugar si la entrega está por encima de la línea de rentabilidad.

Artículo Original
________________________________________