Una crítica a la arquitectura Spring clásica

He estado leyendo el artículo Understanding Spring Web Application Architecture: The Classic Way.

Creo que es un buen artículo porque explicita algo que no mucha gente hace en esta clase de cosas: cómo se distribuye la lógica del dominio en la  arquitectura que propone. En este caso, la divide entre servicios, objetos entity, objetos value, etc … y aunque no lo haya puesto de manera explícita, es habitual que, en el mundo real, la lógica del dominio llegue a los controladores de las vistas. Precisamente ésa es la principal crítica que se le puede hacer: propone un modelo del dominio anémico, lo que supone problemas de testeabilidad y comprensión de las reglas del dominio, dos de las actividades que me parecen más fundamentales en el desarrollo de software. No es un problema menor.

Sin embargo, hay otra crítica que se le puede hacer a estos sistemas. Con un impacto igualmente importante, pero quizás más sutil y difícil de ver: tienen un mayor riesgo de quedarse obsoletos. Este tipo de sistemas tienden a ser usados (por su propia manera de ser) como un todo: usas desde el ORM que empaqueta hasta su sistema de directivas HTML/JS (que, obviamente, tiene sutilezas que lo hace distinto a HTML y JS). Suele ser complejo integrar cosas diferentes a las que te propone el framework. Esto hace que seas vulnerable en áreas donde exista gran volatilidad o innovación. Por ejemplo: hoy en día, es inmensa la innovación que se está dando en las interfaces con HTML y JS, tanto por la consolidación de nuevos estándares –HTML5, ECMAScript6– como por la propia dinámica de la industria que ha apostado fuerte por estas tecnologías en los últimos años. Por lo tanto, si usas un sistema de plantillas propio del framework que sea un sucedáneo de HTML y JS, estás invirtiendo en un conocimiento/tecnología específico que en breve tiene grandes posibilidades de quedarse obsoleto.

Hasta aquí la crítica. Me parece importante entender también el atractivo que tienen este tipo de sistemas todo-en-uno. Desde luego que son atractivos al inicio, ya que venden que puedes construir una aplicación en un par de días sin programar ni pensar sobre cómo hacerla. Probablemente sí puedas hacer alguna cosa muy rápido. Me imagino que las primeras semanas pueden ser un camino de rosas. Pero lo que veo en el mundo real es que, a medida que inviertes tiempo en un framework todo-en-uno, los riesgos de encontrarse con sus límites y quedarte bloqueado son altísimos: costes altos de mantenimiento por falta de integración de tests, semanas de desarrollo para hacer lo que parece una pequeña mejora porque supone revisar la lógica en varios lugares e implementar la nueva petición en otras tantas capas, interfaces que no son tan atractivas como las de los competidores, etc.

Para mí, estos son unos riesgos no menores que no asumiría a no ser que los pros fuesen espectacularmente altos. Y habitualmente no lo son. Es muy fácil dejarse llevar y no darse cuenta de estas sutilezas, pero es igualmente peligroso, porque entonces serán los clientes los que te pidan más de lo que puedes dar a un precio competitivo o directamente contraten a otra compañía que se lo pueda ofrecer. Por eso me parece que la selección tecnológica no es meramente una cosa técnica, sino que tiene un impacto muy alto en el futuro de los productos que tu empresa puede ofrecer y conviene tener en cuenta tu contexto y no tomársela a la ligera.

Del diseño de los centros comerciales

Who enjoys shopping at IKEA? es un recorrido por diferentes diseños de tiendas y centros comerciales, que explica por qué Harrods vendía los sábados menos de lo esperado o cómo los recorridos de IKEA favorecen que el 60% de lo que nos llevamos  no esté en nuestra lista inicial de compra. Walmart bien pudo haber aprendido esto antes de perder billones de dólares con el rediseño de sus pasillos. Al hablar de ratios de conversión y accesibilidad, hay lecciones que se pueden extrapolar al diseño de interacción.

«Too often, universities try to contain the results of research in the hope of commercially exploiting the resulting intellectual property. Politicians believe that setting up tech-transfer incubators around universities will bring significant economic gains in the short or mid-term. It could happen. So couldwinning the lottery.»
Buxton refiere investigaciones hechas en Microsoft para la Academia de Ciencias estadounidense. Afirma que las grandes innovaciones tecnológicas tardan enormes cantidades de tiempo y dinero en hacerse mainstream. Las implicaciones que tiene el informe para la financiación de la transferencia tecnológicas son claras: una fuerte inversión estatal en investigación básica sostenida en el tiempo, con inversión privada en las últimas etapas para llevar la innovación a mercado.

