Se acerca el fin de año, y es momento de listas, ya están por todas partes. Los 30 mejores discos de jazz de 2023, las mejores películas del año, los mejores libros…

Es una época que me encanta. Me gusta revisar listas de discos y libros, me sirve para darme cuenta de todos los discos, películas y libros que tengo que añadir a mi, ya de por sí abultada, lista de “pendientes”.

En paralelo es un buen momento para encontrarse con miles de artículos que tratan de elucidar lo que se nos viene encima en el futuro año que estamos a punto de estrenar. Seguro que ya has visto alguno del estilo de “los 20 frameworks de Javascript que usaremos en 2024” o “las 200 herramientas de IA que tienes que conocer en 2024”. Aquí es donde empieza mi reflexión de hoy.

---

Somos animales, y como animales nos llama la atención todo lo que brilla y se mueve, como a las urracas nos gusta coleccionar pequeños objetos brillantes y esto nos afecta a todos los niveles, incluso cuando se trata de elegir las herramientas para llevar a cabo el trabajo que nos ocupa en esta newsletter, el desarrollo de software para solucionar problemas y aportar valor.

Cuando nos planteamos iniciar un nuevo proyecto, tenemos que tomar muchas decisiones, algunas de mayor calado y otras de menor, pero sin duda una de las que generan más discusiones y más apasionamientos es la elección de las herramientas.

El mundo del desarrollo de software se mueve a gran velocidad, y es frecuente que cada mes, cuando no cada semana, tengamos a nuestra disposición nuevas versiones de las herramientas que utilizamos, que se nos presenten nuevos paradigmas, nuevos frameworks, o incluso categorías completamente nuevas de productos, servicios o herramientas que podemos utilizar en nuestro trabajo para construir nuevos sistemas o añadir nuevas funcionalidades a los que ya mantenemos. 

Cada nueva herramienta promete ser mejor que la anterior y todas parecen llamadas a alterar para siempre el ecosistema en el que nos movemos.

La realidad es que tras los cantos de sirena, la mayor parte de estos cambios terminan por no tener un impacto real tan interesante ni tan profundo como el prometido.

Es fácil dejarse llevar por el miedo a quedarse atrás.

Pero es más importante centrarse en los básicos.

Al final no es tan importante que framework usas ni si es muy moderno o no tanto si las prácticas base no están presentes.

Una organización cuyo objetivo es desarrollar software es un sistema complejo y como tal dispone de ciertas limitaciones físicas, ciertos recursos limitados. El éxito a la hora de conseguir nuestro objetivo depende de cómo organicemos el consumo de esos recursos limitados, si empleamos una parte considerable de nuestra energía en aprender un framework nuevo, a la fuerza vamos a tener menos energía para preocuparnos del diseño del sistema o de tener buenas estrategias de testing, si creamos nuevas fuentes de complejidad al cambiar el modelo de despliegue, o la arquitectura tenemos que entender que a la fuerza estamos restando recursos en otras áreas. En ciertas ocasiones será necesario invertir parte de nuestros recursos en investigar nuevas herramientas y técnicas, pero es clave encontrar el equilibrio justo, ya que nuestro objetivo, como equipos de desarrollo y de producto, casi nunca es probar nuevas técnicas o utilizar el último objeto brillante que la industria ha traído a nuestra puerta. No, nuestro objetivo es crear productos y servicios que solucionen los problemas y necesidades de nuestros clientes finales.

Mi consejo es nunca apartar los ojos del objetivo final, ¿cuál es el problema que tenemos que resolver? Una vez aclarado esto podemos plantearnos la siguiente pregunta ¿las técnicas y herramientas que usamos nos permiten hacerlo? Si la respuesta es no, tiene sentido plantearse cambios y procesos de investigación, en caso contrario, creo que es mejor invertir los recursos limitados de los que dispone nuestro equipo (energía, capacidad de concentración, experiencia) en trabajar los pilares básicos de un proyecto exitoso, buen diseño, buenas prácticas, testing, metodología, validación de que lo que estamos haciendo es lo que tenemos que hacer, etc.

