Hacer cosas pensando en el futuro… ¿o no?

Hace años, en una aplicación corporativa que ya llevaba una década existiendo y que todavía sigue coleando, propuse encapsular las peticiones asíncronas con una etiqueta JSP. La idea era buena: si algún día cambiaban las tecnologías (como había pasado de applets a iframes, luego AJAX), bastaría con tocar esa etiqueta y todo seguiría funcionando como si nada.

Pero la realidad fue más puñetera que mi previsión. Aquello que parecía elegante y mantenible… sigue coleando. El código sigue vivo, pero no siempre por las razones que uno querría 🤷.

Es una situación que me he encontrado en bastantes personas, todas con muy buenas intenciones como yo.

¿Cuándo dejarlo preparado y cuándo no?

Lo reconozco: de joven pecaba de exceso de previsión. Pensaba que dejarlo “preparado para el futuro” era sinónimo de profesionalidad. Pero hay un matiz clave: si no tienes claro lo que va a pasar, prepararte para “todo” es una trampa.

¿Qué aprendí?

  1. El código que no necesitas hoy, te estorbará mañana.
  2. Mañana sabrás más que hoy. Espera. Aprende. Mejora.
  3. La agilidad no es solo Scrum. También es diseño limpio, desacoplado y con margen para evolucionar.

La trampa del “por si acaso”

Desde el manifiesto de extreme programming hasta el puro sentido común que te da la experiencia, todo apunta a lo mismo: optimiza para el cambio, no para la adivinación.

Hoy día no puedes prever ni si tendrás equipo, ni si usarás la misma nube, ni siquiera si tu sector seguirá igual. Si alguien en 2019 hubiese escrito código pensando en que su sistema funcionase bien en el futuro, seguramente habría perdido el tiempo, por la irrupción de los LLMs. Porque nadie los vio venir. Ni los propios investigadores.

¿Y entonces qué hacemos?

Simplifica y déjate todas las puertas abierta que puedas sin incurrir en mucho coste. Deja margen. Y confía en tu yo del futuro: tendrá más experiencia, más información y —si todo va bien— menos ego.

Moraleja

Diseñar con flexibilidad no es renunciar a la calidad. Es reconocer que la calidad técnica incluye la adaptabilidad. No hagas predicciones: diseña para poder decidir con calma cuando llegue el momento.


Si quieres leer más sobre que hacer con el pasado, mira este artículo sobre aplicaciones heredadas. Y si puedes predecir el futuro, mejor lo usas para predecir el numero del euromillones 😉

¿Tú también tienes historias de código que envejece mal? Cuéntamelo en LinkedIn y seguimos la conversación 😉

Diseñado en la cabeza de Iñigo, made in ChatGPT no es bola de cristal es presente.