Ya, ya… Keep It Simple, Stupid… ¿pero cómo?

Complejidad Que seguir el principio KISS y mantener nuestras metodologías, nuestras arquitecturas, nuestros diseños, nuestras clases etc… simples nos proporciona innumerables ventajas es algo que todos los desarrolladores de software tenemos claro desde un principio o acabamos aprendiendo a la fuerza. La simplicidad en una característica que, cuando hablamos de desarrollar o diseñar software, es buena en si misma.

 

La paradoja es, que si bien sabemos lo anteriormente comentados, no es menos cierto que a menudo acabamos con procesos de desarrollo o  con soluciones demasiados complejas. Evidentemente hay dos aspectos claves a la hora de luchar contra la complejidad: uno, detectarla, el otro combatirla.

 

Hoy voy a hablar de que estrategias tenemos a la hora de combatir la complejidad. La verdad es que antes de estar leyendo Simple Architectures for Complex Enterprises de Roger Sessions, no tenía ni una idea explícita sobre este tema. Pero lo que comenta este libro sobre el tema es sumamente interesante. Aunque siempre he creído que la complejidad es uno de los mayores enemigos de los procesos de desarrollo y los sistemas de software nunca me había plantead, antes de la lectura de este libro, de manera explicita, con que tácticas contamos a la hora de atacar la complejidad.  Las tres tácticas con las que contamos son: el particionado, la simplificación y las iteraciones.

 

El particionado consiste en dividir grupos de elementos en elementos menores. Esta táctica es quizás la más poderosa de las tres y, de manera consciente o no, la utilizamos continuamente en el desarrollo de software. Particionados nuestras arquitecturas en capas, de manera que cada una de ellas solo tenga que lidiar con las complejidades propias de su cometido. Nuestra capa de acceso a datos, solo tiene que atacar las complejidades relacionadas con la obtención o persistencia de los datos, pero no se preocupa por las complejidades de la capa de presentación. Particionar la complejidad de manera explicita nos permite atajarla de manera clara. La complejidad crece exponencialmente. Mezclar en una misma capa de la aplicación acceso a datos, e interfaz de usuario, no hace nuestra aplicación el doble de compleja sino que añade varios ordenes de magnitud.  Cuando hablamos de arquitecturas SOA, dos de los pilares de SOA abogan claramente por el particionado: los límites de los servicios son explícitos y los servicios son autónomos.

 

El particionado también es una técnica que las metodologías usan a la hora de reducir la complejidad. Las metodologías ágiles proponer dividir la complejidad de implementar un solución completa en historias de usuario independientes, testeables y simples. Esto es claramente una estrategia de particionado que nos permite atacar la complejidad de un desarrollo en pequeñas historias de una complejidad acotada.

 

En el libro, Roger Sessions cuenta un caso en el que las particiones reducen la complejidad de forma clara y visual cuando estas son adecuadas. Imagináis una tienda en la que la ropa estuviese ordenada por colores ¿no sería extremadamente complejo el proceso de compra?. Sin embargo en todas las tiendas de ropa las particiones que aparecen tiene sentido: caballeros, señoras, niños…, ropa de vestir, ropa deportiva, ropa de dormir, ropa interior… XXL, XL, L, S… con estas particiones ¡la complejidad de realizar una compra es infinitamente menor que si las partición fuese por colores!.

 

Una vez tenemos particiones explicitas, podemos proceder a utilizar la simplificación. La táctica de simplificación mas poderosa es la eliminación. No ha táctica más poderosa de simplificación que eliminar aquellas particiones que no son relevantes. Si eliminamos completamente una historia de usuario, hemos reducido su complejidad a cero: no tenemos que diseñarla, implementarla, probarla o mantenerla. Desgraciadamente esto no siempre es posible: debemos eliminar tanto como sea posible, pero evidentemente no podemos eliminar todas las particiones, es necesario un equilibrio. Pero sin duda merece la pena observar nuestro proceso de desarrollo, nuestra arquitectura, nuestros diseños y nuestras soluciones para eliminar todos aquellos elementos, todas aquellas particiones que añadan complejidad.

 

A veces, si bien no es posible eliminar completamente una partición, si podemos eliminar algunos de los elementos que la componen. Por ejemplo, en un sistema de gestión de almacenes, podemos tener historias relativas a ajustes de almacenes y a informes. No podemos eliminar completamente ninguna de estas particiones sin que el sistema pierda su utilidad, pero seguro que podemos eliminar algunas historias relativas a ajustes y algunas relativas a informes.

 

La otra manera de combatir la complejidad es la iteración. Implementar las particiones de manera iterativa y revisar la complejidad al fin de cada iteración es un mecanismo poderoso que complementa las dos tácticas anteriores. Os remito aquí a un post anterior sobre velocidad de iteración frente a calidad de iteración.

 

Recordad, contra la complejidad: partición, simplificación e iteración.

11 comentarios en “Ya, ya… Keep It Simple, Stupid… ¿pero cómo?”

  1. Muy bueno!! me encanta!!
    A modo resumen:

    – Divide y vencerás
    – No dejes para mañana lo que puedas simplificar hoy.
    – No por mucho madrugar… ponte metas cortas y asequibles.

    Un saludo!!

  2. ¡Excelente explicación! Nunca había pensado en como simplificar las cosas de manera explícita. Una vez leído tu post parece de sentido común.

    El libro ese está inpirandote bastantes artículos de calidad para el blog. Estoy por comprarlo…

  3. En mi opinión creo que muchas veces dotamos a nuestra aplicaciones de una complejidad excesiva, hay veces en que la decisión de realizar una arquitectura en n-capas no será la más adecuada, en algunas ocasiones realizar el desarrollo en dos o incluso en una sola capa puede ser más adecuado que realizarla en mas. El tiempo y la complejidad de las aplicaciones son factores importantes que debemos tener en cuenta. De la misma forma que es un error no dividir bien nuestras aplicaciones en ocasiones dividirlas en exceso puede ser un error mayor ya que la complejidad en el desarrollo aumenta, de igual forma, otras veces implementamos en nuestras aplicaciones funcionalidad adicional que en muchos casos los usuarios ni siquiera utilizan y que solo añaden complejidad a nuestras aplicaciones.

    Esto me hace pensar en la importancia que tiene dividir comprender bien el problema que queremos solucionar. Las aplicaciones cada vez más, tienden a incorporar mayor número de características, diferentes tecnologías y sistemas, más reglas, muchas “mejores prácticas”, en resumen mas complejidad, no sé, quizás…, no estemos haciendo algo bien…

  4. @grunchitog: que tienen que ver lo que tu comentas (patrones) con el tema del post. Se que los patrones pueden ser un camino hacia la simplicidad, pero también pueden ser una fuente de complejidad… si se olvidan algunas de las obviedades que comento en el post.

    De todo modos, puestos a ser rigurosos y concretos, no estaría mal algo más constructivo que un comentario de dos líneas y un link sin contexto alguno.

    ¡Un saludo!

Deja un comentario

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