Cuándo elegir Elm de verdad: los perfiles donde la apuesta sale bien

Toda decisión de tecnología es una apuesta sobre el futuro, y lo que distingue una apuesta razonada de una corazonada es haber escrito antes qué tendría que ser cierto para que salga bien. Con Elm esa escritura es especialmente útil porque su perfil de coste es inusual: cobra por adelantado y paga a plazos. La curva de adopción es empinada las primeras semanas, la integración con lo existente exige diseño en lugar de importaciones, y hay piezas que habrá que envolver o escribir. Todo eso ocurre en los primeros meses, donde es visible y duele. El retorno llega después, en forma de una cosa que no se ve porque consiste en ausencias: incidentes que no ocurren, refactorizaciones que no dan miedo, entregas que no requieren una ronda de comprobación manual, código de hace tres años que se lee sin arqueología. Un perfil de coste así solo tiene sentido si el proyecto vive lo suficiente para cobrar el retorno, y por eso la pregunta de si Elm es bueno está mal formulada. La pregunta correcta es cuánto va a durar esto, cuánto cuesta que falle, cuánto de lo que hay que construir es dominio y quién será el dueño dentro de dos años.

Las cuatro variables

La primera es el horizonte. Un producto que vivirá seis meses no llega a cobrar nada de lo que Elm ofrece, porque todo su retorno está en el mantenimiento. Un producto que vivirá cinco años y será modificado continuamente por gente distinta está exactamente en el otro extremo. La pregunta no es cuánto se tarda en construirlo sino cuántas veces se cambiará después, y esa cifra suele conocerse mejor de lo que se admite: los productos internos de una organización, las herramientas de operaciones y los sistemas de administración viven casi siempre más de lo que su primera versión sugiere.

La segunda es el coste de un fallo. Hay interfaces donde un error de ejecución produce un usuario molesto que recarga la página, y hay interfaces donde produce una transacción incorrecta, un dato médico mal mostrado, una operación financiera con el signo cambiado o una pérdida de confianza que no se recupera. Cuanto más cara sea la cola de la distribución, más vale una garantía frente a una probabilidad muy buena, y esa es literalmente la diferencia que Elm ofrece frente a un sistema de tipos con escapes.

La tercera es la proporción entre lógica de dominio y superficie de integración. Un producto cuya dificultad está en reglas, estados, transiciones y validaciones aprovecha todo lo que el lenguaje sabe hacer. Un producto cuya dificultad está en orquestar diez servicios externos con sus propios widgets pasa la mayor parte del tiempo en la frontera, que es justamente donde Elm cobra más caro. La proporción se puede estimar contando, en el mapa de pantallas, cuántas resuelven reglas propias y cuántas presentan o envuelven algo ajeno.

La cuarta es la estabilidad de la propiedad. Un equipo que mantiene lo que construye internaliza el retorno; un equipo que entrega y desaparece lo externaliza y solo ve el coste. Este factor explica buena parte de por qué la misma decisión técnica se juzga excelente en una empresa de producto y desastrosa en una consultoría por proyecto, sin que ninguna de las dos se equivoque.

Las cuatro variables no se combinan por suma sino casi por producto, y esa distinción importa. Un proyecto con horizonte largo, coste de fallo alto y mucho dominio propio, pero sin propiedad estable, no es un caso favorable con una pega: es un caso desfavorable, porque quien pagaría el coste inicial no es quien cobraría el retorno y esa asimetría acaba imponiéndose sobre cualquier mérito técnico. Lo mismo ocurre cuando falla el horizonte: da igual lo bien que encajen las otras tres si el producto se apaga en nueve meses. La forma correcta de usar estas variables no es sumar puntos sino comprobar que ninguna está en cero, y solo entonces mirar la magnitud de las demás.

Los perfiles donde sale bien

El primero y más claro es el producto interno de larga vida con reglas duras: sistemas de administración, herramientas de operaciones, paneles de control, aplicaciones internas de seguros, banca, logística o salud. Tienen horizonte largo, coste de fallo alto, mucha lógica de dominio, poca dependencia de piezas visuales exóticas, y usuarios cautivos que no exigen el último efecto de moda. Es el perfil sobre el que descansan casi todos los casos de adopción documentados que han sobrevivido más de cinco años.

El segundo es el equipo pequeño con propiedad estable, entre dos y ocho personas, que construye y mantiene lo mismo durante años. Aquí el retorno se internaliza por completo y el riesgo de concentración de conocimiento se gestiona con formación en pares desde el primer día. La ausencia de decisiones triviales que el lenguaje impone vale más en un equipo pequeño que en uno grande, porque cada discusión evitada es una fracción mayor de su capacidad. Hay además un efecto que estos equipos describen con insistencia: la desaparición casi total del trabajo de comprobación manual antes de cada entrega, que en un equipo de cinco personas puede suponer un día entero por semana recuperado.

