Antes muerto que sencillo

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.

6 comentarios en “Antes muerto que sencillo

  1. Supongo que poco a poco vas aprendiendo a ignorar esos cantos de sirena. Pero siempre cuesta abandonar esa prometedora linea de experimentacion por una mas ramplona y practica (aunque no siempre mas simple)
    Tambien ayuda el tener tiempo e interes (o frikismo) en montarte tus propios chiringuitos por amor al arte.
    Aunque a veces da vertigo el ver el abismo entre lo que «tienes» que hacer y lo que puedes hacer en tu tiempo libre

  2. En términos generales, creo que si existieran procedimientos claros para lograr el objetivo final no ocurriría lo que comentas.

    Así, yo achaco como «caldo de cultivo primordial» el caos, la vorágine, el batiburrillo, el cajón de sastre que es sin duda el «paradigma» del desarrollo del software hoy en día.

    Cualquier profesional motivado busca nuevas vías que le permitan expresarse, destacar, innovar, aprender, ponerse a prueba, etc… y en semejante «chipi-chapa» esa sana actitud se torna casi locura.

    Pero hay de todo, hay quienes se centran en tecnologías muy concretas, hay hormiguitas que hacen bien y pasito a pasito las cosas, hay especialistas del malabarismo y, claro, están los que hacen castillos de naipes…

    En todo caso, es un terreno complicado en el que lo que «menos» importa son las tecnologías y más la puesta en práctica, pero es algo que el bosque no nos deja ver y por eso andamos todos por las ramas… XD

  3. Me encanto el título del post, gracioso y representativo de la realidad por partes iguales. A mí también me gusta llamarlo “arquitectura guiada por el CV”.

    Yo creo que hay un problema de autoestima, muchos que tienen que tomar decisiones importantes y que no tienen la experiencia suficiente y entonces se vuelven en los mayores fundamentalistas de alguna de las teorías que existen para poder “mirar a los ojos a sus colegas” pero perdiendo totalmente el norte con respecto al objetivo que es desarrollar software para solucionar un problema (como lo dice el post).

  4. Complicarse la vida parece cosa de la naturaleza humana :). Yo desde hace muchos años lo tengo claro, las palabras, y los «pogüerpoin», blogs y demás zarandajas se las lleva el viento; A mí me enseñas el código y, dado que trabajo en rendimiento, los números, si no pues tu opinión es muy bonita pero yo tengo la mía y no me la he inventado.
    Así se aprende más, se pierde menos tiempo y se callan muchas bocas. A mí si me enseñan el código que es mejor y me lo demuestran, encantado de aprender, pero a mi un «lo he leido en un blog», «lo hace todo el mundo», «lo ha dicho el gurú X» me dan la risa floja.
    Y sigo opinando lo mismo que hace años (disclaimer: enlace a mi superdesactualizado blog): el problema es no tener claras las prioridades.
    También es cierto que de pequeño me cai en la marmita de pragmatismo y cinismo y así me quedé. :X

  5. José Aguirre dijo:

    Estoy totalmente de acuerdo con lo que dices, yo eh pasado por lenguajes e incluso frameworks que no me satisfacían mi ego y nunca me enfoque a la solución viable del problema, soy un programador medio y te puedo decir que eh pasado por Python/Django, Ruby/Rails y al final me opte por ser full stack en javascript usando Node/Express con un puño de librerías que ni conozco al 100% e incluso el lenguaje.

    Y me eh puesto a pensar que yo mismo me pongo el reto de querer ser mas «mainstream» o «hardcore» al desarrollar y termino sin desarrollar nada, y esto al final me llevo muchas veces a la parálisis por análisis.

    El único consejo que puedo dar es que no sean como yo y siempre resuelvan el problema con lo primero que tengan a la mano sin pensar tanto, ya que al final todo software itera y evoluciona.

Comentarios cerrados.