Me ha gustado mucho el post de Nicolas Herrera sobre simplificar controladores de una aplicación web, plantea muy bien una sucesión de cambios para obtener un diseño más simple y creo que esos pasos son un buen ejemplo para ver que alcanzar la simplicidad no es un proceso fácil.

Pero una cosa es que conseguir un diseño simple sea difícil, y otra que nos empeñemos en evitar el camino sencillo y busquemos soluciones lo más complicadas y barrocas que se nos ocurran. Cualquier cosa antes que parecer que lo que hacemos es sencillo.

Full-stack overengineering

Esto de hace cosas extremadamente complicadas suele asociarse con arquitectos alejados de la realidad, que se empeñan en incluir en su arquitectura todos los conceptos que se les ocurren:

«Está claro, desplegaré en 4 servidores web, con un SQL para reporting, un par de bus para conectarlo todo, luego pongo un redis por delante para cachear, monto el CDN con akamai que me garantice disponibilidad global, un buen dashboard para monitorizar, y empaqueto cada cosa en su contenedor Docker… Listo, ya sólo me falta decidir qué aplicación hago».

En realidad, esto se da a todos los niveles y no es, ni mucho menos, algo exclusivo de la arquitectura de un sistema.

Empezando por lo que debería ser la primera fase de todo desarrollo, la concepción y definición de características, en la que es muy frecuente acabar añadiendo todo aquello que se nos ocurre «para hacer el producto más atractivo». Todo el mundo ha oído eso de que menos es más, de hacer pocas cosas pero hacerlas bien y demás, pero al final es muy tentador tener esa funcionalidad extra «por si acaso a alguien le viene bien».

Pero claro, estamos hablando de gente que no sabe de código, los que vivimos el día a día del desarrollo sí que tenemos los pies en el suelo, ¿verdad? Pues no, claro que no. Caemos en los mismos errores, aunque a nuestro nivel.

Creamos abstracciones que lo único que hacen es complicarnos la vida, en aras de una supuesta mantenibilidad desacoplamos código hasta hacerlo imposible de seguir, reimplementamos las mismas herramientas una y otra vez, abusamos de soluciones mágicas y, en general, tendemos a recrearnos demasiado en lo que nos gusta.

Incluso los lenguajes de programación y las herramientas que usamos son cada vez más potentes, hasta el punto de que parece más complicado aprender a manejarlas que resolver el problema que realmente tienes que resolver.

¿Por qué hacemos esto?

No lo sé, e imagino que habrá mil motivos, pero me atrevería a decir que algunos de ellos son relativamente recurrentes.

Por una parte, queremos sentirnos importantes. Todos estamos en este mundillo y conocemos las historias de sistemas gigantestos, con necesidad de rendimiento y escalabilidad enormes, y queremos ser como ellos. Nosotros somos igual de buenos que los ingenieros de Amazon, faltaría más. Si Netflix puede mantener un sistema con miles de servidores, ¿por qué nosotros no?

Intentamos convertir el software en un fin, olvidando que sólo es un medio. Por muy complejo que queramos hacer el software, su importancia es, ni más ni menos, la del problema que resuelve. Si el software resuelve un problema importante, ese software será importante, aunque sea un triste script en powershell. Por mucho que compliquemos el software, no vamos a cambiar la importancia del problema que resuelve.

Otro factor, ligado al anterior, es la «presión comercial». Desde los fabricantes de software nos venden sus soluciones, a veces directamente, a veces apoyados por zorros, y hay quien se deja convencer. A fin de cuentas, si has estado toda tu vida haciendo caso al fabricante X y te ha ido bien, para qué cuestionarse nada. Por supuesto, los objetivos del fabricante son venderte sus servicios, y en general, cuantos más, mejor, por lo que olvídate de que te proponga la solución más sencilla.

Incluso entre nosotros hacemos una labor parecida de «presión social». Si te dedicas a leer blogs (empezando por éste) encontrarás información sobre cosas como aggregate roots, Machine Learning y temas «que molan», y es fácil olvidar que muchas veces nuestros problemas son bastante más mundanos. Si te vas a eventos como codemotion, podrás asistir a charlas sobre «Escalando a 10 trillones de usuarios con mongodb y CQRS», pero es raro que encuentres la de «Así monté el WordPress de la panadería de mi cuñado».

Uno podría pensar que estos motivos son propios de gente sin experiencia, y que los que llevamos ya muchos años en esto no vamos a caer en el error de sobrecomplicar las cosas, pero no hay que subestimar otro factor: el aburrimiento.

Seamos realistas, por mucho que saltes de un cliente a otro, cambies de empresa o de sector, muchos de nosotros nos movemos en el ámbito de las aplicaciones «de línea de negocio», que sí, que tienen cada una sus particularidades, pero que después de unos años no presentan tantos desafíos técnicos como para mantenernos siempre alerta y motivados.

Como decía mi abuelo, cuando el diablo se aburre, con el rabo espanta moscas. Y eso hacemos. Jugamos, experimentamos y nos dejamos llevar hasta montar cosas más complicadas de lo necesario por el mero hecho de ver si es posible y de lo que podemos sacar de ellas.

El resultado es el mismo, una aplicación más complicada de lo necesaria, pero quiero pensar que esto también sirve como campo de pruebas que nos permite estar preparados cuando sea necesario. O al menos, así me gusta racionalizarlo para quedarme tranquilo.

Todo esta palabrería puede sonar rara viniendo de un tipo que usó cuatro lenguajes de programación en un mismo post para hablar de una cosa que ni siquiera entendía muy bien, pero es que en el fondo somos así: antes muertos que sencillos.