El tercero es el módulo crítico dentro de un sistema mayor. No hace falta convertir el producto entero: se aísla la parte donde un fallo cuesta caro —el editor de una póliza, el flujo de pago, la configuración de un dispositivo— y se construye ahí con el constructor de elemento, incrustado en la página que gestiona la tecnología existente. La frontera es explícita, la hipótesis se comprueba en meses y el coste de revertir es acotado.

El cuarto perfil es menos evidente y aparece con frecuencia en dominios regulados: el producto cuyas reglas están escritas en otro sitio y no las decide el equipo. Cálculo de primas, liquidaciones, elegibilidad de prestaciones, configuraciones de producto con restricciones combinatorias, protocolos clínicos. Lo que caracteriza a estos casos es que las reglas son numerosas, cambian por decisión externa y hay que poder demostrar que el programa las implementa todas. Un sistema de tipos que obliga a enumerar variantes y a tratar cada una convierte un cambio normativo en una lista finita de errores de compilación, y esa lista es a la vez el plan de trabajo y la evidencia de que no queda nada suelto. Pocas cosas encajan tan bien con la disciplina del lenguaje como un dominio en el que alguien de fuera decide las reglas y alguien de dentro responde de haberlas aplicado.

-- Adopcion por frontera: el modulo critico vive dentro de la pagina existente
main : Program Configuracion Model Msg
main =
    Browser.element
        { init = init
        , update = update
        , subscriptions = subscriptions
        , view = view
        }

-- Fuera queda todo lo demas. La frontera es el contrato de banderas y ports,
-- y su tamano es exactamente lo que hay que revisar en la decision.

Conviene subrayar una cosa sobre este tercer perfil, porque es el que convierte la discusión en algo comprobable. Una adopción por frontera transforma una decisión de fe en un experimento con resultado observable: se fija de antemano qué habría que ver a los seis meses para considerar que la hipótesis se sostiene —número de incidentes en ese módulo frente a los equivalentes, tiempo de incorporación de la última persona que lo tocó, coste de los tres últimos cambios de dominio— y se mira. Casi nadie lo hace, y por eso casi todas las adopciones se juzgan por impresiones. Una hipótesis escrita antes de empezar es la diferencia entre haber aprendido algo y haber discutido durante seis meses.

Los perfiles donde no sale, dicho a tiempo

-- El perfil regulado: la norma cambia y el compilador escribe el plan de trabajo
type Cobertura
    = Basica
    | Ampliada { franquicia : Centimos }
    | Total { franquicia : Centimos, asistencia : Asistencia }
    | Reducida { limite : Centimos }   -- la norma introduce esta

-- Ningun calculo, ninguna pantalla y ningun informe compila
-- hasta que alguien decida que hacer con la variante nueva.
-- La lista de errores es la lista de cosas por revisar, y esta completa.

Hay cuatro situaciones donde recomendar Elm es un error, y decirlo pronto vale más que cualquier defensa entusiasta. La primera es el prototipo desechable o el producto de validación rápida: todo el coste está por delante y no hay ningún plazo para cobrar el retorno. La segunda es el producto cuyo núcleo funcional es una pieza de la categoría bloqueante, ya sea un editor enriquecido, un lienzo con manipulación directa o el widget de un proveedor; en ese caso la aplicación se convierte en un anfitrión de código ajeno y hereda toda su complejidad sin ninguna de sus ventajas. La tercera es la organización con rotación alta y sin propiedad estable, donde el conocimiento se concentra y se pierde antes de difundirse. La cuarta, la más importante y la que menos se dice, es aquella en la que la decisión de tecnología no la toma quien la va a mantener: una adopción impuesta desde fuera fracasa aunque sea técnicamente correcta, porque el coste inicial se paga con voluntad y nadie pone voluntad en una decisión que no tomó.

Conviene añadir una quinta situación que no es de proyecto sino de momento, y que arruina adopciones técnicamente impecables: hacerla coincidir con una entrega comprometida. El coste inicial de Elm se paga en semanas donde el equipo produce menos de lo habitual, y si esas semanas caen dentro de un plazo cerrado, la adopción se juzgará por la única métrica que estará mirando todo el mundo. La consecuencia no es que la decisión se revierta, que sería sano, sino algo peor: se abandona a medias, quedando un módulo en la tecnología nueva que nadie termina y que se cita durante años como prueba de que aquello no funcionó. Adoptar es también elegir cuándo, y el momento correcto es aquel en que el equipo puede permitirse ser lento sin que nadie lo interprete.

flowchart TD
A[Evaluo adoptar Elm] --> B{Horizonte de anios}
B -->|No| N[No compensa]
B -->|Si| C{Cuesta caro un fallo}
C -->|No| M[Dudoso, mide otra vez]
C -->|Si| D{Predomina el dominio}
D -->|No| N
D -->|Si| E{Quien construye mantiene}
E -->|No| M
E -->|Si| F[Empieza por un modulo critico]
F --> G[Comprueba la hipotesis en meses]
style F fill:#a6e3a1,color:#11111b
style N fill:#f38ba8,color:#11111b
style M fill:#f9e2af,color:#11111b