Nadie se propone diseñar mal software; más bien sucede lentamente con el tiempo.
Una estancia desordenada. Ningún diseñador se propuso crear este desastre. En su lugar, sucedió naturalmente con el tiempo, como el resultado de pequeñas decisiones malas, que destruyeron gradualmente este espacio.
Muchas personas, tratan de correlacionar la creación de software, con la construcción de una casa: ésto no sólo es incorrecto, sino que además, es peligroso.
¿Cómo construimos Casas?
Al crear una estructura, el diseñador y el constructor, son funciones separadas. En el software, la metáfora comienza a descomponerse.
El manifiesto ágil; afirma que los procesos y las herramientas siguen siendo importantes con agilidad, pero los individuos y la interacción se valoran mucho más. La mayoría, sin embargo, interpretaron el manifiesto ágil, de manera incorrecta, asumiendo que los procesos no son necesarios …
El manifiesto, también declara, «software de trabajo sobre documentación comprensiva», que ha llevado a la gente, a no ver la necesidad, de definir la arquitectura o hacer diseño de software. Esto, ha llevado a algunos conflictos entre Arquitectura y Agilidad.
El primer conflicto, es sobre la estructura del equipo: ¿ necesitamos un arquitecto de software dedicado?, o ,¿ todo el mundo es un arquitecto de software?
El principio 11 del manifiesto, afirma que «las mejores arquitecturas, requisitos y diseños emergen de los equipos auto-organizados». La buena noticia, es que el manifiesto menciona la arquitectura y el diseño. Conocemos casos de equipos exitosos, donde el rol de la arquitectura, se extendió entre los componentes, pero también , y muchos de ellos, donde no existía una clara responsabilidad de la arquitectura y el diseño; donde todo el mundo suponía, que alguien más, estaba cuidando de la arquitectura.
El segundo conflicto, tiene que ver con el proceso. Históricamente, ha habido una tendencia hacia el “primero, grandes diseños”, donde la gente, trató de «entender todo» para definir un plan. El diseño evolutivo, intentó proporcionar una solución, haciendo un cierto diseño. Pero, es difícil cambiar el software, cuando la arquitectura resulta ser incorrecta: la refactorización puede ser costosa.
Para solucionar los problemas con la arquitectura, necesitamos entender lo que realmente es ágil. La definición central propuesta:
«Agile» es un enfoque ligero, para ofrecer software, basado en una mentalidad y cultura, de mejora continua.
El principio 9 del manifiesto afirma, que «la atención continua a la excelencia técnica y al buen diseño aumenta la agilidad». Una buena arquitectura permite agilidad.