Hay una brecha extraña en el software latinoamericano, y también en el del resto del mundo. En un extremo están las empresas suficientemente grandes para convertir la práctica de ingeniería en infraestructura: Mercado Libre, Rappi, Globant en sus años de mayor escala, y sus pares globales, pueden costear equipos de plataforma dedicados, herramientas internas, comités de arquitectura y años de memoria institucional acumulada. En el otro extremo están las empresas de garaje y los pequeños negocios que no pretenden tener un ciclo de vida de desarrollo de software — despliegan desde una laptop porque el producto es una sola persona, el cliente está esperando, y la alternativa no es un proceso más riguroso sino ningún producto. Entre esos dos polos hay miles de empresas con suficiente software como para necesitar disciplina de ingeniería y sin el margen, la atención o el respiro organizacional para hacer de esa disciplina una prioridad de primer orden. Ese medio es donde efectivamente se escribe la mayoría del software, y es la parte de la industria de la que la propia literatura de la industria menos tiene que decir.

I. No es una falla de conocimiento

El medio ausente no es un medio ignorante. Las prácticas tienen nombre — SDLC, diseño guiado por dominio, integración continua, observabilidad, modelado de amenazas, pruebas automatizadas, respuesta a incidentes, documentación, revisión de código. Los libros existen. Los consultores pueden explicar el modelo de madurez en una sala de juntas, y los ingenieros pueden describir de memoria las consecuencias de saltarse cada paso, porque la mayoría las vivió en carne propia. El problema nunca fue la ignorancia. El proceso llega a estas organizaciones como una preocupación de segundo orden, subordinada a lo que el mercado esté castigando ese trimestre.

Esa distinción importa. Decir que una empresa “no tiene cultura de ingeniería” hace que la falla suene a negligencia. Muchas veces es más parecido a un triage. Ventas necesita una funcionalidad antes de que la lance un competidor. Un cliente encontró un bug en producción y amenaza con irse. La junta quiere evidencia de crecimiento para el viernes. Una migración ya se atrasó dos veces. Bajo esas condiciones el proceso no se rechaza por filosofía — se posterga, y la postergación se repite hasta que la excepción se convierte en el modelo operativo. Ward Cunningham acuñó “deuda técnica” en OOPSLA en 1992 como metáfora, no como acusación: un préstamo que se toma deliberadamente, con la expectativa de pagarlo. Lo que la metáfora omite es que en el medio ausente nadie agenda nunca el pago. Siempre hay un préstamo más urgente que tomar primero.

II. La ventaja de escala de las grandes tecnológicas

En la cima del mercado, el proceso se convierte en un activo competitivo porque la escala crea espacio para pagarlo. Una empresa que atiende a cientos de millones de usuarios puede justificar un equipo entero cuyo trabajo es hacer que otros equipos sean más rápidos y más seguros. Puede absorber una reescritura de plataforma, mantener un catálogo de servicios, exigir revisiones de diseño y tratar la confiabilidad como una funcionalidad del producto, porque una caída tiene un precio global medible. La maquinaria interna de Amazon — el memo narrativo de seis páginas que reemplaza al PowerPoint, el comunicado de prensa “working backwards” escrito antes de la primera línea de código, el equipo “de dos pizzas” como unidad organizacional — está documentada con suficiente detalle, notablemente en Working Backwards de dos de sus exejecutivos, que se lee menos como cultura y más como infraestructura con una línea de nómina.

Esto no es virtud superior. Es una economía de escala. El proceso de ingeniería tiene un costo fijo: alguien tiene que definirlo, enseñarlo, automatizarlo, medirlo y defenderlo del próximo pedido urgente. Distribuido entre suficiente ingreso y suficientes equipos, esa inversión empieza a parecer obvia. Fred Brooks, describiendo qué es lo que realmente devora el cronograma de un proyecto grande de software en El mítico hombre-mes, argumentó que la sobrecarga de comunicación crece más rápido que la cantidad de gente — y las grandes tecnológicas respondieron no manteniéndose pequeñas, sino industrializando esa sobrecarga, diseñando el organigrama a la medida del software, exactamente al revés de la ley de Conway, que observa que los sistemas terminan con la forma de las organizaciones que los construyen. A esa escala uno puede darse el lujo de diseñar la organización a propósito.

