Elegir una tecnología que sobreviva a su autor

La elección tecnológica de una aplicación de negocio es una decisión de mantenimiento disfrazada de decisión técnica. El código se escribirá una vez y se mantendrá una década.

Los criterios que de verdad predicen el coste

¿Puede contratar para ello? Busque en su mercado local y en el remoto. Si una tecnología devuelve un puñado de candidatos, cualquier cambio futuro dependerá de encontrar a uno de ellos.

¿Es aburrida? Aburrida significa bien entendida, ampliamente desplegada, exhaustivamente documentada y con sus modos de fallo conocidos. Aburrida es un cumplido.

¿Quién la mantiene? Una fundación o una gran empresa con política de soporte es algo muy distinto de un entusiasta. Revise el histórico de versiones y si los parches de seguridad llegan pronto.

¿Cuál es la ventana de soporte? Todo framework tiene una fecha de fin de vida por versión. Esa fecha es cuando su actualización pasa a ser obligatoria, y debería estar en su plan antes de empezar.

¿Qué tamaño tiene el árbol de dependencias? Cada paquete es algo que actualizar y algo que podría traer una vulnerabilidad. Menos dependencias, mejor elegidas, envejecen mucho mejor.

La trampa de la opción emocionante

Los frameworks nuevos son genuinamente agradables y a menudo técnicamente superiores. También son donde una tecnología va a quedar abandonada. Una herramienta con comunidad pequeña y un mantenedor puede ser excelente hoy y estar sin mantener en tres años, momento en que su aplicación funcional se convierte en una reescritura.

Para software de gestión interno, elija la opción con la comunidad más grande que cumpla el requisito. Reserve la novedad para lo que pueda permitirse tirar.

Valores por defecto razonables

• Un lenguaje mayoritario con versiones de soporte extendido
• Un framework de uso comercial amplio, no solo de discusión amplia
• Una base de datos relacional, salvo razón concreta en contra
• Un despliegue que un ingeniero competente pueda entender solo con la documentación
• Tantas piezas móviles como el problema realmente exija, y ni una más

Escriba la decisión

Una página: qué se eligió, qué se descartó y por qué. Cuando dentro de cuatro años alguien pregunte por qué el sistema está construido así, esa página evita una reescritura cara argumentada desde el desconocimiento.

Tomamos estas decisiones de forma deliberada en los proyectos de desarrollo de software.