Es más importante hacer las cosas bien, programar limpio, testear con calidad y hacer que tu equipo realmente esté alineado con las necesidades del negocio y que cada miembro implicado en el proceso entienda el objetivo final de proyecto y el problema que pretende solucionar.

Por supuesto hay que utilizar las herramientas adecuadas para el proyecto en curso y hay que eliminar de nuestra caja de herramientas aquellas que se han quedado anticuadas, que ya no funcionan o que pertenecen a un paradigma que ya no nos sirve. Pero cuidado con elegir las herramientas en base al FOMO (fear of missing out), las estrategias de marketing de los distintos proveedores y las ganas que todos tenemos de probar el último objeto brillante que el sector pone ante nuestros ojos.

---

Principios

Para elegir las herramientas correctas creo que podemos basarnos en los siguientes principios.

Elegir la herramienta adecuada para la fase en que está el proyecto

Elegir bien la herramienta para la fase en la que se encuentra el proyecto es de vital importancia, ciertas herramientas, frameworks y lenguajes nos ayudan a ir más rápido a cambio de perder ciertas ventajas a corto plazo y otras al revés, nos complican el inicio a cambio de ventajas futuras.

Debemos ser capaces de detenernos un momento y pensar que es lo que más sentido tiene para la fase en la que estamos, no es lo mismo plantear un nuevo proyecto dentro de un ecosistema enterprise bien establecido y maduro que crear un MVP para probar una idea de negocio en una startup naciente. 

Esto aplica también a decisiones de arquitectura.

Elegir con el mercado laboral en mente

Da igual que cierta nueva tecnología sea el último grito en Silicon Valley si tú montas tu proyecto con ella y luego no puedes contratar a nadie que la domine.

Es necesario conocer las nuevas tendencias, pero al final del día necesitas ser capaz de contratar y mantener equipos expertos en las herramientas que usas.

De nada sirve saber con certeza que estas usando el mejor y más eficiente lenguaje de programación funcional o la ultimísima base de datos orientada a grafos si luego no puedes contratar gente que esté preparada para trabajar con esas herramientas. Obviamente siempre cabe la posibilidad de contratar gente capacitada para aprender y especializarse en esas herramientas, pero tienes que tener muy claro que tus recursos te permiten esa inversión (y no siempre es así).

Elegir herramientas battle-tested

Entre un framework recién salido al mercado y una herramienta curtida en miles de proyectos y con casos claros de éxito (y porqué no, también de fracasos) elige siempre la segunda.

Todas las nuevas herramientas vienen con la maleta llena de promesas y de nuevas maneras de ver los problemas y todas prometen resolver los problemas de siempre para siempre. La realidad es que casi nunca es cierto, no reinventemos la rueda. 

Elige herramientas probadas sin dejar de tener un ojo en lo nuevo que va saliendo para ver qué nuevas ideas traccionan y cuáles se quedan en nada tras algo de tiempo. No cometas el error de empezar un proyecto a largo plazo con algo que acaba de salir y de lo que todavía no se han descubierto los problemas y carencias.

Documentación y comunidad

Muy en línea con el punto anterior, si estás trabajando con una herramienta o técnica necesitas tener acceso a documentación de calidad, a una comunidad sólida y a casos de error y preguntas y respuestas sobre los problemas, dudas y bloqueos que te van a ir surgiendo por el camino. Antes de tomar ninguna decisión crítica que pueda afectar al proyecto valora la existencia de este tipo de recursos. Aquí una vez más se refuerza la idea de que usar herramientas probadas por el paso del tiempo te va a facilitar las cosas a medio plazo.

Soporte a largo plazo

De igual modo debes valorar el soporte a largo plazo que cada pieza de tu sistema va a recibir.

¿Quién está detrás del proyecto? ¿Cuáles son las posibilidades de que el proyecto siga con buena salud tras 2, 5 ó 10 años? ¿Cada cuanto se actualiza?

Tener en cuenta este punto puede ser de gran importancia cuando trabajamos en proyectos con posibilidades de prolongarse en el tiempo, que al fin y al cabo es lo que todos los proyectos deberían buscar, ya que es señal de que estamos trabajando en algo que realmente aporta valor.

En definitiva, robustez y simplicidad por encima del hype.