La tecnología cambia a diario, ¿debería tu negocio intentar seguir el ritmo?

La verdad es que no. A menos que el negocio impulse esa necesidad de cambio.

Es un error que muchos (yo incluido) cometemos. Sale una nueva tecnología y nuestro software hay que reescribirlo usándola. Pero ¿qué ventaja le aporta eso a nuestro negocio y a nuestros usuarios finales? En la mayoría de los casos, ninguna.

En lugar de pasar el tiempo cambiando a tecnologías más nuevas o actualizando y volviendo a probar tras cada release menor de tus 250 dependencias, ese tiempo podría dedicarse a desarrollar y entregar nuevas funcionalidades para tus usuarios finales. En serio, a nadie le importa que estés ejecutando la última versión de Angular si te faltan funcionalidades que sí tienen tus competidores.

Vale, podrías decir, pero ¿qué pasa dentro de 3 años cuando sea necesario actualizar, vayas 10 versiones mayores por detrás y tengas toneladas de código “legacy”?

Primero, siéntete orgulloso de lo que has logrado. El hecho de que hayas priorizado correctamente tus recursos significa que tu negocio ahora impulsa el cambio y exige que actualices. Sin esa priorización, tu negocio quizá nunca habría despegado y seguirías trabajando a oscuras, actualizando entre versiones de Angular sin que nadie use realmente tu software.

Segundo, no intentes reescribir todo tu software. Esto es especialmente cierto con aplicaciones web. Al principio, reescribe solo los módulos para los que la actualización era necesaria. Continúa con los nuevos módulos o funcionalidades que vayas desarrollando y, conforme aparezcan cambios mayores en otros módulos, decide si vale la pena reescribir y, si es así, hazlo.

Si funciona, no lo arregles

Cada cambio que haces introduce riesgo y, por tanto, con cada actualización tendrás que volver a probar tu software. Como alternativa, puedes lanzarlo a la naturaleza y vigilar los incendios; eso también funciona, hasta cierto punto, y realmente depende de la situación. Podrías hacerlo con tu propio producto, ya que si algo pasa y acabas perdiendo dinero, es tu culpa, tu dinero. Pero ¿qué pasa cuando haces este cambio para un cliente, pensando que haces bien, pero el cliente no lo ha pedido y no te molestaste en avisarle, y acabas introduciendo un bug que a su vez le hace perder dinero? Exacto. Asumiste un riesgo por algo que tu cliente no puede cuantificar y te explotó en la cara.

Justificar el cambio

El cambio se puede justificar. Solo asegúrate de no mentirte a ti mismo (o a tu cliente, si trabajas para alguien) por amor al juguete nuevo. Los juguetes van y vienen; se rompen, se tiran y compras juguetes nuevos. Piensa en términos de herramientas, piensa en productividad, rendimiento, seguridad. “Reducir riesgo” es demasiado genérico. Ten argumentos y cifras reales para respaldar una decisión así.