Hay una forma fiable de reconocer el software construido para impresionar a quien lo construye en lugar de servir a quien lo posee: cuente las tecnologías. El sistema con cuatro bases de datos, dos sistemas de colas y un framework publicado la primavera pasada no se diseñó - se coleccionó. Y el coleccionista rara vez paga la factura del mantenimiento.
El coste real de la tecnología emocionante
La tecnología nueva se cobra tres veces. Primero, en las incógnitas que ni siquiera sabe que existen: los modos de fallo sobre los que todavía nadie ha escrito, descubiertos a las dos de la madrugada en su sistema de producción. Segundo, en contratación: cada elección exótica reduce el número de personas capaces de mantener el sistema y sube su precio. Tercero, en longevidad: el framework emocionante de este año tiene las mismas probabilidades de estar abandonado dentro de cinco años que de seguir vivo - las herramientas probadas ya han sobrevivido a sus extinciones.
Los tres costes se refuerzan entre sí. La base de datos exótica falla de una forma no documentada, lo cual sería llevadero - salvo que el único ingeniero que la entendía se marchó en primavera y la búsqueda de sustituto va por el cuarto mes, porque el número de candidatos con esa habilidad concreta es un error de redondeo. Mientras tanto, el framework del que depende ha anunciado su «nueva y prometedora dirección», que en lenguaje de proveedor significa reescribir todo lo que usted construyó sobre la versión anterior. Ninguno de estos era un riesgo aparte; era un solo riesgo, comprado tres veces.
Estos costes llegan cuando la agencia ya se ha ido. Precisamente por eso las agencias tienen una tentación estructural por la tecnología emocionante - el beneficio para el currículum es suyo, la factura del mantenimiento es de usted. Alinear esos incentivos es tanto un problema de diseño de contrato como de ingeniería: es parte de por qué damos garantía sobre nuestro trabajo y ofrecemos operar lo que construimos.
Cómo se forma la colección
Nadie se propone construir un sistema imposible de mantener; se acumula mediante decisiones defendibles una a una. Un ingeniero quiere una tecnología en su currículum, y el proyecto es el único sitio donde conseguirla. Una charla de conferencia hace que una arquitectura pensada para una empresa con mil ingenieros parezca la buena práctica de un equipo de seis. Un diagrama de microservicios parece más profesional que un monolito honesto. Cada elección añade una pieza móvil, y las piezas móviles se multiplican: dos bases de datos no cuestan el doble que una - cuestan la segunda base de datos más la sincronización entre ambas, para siempre.
La defensa es una regla aburrida aplicada en el momento de la revisión: toda tecnología que se salga del stack por defecto tiene que ganarse la entrada con un requisito medible que el stack por defecto no pueda cubrir. «Escala mejor» no cuenta sin un número. «Puede que lo necesitemos más adelante» es una razón para añadirlo más adelante. La carga de la prueba recae sobre la novedad, nunca sobre la opción aburrida - porque solo una de las dos tiene un historial que enseñar.
La innovación es un presupuesto. Gástelo en su producto, donde los clientes pueden verlo - no en su infraestructura, donde solo lo ven sus ingenieros.
Aburrido ≠ antiguo
Aburrido no significa heredado. PostgreSQL, TypeScript, React, los servicios de nube mayoritarios - son modernos, tienen desarrollo activo y son extremadamente capaces. Lo que los hace aburridos es que sus aristas están documentadas, sus modos de fallo se conocen y un millón de equipos ya se han topado con los problemas con los que usted está a punto de toparse. Aburrido significa predecible, y la previsibilidad es lo que compra cuando paga tarifas senior.
Aquí se esconde una señal de contratación que los propietarios leen mal de forma sistemática. Los ingenieros junior persiguen stacks interesantes; los ingenieros senior persiguen problemas interesantes y eligen herramientas soporíferas a propósito, porque han pagado en persona la factura de las dos de la madrugada. Un equipo que le vende una arquitectura aburrida no está siendo poco ambicioso - le está enseñando sus cicatrices. La ambición pertenece a lo que el sistema hace, no a aquello de lo que está hecho.
La disciplina tiene un corolario: cuando sí gastamos el presupuesto de innovación - como en los sistemas de IA, donde la frontera se mueve de verdad cada trimestre - aislamos la parte emocionante detrás de interfaces aburridas, la mantenemos intercambiable y la envolvemos en evaluación. El radio de impacto de la novedad debe ser un módulo, nunca una arquitectura.
En la práctica, eso significa que el proveedor del modelo queda detrás de una interfaz que el resto del sistema desconoce, así que cambiarlo es un cambio de configuración, no una migración. Significa un marco de evaluación que puntúa cada modelo candidato sobre sus casos reales, de modo que la decisión de cambiar es una medición y no una cuestión de moda. La parte emocionante sigue siendo emocionante - sencillamente, no se le permite volver interesante al resto del sistema.
El stack por defecto, y cómo cambiarlo
La herramienta práctica detrás de todo esto es un stack por defecto puesto por escrito: la lista corta de tecnologías que usa un sistema nuevo salvo que alguien demuestre lo contrario. Una base de datos principal. Un lenguaje de backend que lea todo el equipo. Un framework de frontend. Servicios gestionados en la nube antes que cualquier cosa autoalojada - la opción aburrida en operaciones es pagar al proveedor de nube para que lleve la guardia. La lista cabe en una ficha, y de eso se trata: cada añadido debería parecer caro, porque lo es.
Cambiar el valor por defecto está permitido - por la puerta principal. Un argumento breve por escrito: el requisito que el valor por defecto actual no puede cubrir, el número que lo demuestra, el camino de migración de entrada y el de salida. Después, una prueba en algo no crítico antes de que nada de cara al cliente dependa de ello. Los equipos que siguen este ritual adoptan quizá una tecnología nueva al año, de forma deliberada, y se queda. Los que no, adoptan cinco por accidente y conservan dos - las otras tres siguen igualmente en producción, medio migradas, cobrando alquiler para siempre.
Preguntas para su próximo proveedor
¿Quién va a mantener esto en el tercer año, y cuánto costará? ¿Cómo de grande es el mercado de contratación para este stack - y qué le pasa a nuestro calendario cuando abandonen uno de estos frameworks? ¿Por qué esta segunda base de datos, en números? ¿Qué aspecto tiene el manual de guardia, y podría seguirlo un ingeniero que no construyó el sistema? Si las respuestas son vaguedades, la arquitectura es un pasivo disfrazado de demo.
La tecnología aburrida es la forma de que el software siga siendo un activo en lugar de convertirse en un proyecto de ciencias con pantalla de acceso - es decir: es un lujo que su negocio puede permitirse precisamente porque no lo parece. Lo premium no está en las herramientas. Está en la contención.