La Arquitectura de Software y el Síndrome de la Complejidad

Como dijo Horace Greele «El sentido común es el menos común de los sentidos». Todos los que nos dedicamos en mayor o menor medida al mundo del desarrollo de software sabemos que la solución más simple es la mejor, inventamos acrónimos para recordarnoslo (KISS – Keep It Simple Silly – Hazlo fácil tonto), incluso inventamos métricas que miden la complejidad del software para advertirnos de que vamos por el mal camino, pero siempre hay algo que nos lleva hacía el oscuro mundo de la complejidad , una especie de atracción como el fatum griego que nos hace complicar lo mas simple, hasta el punto de no ver la solución trivial y encaminarnos hacia soluciones tortuosas y carentes de practicidad. Dimensionar tres meses de desarrollo para ganar menos de un segundo en una aplicación de gestión es un ejemplo claro de este síndrome de la complejidad que nos invade.

El fundamento de cualquier profesional que se quiera dedicar al desarrollo de software es poseer y saber utilizar el sentido común. Saber dar un paso atrás y ver la situación global para comprender lo que se nos pide. Y una vez que nos encontramos en esta situación darle la solución mas simple. Esta es la base de la que debe partir cualquier arquitecto de software. No hay que dejar de lado las capacidades técnicas y de abstracción pero siempre al servicio del sentido común.

Pero este síndrome no ha afectado solo a arquitectos y técnicos, llega hasta los gestores de recursos, planificadores y coordinadores de todo tipo. Si hay que tomar una decisión y se pone en la balanza la opción mas simple y en la otra una compleja pero con grandes virtudes arquitectónicas que nadie ha pedido y son totalmente innecesarias, todos sabemos cual será la elegida. Ya puedes dar datos sobre costes, riesgos, da igual, la elección siempre es la brillante, complicada e innecesaria opción más compleja.

Ejemplo para el lector: Tienes un proyecto en crisis con compromisos de puesta en producción complicados de conseguir y alguien en otro proyecto quiere reutilizar parte de tu software. ¿que harías?

1.- Le das el software, que lo copie y lo mantenga en su proyecto.

2.- Implementas un servicio reutilizable que de servicio a todas las aplicaciones que lo requieran.

El sentido común de un arquitecto debe estar alineado con los objetivos del negocio que requiere la puesta en producción en unas fechas determinadas. Evaluando esfuerzos de nuestro equipo de trabajo podemos llegar a la conclusión que entregar nuestro software y dar un mínimo soporte es fácilmente medible, pero desarrollar ese servicio reutiliazable no sabemos que puede implicar (concurrencia, alta disponibilidad, recursos, …) y es medible pero con un amplio margen de error. Seguro que muchos habéis vivido situaciones parecidas y ya sabéis cual es la respuesta.

Un llamamiento a la cordura: ¡Mantengamos el software simple!