image

La galería de objetos interactivos de Bill Buxton es una gozada (y me da impulso para ampliar mi propia compilación). Te puedes encontrar cosas como la historia del trackpoint o pointing stick de IBM contada por el propio Ted Selker, inventor del dispositivo. Novelada por Malcom Gladwell, esta historia podría ejemplarizar la dureza de llevar al mercado una innovación: trabas burocráticas y técnicas, momentos de bajón, tesón y premio final.

Me pregunto dónde estarán ahora los Ted Selker de nuestra generación.

Atom 1.0 ha sido publicado. De alguna manera salió de mi radar y se me pasó que hay paquetes para Linux desde hace meses. Declaran que en 1 año han hecho 155 releases, es decir, 3 por semana. Todavía me sorprende lo bien que funciona y lo mucho que se ha extendido el estilo agile: si es que ha sido 4 años atrás cuando los grandes adoptaron este estilo! La apuesta de Atom es alta: unir emacs y las chrome devtools. Creo que es la primera release de un editor que me genera expectativas.

Cómo está cambiando la industria del software

image

Se podría decir que The software paradox, de Stephen O’Grady, relata cómo la irrupción del software libre e internet en los 90 han erosionado la venta de licencias de software como el principal motor económico de la industria, en favor de otros espacios de la cadena de valor. Cómo el software pasa de ser vendido como un producto standalone a ser parte de otra cosa: servicios (amazon, atlassian), productos (apple, nest), publicidad (google, facebook). Quizás no resulte una lectura novedosa para el que sigue el día a día de la industria, pero es muy agradecida por su análisis de varios casos de compañías del mundo tecnológico.

Recomiendo compaginarla con la charla Software G forces: the effects of aceleration de Kent Beck. Me parece que se comprende todavía muy poco cómo las metodologías ágiles sirvieron de catalizadores en esa transición, cómo la reducción del time to market habilitó el nacimiento de estos gigantes.

«Silk Road offers a neat political parable for the rising liberartian tide in Washington and the smug pride of today’s Sillicon Valley, where self-appointed revolutionaries of all stripes believe their powers allow them to trascend tradicional moral boundaries, including their own mortality. In a way Silk Road is the dark mirror of The social network, a wild technological succes story taken to its logical extreme conclusión.»

La historia sobre Silk Road (el ebay de productos ilegales) que publica Wired en dos partes -el ascenso y la caída– bien podría simbolizar el Eliot Ness VS Al Capone de nuestra generación.

Es una lectura que requiere un par de horas, pero que valen la pena. La narrativa es digna de novela negra. La exposición de un tema nada fácil, clara y accesible a público general con un mínimo conocimiento tecnológico (saber lo que es una IP y conocer TOR). Profundiza en ciertos detalles oscuros del caso y dibuja a Ross Ulbricht desde varios puntos de vista.

«The notion of a logo equity has been with us from the very beginning of time. When we were asked to design a new logo for the FORD Motor Company, we proposed a light retouch of the old one which could be adjusted for contemporary applications. We did the same for CIGA HOTELS, CINZANO, LANCIA Cars and others. There was no reason to dispose of logos that had seventy years of exposure, and were rooted in people’s consciousness with a set of respectable connotations.

What is new is NOT a graphic form but a way of thinking, a way of showing respect for history in a context that usually has zero understanding for these values.»

— Massimo Vignelli, The Vignelli canon

Tengo en la memoria la reciente visita a Glasgow. Cómo el diseño que Mackintosh hizo para la GSA me pareció una actualización de la Glasgow University: mismos materiales, idénticas ideas básicas sobre la el aprovechamiento de la luz con sus ventanas enormes, pero formas estilizadas para la época. Lo mismo con algunos diseños para muebles. Como Vignelli, el pasado y la continuidad histórica como inspiración.

Diseño y testeabilidad

