El informe nos ofrece cifras de los proyectos de software, de su éxito, de su fracaso, o de proyectos cuestionados (es decir, que han costado más de lo inicialmente previsto, económica o temporalmente, o que no alcanzan los requisitos y se quedan a mitad).

La tendencia dice que vamos a peor. Afortunadamente han mejorado los proyectos con éxito pero aún así sigue siendo insuficiente.

¿Y todo esto por qué?

Porque el software es intangible, físicamente no tiene forma ni volumen.

Entender el software requiere un gran esfuerzo

• Porque el tamaño del software hace que sea difícil de leer y estructurar.
• Porque la complejidad es muy alta y con el software intentamos resolver problemas difíciles.
• Porque el software evoluciona… Cambia muy rápido, se adapta, y lo que entendíamos hoy mañana ya no sirve…

Muy bien, y entonces ¿qué podemos hacer para entender el software?

TENEMOS QUE VERLO

Tenemos que ser capaces de entender el software “viéndolo”. Parecerá un ejemplo "cutre" pero ¿cómo ayudó a Neo en The Matrix el llegar a “ver el código”?

Ver el código le permitió ENTENDER, y así resolver los problemas más rápidamente.

VER ES ENTENDER.

Hagamos un poco de historia y repasemos grandes acontecimientos... Londres, 1854. Epidemia de cólera. 

Dos tendencias, los contagionistas, pensaban que se transmitía por el contacto, y la teoria miasmática, transmitido por el viento, por los miasmas: vapores tóxicos emitidos por descomposición que transportaban de un lugar a otro el cólera.

En medio de todo eso llegó John Snow (si, si, y no tiene nada que ver con Juego de Tronos), y convencido de que debía haber otras causas, comenzó a realizar un estudio de cada caso, así que cogió su libretita y fue a visitar a todos los enfermos, y fue apuntando las zonas donde vivían y donde se desplazaban.

Hizo un mapa y detectó que se concentraba la mayor parte de los fallecidos cerca de un pozo de agua.

Con ese mapa resolvió uno de los mayores problemas de la época, y se convirtió así en el padre de la epidemiología moderna. 

Una sola imagen bastó para detectar donde estaba el problema:

Mapa de casos de cólera de John Snow

Una imagen vale más que mil palabras

Pero cuidado, que algunos se lo toman al pie de la letra y se construyen UMLs o Gantts pensando que ayuda a ver mejor el estado y resulta que en esas “imágenes” hay más de mil palabras. No vale poner palabras y hacer lineas de un lado a otro ;-)

Así no, estas imágenes no siempre valen para ayudar

Así que aquí es donde viene la visualización al rescate:

Y todo esto tiene sentido, ¿no conocéis los principios de Gestalt? ¿Proximidad, cierre, conectividad, semejanza? Nuestro cerebro procesa la información teniendo en cuenta toda esa información y nos permite extraer conclusiones simplemente al verlo.

¿Cuántos grupos ves en cada imagen?

La mente configura a través de ciertas leyes los elementos que llegan a ella a través de los canales sensoriales (percepción) o de la memoria (pensamiento, inteligencia y resolución de problemas). La forma, orientación, longitud de línea, curvatura, grosor de línea, marcas, tamaño, ... nos ayudarán a detectar visualmente elementos diferenciadores en las imágenes.

Más del 70% de los estímulos externos que percibe el organismo provienen de la función visual.

Muy bien, ¿pero entonces? ¿qué visualizamos del software para entenderlo? Pues evidentemente el código fuente. ¿Os suena el coloreado de sintaxis? ¡guau! Una aplicación de los principios de Gestalt sobre el código ;-)

¿Y qué más podríamos visualizar? Métricas, muchas métricas, hoy día ya tenemos métricas para dar y tomar…

Visualización de estructura del código

Pero todo esto es complejo y tenemos que abstraernos un poco:

• podemos ver la estructura, con diagramas de paquetes o clases, por ejemplo, esto ayuda un poco a entender la arquitectura de un proyecto, ¿verdad?

• podemos usar las vistas polimétricas… Cada nodo es un elemento software, y cada línea es una relación entre esos dos elementos. El tamaño de cada nodo se puede representar con diferentes métricas (alto y ancho) según lo que nos interese ver. El color puede ser otra métrica.  Lo interesante es que podemos ver esas jerarquías o relaciones y también evaluar tamaño y complejidad.

Vistas polimétricas

• podemos usar los mapas de distribución. Cada rectangulo pequeño es una clase, que esta agrupados en paquetes (rectangulos grandes), y el color de cada clase viene determinado por el concepto predominante (o funcionalidad principal de las clases, o lo que me interese conocer).

• podemos usar mapas de paquetes… Muestra quien “posee” cada clase y sus jerarquías.

• ¿y quién no ha usado alguna vez un treemap (o mapa de árbol)? El resultado final es una visualización muy intuitiva y dinámica de un plano dividido en áreas proporcionales a los datos que representan, jerarquizado por tamaños y código de color, y optimizando el espacio.

  Forma circular

• otra forma es representar nuestros elementos de software en forma circular, y dibujando líneas entre ellos con las dependencias (rojo=invocado, verde=invocador). En el ejemplo las unidades 16 y 18 son las que más veces se invocan pero es difícil saber desde donde. Demasiado ruido en la imagen. Aunque esta forma de representación evoluciono para intentar ser más limpia.

• incluso tenemos diagramas de arco para detectar código duplicado… complicado pero visual…

¿Pero es todo esto suficiente?

Un día comiendo en restaurante japonés, con grandes amigos, Paco, Carlos y Hugo la conversación fue volviéndose cada vez más "friki" (de cuatro informáticos no puede salir nada bueno). Uno de los problemas que teníamos en excentia era como poder trasladar la complejidad del mundo del software a todo el mundo, sin necesidad de entender métricas ni ver números ni ser expertos en calidad. Hacer tangible lo intangible.

Y recuerdo perfectamente ese momento, en el que Carlos estaba de reformas en su casa del pueblo hablándonos de las "chapuzas" de los obreros, cuando nos dimos cuenta de que quizás lo más visual sería representar el software como una ciudad, como casas, como edificios. Y es ahí donde surgió la idea de City Model y empezamos a crear la metáfora de la ciudad para representar el código, el nacimiento de un producto que hoy día puedes descargar directamente en cualquier instancia de SonarQube, pero todos estos detalles ya los dejo para el siguiente artículo ;-)