III. La ventaja del fundador

Las empresas más pequeñas escapan a las mismas expectativas por la razón opuesta. Un fundador puede tener todo el sistema en la cabeza. La persona que habla con el cliente es la misma que cambia el código, despliega el servicio y nota cuando algo se rompe. Puede no haber un SDLC formal, pero el ciclo de retroalimentación es corto y el modelo de dominio se transmite socialmente en vez de por escrito. Ese arreglo falla apenas el sistema o el equipo crecen, pero antes de ese punto, la ceremonia que se ahorra puede valer más que el riesgo futuro que se posterga.

La empresa de garaje no es necesariamente inmadura por trabajar así. Puede estar haciendo un intercambio racional — velocidad y supervivencia ahora a cambio de mantenibilidad después. El problema empieza cuando la empresa conserva el modelo operativo de startup después de haber adquirido la complejidad de una institución más grande. Un equipo de doce ya no puede compartir cada supuesto. Un producto con varias integraciones ya no se puede entender de memoria con seguridad. La organización cruzó el umbral donde la coordinación informal deja de escalar, pero el mercado todavía no le concedió el presupuesto para construir una alternativa formal.

IV. El impuesto de las prioridades

Aquí es donde el medio queda atrapado. Cada práctica de ingeniería compite con una prioridad de negocio visible. Las pruebas no parecen ingreso. El refactor no aparece en la demo. La documentación no produce ninguna captura de pantalla para la junta. El modelado de dominio es más difícil de defender justo cuando el dominio cambia más rápido. La organización puede ver el costo de posponer una funcionalidad hoy y solo puede estimar el costo de debilitar el sistema mañana — y las estimaciones pierden contra las partidas presupuestarias en cada reunión de presupuesto que se haya hecho.

Entonces la empresa recorta camino, lanza primero, y promete exigir el proceso después. A veces esa es la decisión correcta — el software no es un puente, y no todo lanzamiento merece la misma ceremonia. Pero el “después” tiene la costumbre de llegar pegado a otro plazo. La excepción temporal se vuelve precedente, el precedente se vuelve expectativa, y eventualmente al equipo se le dice que el proceso está fallando cuando nunca se le permitió formar parte de la definición de terminado del producto. El resultado no es caos en el sentido dramático. Es un lento impuesto de prioridades: cada atajo hace que el próximo cambio sea un poco más caro, cada supuesto no documentado hace que una persona sea más imprescindible, y cada emergencia deja a la organización menos capaz de invertir en las condiciones que evitarían la próxima. La empresa se mantiene funcional, y por eso mismo el impuesto es tan difícil de ver. Se paga en opciones perdidas, no en fallas visibles.

V. Qué significaría en verdad ser de primera clase

Convertir el proceso de ingeniería en una prioridad de primera clase no puede significar importar los rituales de Amazon a una empresa de veinte ingenieros — eso confunde la forma visible de la escala con la razón de la práctica. La pregunta es más pequeña y más exigente: ¿cuáles son los hábitos mínimos que preservan la capacidad de la organización de entender, cambiar y recuperar su propio sistema a medida que crece? Una prueba alrededor de una regla crítica para el ingreso puede importar más que una meta de cobertura del cien por ciento. Un vocabulario de dominio compartido, el tipo de cosa que Eric Evans llamó lenguaje ubicuo, puede importar más que una arquitectura de moda. Un despliegue que se puede revertir en cinco minutos puede importar más que un tren de lanzamientos elaborado que nadie tiene tiempo de operar.

El medio ausente no necesita proceso máximo. Necesita proceso explícito — un acuerdo deliberado sobre qué riesgos acepta la empresa, qué decisiones deben quedar registradas, y qué atajos vencen en vez de volverse permanentes. Lo difícil nunca fue elegir las herramientas. Es darle a alguien suficiente autoridad y tiempo para defender el futuro frente al presente, sin fingir que el presente es irracional por pedir sobrevivir.

Lecturas recomendadas