Todo programador que lleve un tiempo en esto, ha vivido debates sobre «arquitecturas» o «patrones de diseño». Dentro de la serie que he iniciado para hablar de desarrollo de software en una PYME, creo que estos debates tienen un encaje fundamental porque una vez seleccionas tecnología tienes que darle forma de alguna manera. Y esa manera es el «diseño» o «arquitectura» de tu producto.

El «buen diseño»

Lo primero que conviene recordar es que la reducción de los tiempos de producción y mayor calidad de producto es el camino de una PYME para ofrecer el máximo valor posible al cliente. En el mercado, eso te pone en una situación favorable con respecto a tu competencia. Definiremos, pues, como «buen diseño», aquel que se pone al servicio de la producción, que permite aumentar la calidad y reducir los tiempos de desarrollo.

Podemos continuar y definirlo como flexible y mantenible, bello y que hace sentirse orgulloso al que lo crea, etc. Pero el problema no es tanto definirlo, sobre lo que existe mucha literatura, sino cómo se llega a él y cómo se mantiene a lo largo del tiempo. Porque tenemos que reconocer que no es fácil y que existen varios problemas. Para empezar, no existe un diseño universal válido sino que hay tantos como contextos, que las personas, además, insisten en tener diferentes opiniones sobre qué es un «buen diseño» y que ambas cosas se reflejan en el código – lo que fácilmente puede convertir tu producto en una torre de babel ininteligible si no se construye una visión común. Tenemos, además, estructuras de comunicación disfuncionales que provocan diseños sub-óptimos, deuda técnica y requisitos cambiantes que introducen variantes a lo largo del tiempo, rotación de personas en los equipos y distintos niveles de experiencia que dificulta la transmisión de ideas, etc. Es decir, el software, su diseño, se ve afectado por las fuerzas humanas y organizacionales. ¿Cómo podemos ponerlo a salvo? ¿Cómo asegurarnos de que las fuerzas están en equilibrio y el diseño sirve a nuestros objetivos?

Necesitamos salvaguardas que nos permitan calibrar qué es un «buen diseño» y controlar su degradación a lo largo del tiempo, herramientas que nos ayuden a caminar hacia a él y nos orienten.

Los tests como salvaguardas

Michael Feathers, en su libro «Working effectively with legacy code» desarrolla la idea de cómo trabajar con software que está degradado. Cómo, partiendo de código degradado, se puede conseguir un «buen diseño» a partir de las restricciones habituales en el día a día (tiempos limitados, código con altas dependencias, etc). Es un libro por ello interesantísimo porque te cuenta ciertas maneras de cómo llegar a ese buen diseño. Y su principal herramienta son los tests:

«When you start to try pull out individual classes for unit testing, often you have to break a lot of dependencies. Interestingly enough, you often have a lot of work to do, regardless of how “good” the design is. Pulling classes out of existing projects for testing really changes your idea of what “good” is with regard to design. It also leads you to think of software in a completely different way.»

Empatizo por completo con su visión. Sobre los tests hay poco que decir: tener o no tener, that’s the question. Porque tenerlos afecta a la producción a varios niveles:

  • El primer efecto y más obvio es que, tenerlos, reduce los tiempos más inciertos y difíciles de estimar en proyectos de software: el testeo manual que hay que hacer en cada versión y el bugfixing. En gran medida, estos tiempos son los que suelen determinar que un proyecto sea o no rentable.
  • Otro efecto un poco más indirecto es que, para desarrollar software testeable, necesitamos dividirlo en trocitos, evitar y romper las dependencias. Es decir, estamos en la dirección de desarrollar software reutilizable, reducir la complejidad.
  • Quizás un poco más sutiles sean los efectos a nivel personal, pero no menos importantes. Por un lado, aportan seguridad y confianza en tu trabajo a posteriori ya que tienes algo objetivo y automático que te dice que funciona. Pero es que además, durante el proceso, tener feedback continuo te ayuda a enfocar tu trabajo y a mantener tu moral alta a base de pequeñas victorias cotidianas. Y la moral, en tareas creativas, es un factor clave en la productividad.

Conclusiones

Tests y diseño van de la mano. Una vez has sentido sus efectos, tu visión cambia. Aprendes que un buen diseño es un diseño testeable. Porque eso es lo que te va a permitir reducir tiempos de producción y aumentar la calidad de lo que ofreces, ganarte la vida desarrollando software de un modo sostenible, que, al final, es de lo que va todo esto.