Velocidad y Calidad

El bonito problema: optimizar para dos variables que normalmente se destruyen entre sí. Velocidad sin calidad es deuda técnica a 10x. Calidad sin velocidad es irrelevancia.

Un tema normal en mis pláticas con amigos es sobre cómo generar buenos equipos de ingeniería. A fin de cuentas, si trabajas en un buen equipo mejora nuestra calidad de vida, es un tema al que nos gusta dedicarle mucho tiempo — llegas el lunes con ganas de resolver problemas interesantes, no con miedo a apagar incendios. A veces hasta me toca mentorear amigos sobre cómo lograr esto. La plática suele empezar con dos preguntas que todos hemos hecho alguna vez: “¿Cómo entregamos features más rápido?” y “¿Cómo reducimos el número de bugs?”. Estas dos preguntas son el primer síntoma del bonito dilema que implica desarrollar software — cómo construir con velocidad sin sacrificar calidad.

Es un dilema tangible y doloroso. Piénsalo: llega feedback de un usuario importante el viernes a las 4pm. ¿Cuánto tiempo te toma implementarlo en tu producto? ¿Una hora? ¿Una semana? ¿Un mes? ¿nunca? O cuando notas un bug crítico a las 2am — ¿logras resolverlo suficientemente rápido para que tus usuarios no se molesten y cancelen su suscripción? La diferencia entre una hora y un día puede ser la diferencia entre un cliente feliz y uno perdido para siempre.

El problema es que hablar de “buena velocidad” y “calidad” muchas veces se siente como un debate filosófico sin fin. Para la gente de negocios, nunca será suficientemente rápido — siempre hay un competidor pisándonos los talones. Para la gente de ingeniería, nunca tendremos suficiente calidad — siempre hay deuda técnica que nos quita el sueño. Y mientras tanto, el producto está ahí, con usuarios reales que no les importan nuestras filosofías, solo quieren que les resuelva su problema.

LLMs como catalizador, no como solución

transformado radicalmente nuestra capacidad de generar código — Claude puede escribir en minutos lo que antes tomaba horas, Cursor puede completar componentes enteros con solo un prompt. Pero aquí está el plot twist crucial: nuestra capacidad de generar código se multiplicó por 10, mientras que nuestra capacidad de asegurar calidad no ha crecido al mismo ritmo. Es como si nos hubieran dado un Ferrari pero seguimos conduciendo en calles llenas de baches.

Como reflexioné en mi artículo sobre complejidad, el código nunca fue realmente el trabajo. El trabajo siempre fue, y sigue siendo, resolver problemas complejos de manera simple y mantenible. En mis años programando, nunca me pagaron por entregar líneas de código — siempre me pagaron por resolver problemas. El código era solo el vehículo. Hoy ese vehículo es 10 veces más rápido, pero el destino — entregar valor al usuario — sigue siendo el mismo.

Y aquí está el riesgo real: no es que los LLMs nos hagan obsoletos. El riesgo es que ahora podemos generar deuda técnica 10 veces más rápido, agregar features sin validar si sirven, y construir complejidad accidental a una escala sin precedentes. Por eso, dominar herramientas como Cursor y Claude Code es solo el principio. El verdadero desafío es entender qué significa entregar software con calidad en esta nueva era donde la velocidad de generación de código ya no es el cuello de botella.

Feedback loops: el arte de la mejora continua

Después de años observando equipos de alto rendimiento, hay un patrón que se repite: los mejores equipos no son necesariamente los que tienen los mejores programadores, sino los que han dominado el arte de crear feedback loops positivos. Es la diferencia entre caminar a ciegas y tener un GPS con actualizaciones en tiempo real.

En esta industria llevamos décadas tratando de resolver este problema. El Agile Manifesto surgió en 2001 como respuesta a las metodologías waterfall que tardaban meses en obtener feedback. Desde entonces han aparecido Scrum, Kanban, SAFe, y docenas de frameworks más, cada uno prometiendo ser la solución definitiva. La realidad es que todas estas metodologías son leaky abstractions — funcionan bien cuando las implementas correctamente y entiendes sus limitaciones, pero ninguna es una bala de plata. Sin embargo, hay un denominador común en todas ellas: están obsesionadas con construir mejores feedback loops.

Hoy quiero enfocarme en tres aproximaciones que, aunque vienen de disciplinas distintas — DevOps, Lean, y experimentación de producto — se complementan magistralmente. No son otro framework más; son principios probados con data dura de miles de organizaciones. A fin de cuentas, todas las disciplinas tienen que poner su granito de arena para que esto funcione: ingeniería necesita feedback técnico rápido, producto necesita validación de usuarios, y el negocio necesita saber si vamos en la dirección correcta.

En “Accelerate”, los investigadores de DORA encontraron algo revelador: los equipos de alto rendimiento no eligen entre velocidad y estabilidad — logran ambas simultáneamente. ¿Cómo? A través de feedback loops que operan en múltiples niveles:

Feedback técnico inmediato: Continuous Integration que detecta problemas en minutos, no días. Tests automatizados que corren con cada commit. Monitoring que alerta antes de que el usuario se dé cuenta del problema.

Feedback del producto: A/B testing riguroso que valida si un feature realmente mueve las métricas que importan. Como explican en “Trustworthy Online Controlled Experiments”, el Overall Evaluation Criterion (OEC) debe ser medible en semanas, no meses, creando un loop entre hipótesis y validación.

Feedback organizacional: Prácticas como el “catchball” que describe Accelerate, donde la información fluye verticalmente y horizontalmente, permitiendo que los equipos de primera línea aprendan sobre prioridades estratégicas mientras los líderes aprenden sobre la experiencia real del cliente.

La cultura del equipo emerge de estos loops. Un equipo con feedback rápido y confiable naturalmente desarrolla confianza para moverse rápido. Un equipo con feedback lento o inexistente naturalmente se vuelve conservador y temeroso. No es un problema de personas; es un problema de sistema.

Un bonito problema

Tengo una mente que le gusta optimizar. Optimizar una variable generalmente es fácil — cortas todo lo que la afecta negativamente a cero y después subes a tope lo que la mejora. Pero los problemas bonitos, los que realmente valen la pena, vienen de tener que optimizar para que dos variables que normalmente se afectan negativamente mejoren a la vez.

Velocidad y calidad en software son el ejemplo perfecto de un bonito problema. Históricamente, la industria las ha tratado como un trade-off inevitable. “¿Quieres rapidez? Sacrifica calidad. ¿Quieres calidad? Ve más lento.” Pero esta es una falsa dicotomía que la investigación moderna ha destruido completamente.

La clave está en entender que velocidad y calidad no son características que agregas a tu código — son propiedades emergentes del sistema. No puedes simplemente decidir “ser más rápido” o “tener más calidad”. En cambio, debes construir un sistema que naturalmente produzca ambas. Y ese sistema se construye mejorando métricas específicas que actúan como palancas.

El secreto no es implementar todas las métricas de golpe — eso es una receta para el fracaso. Es más como acercarse a un buffet: empiezas eligiendo una métrica de velocidad (quizás Lead Time) y una de calidad (tal vez Change Fail Rate) que hagan sentido para tu momento actual. Las agregas al ritmo del equipo, las vuelves parte del día a día, dejas que se vuelvan hábito.

Solo cuando esa primera métrica es tan natural como respirar, tomas la siguiente que la complemente. Deployment Frequency para reforzar velocidad. MTTR para robustecer calidad. Construyes el sistema incrementalmente, métrica por métrica, hasta que un día te das cuenta de que tu equipo está entregando features diariamente con menos del 5% de failure rate — y ya no se siente como un esfuerzo heroico, sino como la forma normal de trabajar.

Velocidad: más allá de escribir código rápido

Cuando hablamos de velocidad en desarrollo de software, la mayoría piensa en escribir código más rápido. Pero como aprendí construyendo productos durante años, la velocidad real no se trata de qué tan rápido tecleas, sino de qué tan rápido entregas valor al usuario.

DORA define velocidad a través de dos métricas fundamentales que han probado predecir el éxito organizacional:

Lead Time for Changes: El tiempo que toma desde que un desarrollador hace commit hasta que ese código está corriendo exitosamente en producción. Los equipos élite logran esto en menos de una hora. No es broma — una hora desde la idea hasta el usuario. Compare esto con organizaciones tradicionales que toman meses para el mismo viaje.

Deployment Frequency: Qué tan seguido despliegas a producción. Los mejores equipos despliegan bajo demanda, múltiples veces al día. Esto no es velocidad por velocidad — es sobre batch size. Lotes pequeños significan feedback más rápido, menor riesgo, y paradójicamente, mayor calidad.

Pero aquí está el insight crucial que muchos pasan por alto: estas métricas no son sobre trabajar más rápido en el sentido tradicional. Son sobre eliminar fricción, automatizar lo repetitivo, y crear flujo continuo. Y es aquí donde el mundo de A/B testing ofrece una perspectiva complementaria fascinante.

El Overall Evaluation Criterion (OEC) del mundo de experimentación controlada añade otra dimensión a la velocidad: la velocidad de aprendizaje. No solo importa qué tan rápido despliegas, sino qué tan rápido validas si lo que desplegaste mueve las métricas que importan. Los mejores equipos pueden correr experimentos en 1-2 semanas, obteniendo data estadísticamente significativa sobre si un feature realmente aporta valor.

Esta combinación es poderosa: despliegas rápido (DORA) y aprendes rápido (A/B testing). Es la diferencia entre correr rápido con los ojos vendados versus correr rápido con visión clara del destino.

Las estrategias para mejorar la velocidad real incluyen:

Automatización comprehensiva: No solo tests, sino deployments, rollbacks, monitoring. Todo. Los equipos de alto rendimiento reportan el menor trabajo manual. No porque sean flojos, sino porque entienden que el tiempo humano es demasiado valioso para gastarlo en tareas repetitivas.

Arquitectura desacoplada: La arquitectura más importante no es microservicios vs monolito — es qué tan independientemente pueden trabajar los equipos. Si necesitas coordinar con tres equipos para hacer un cambio, tu velocidad está limitada por el equipo más lento.

Trunk-based development: Branches que viven menos de un día. Suena aterrador hasta que te das cuenta de que el riesgo real no está en mergear frecuentemente, sino en acumular cambios masivos que nadie entiende completamente.

Working in small batches: Como enfatiza Lean, lotes pequeños aceleran el flujo. Una feature que toma una semana es mejor que una épica de tres meses, incluso si la épica promete más valor. ¿Por qué? Porque el valor no entregado es valor cero, y el feedback tardío es feedback inútil.

Experimentación continua: No solo desplegar rápido, sino validar rápido. Feature flags y A/B testing permiten probar ideas con subconjuntos de usuarios, midiendo impacto real antes de hacer rollout completo. Esto convierte cada deploy en una oportunidad de aprendizaje, no solo de entrega.

Calidad: el multiplicador silencioso

En la era de los LLMs, donde Claude puede generar cientos de líneas de código en segundos, la pregunta “¿qué es calidad?” se vuelve existencial. Ya no es sobre escribir código sin bugs — es sobre construir sistemas que perduren, escalen, y sobre todo, que entreguen valor consistente a los usuarios.

La calidad en software moderno se manifiesta en múltiples dimensiones que DORA y el mundo de experimentación iluminan desde ángulos complementarios:

Estabilidad y Confiabilidad del Sistema

La investigación de DORA define la estabilidad a través de dos métricas clave:

Mean Time to Restore (MTTR): Cuando algo falla (y siempre fallará), ¿qué tan rápido puedes restaurar el servicio? Los equipos élite lo hacen en menos de una hora. Pero aquí hay un matiz importante del mundo de A/B testing: los Guardrail Metrics. Estos son métricas que monitoreas constantemente durante experimentos para detectar degradación antes de que se vuelva crítica. Si tu experimento aumenta los crashes en 0.1%, lo detectas y reviertes antes de que se convierta en un incidente mayor.

Change Fail Rate: ¿Qué porcentaje de tus cambios causan degradación del servicio? Los mejores mantienen esto debajo del 15%. Y aquí el A/B testing ofrece una perspectiva valiosa: no todos los “failures” son iguales. Un cambio que no mueve tu OEC no es necesariamente un failure técnico, pero sí es un failure de producto. La calidad incluye tanto estabilidad técnica como eficacia del producto.

Valor Entregado al Usuario

Aquí es donde el concepto de Overall Evaluation Criterion (OEC) se vuelve crucial. Calidad no es solo ausencia de bugs — es presencia de valor. El OEC te obliga a definir explícitamente qué significa “calidad” para tu usuario. ¿Es velocidad de carga? ¿Engagement? ¿Conversión? Sin una métrica clara, puedes tener código técnicamente perfecto que no sirve para nada.

Como mencioné antes, hoy corremos el riesgo de feature creep multiplicado por 10. Con LLMs, podemos agregar features a una velocidad sin precedentes, pero nuestra capacidad de validar si esos features realmente sirven no ha crecido proporcionalmente. Un producto con 100 features que nadie usa no tiene más calidad que uno con 10 features que todos aman.

Excelencia en el Proceso

La filosofía “building quality in” de Lean se complementa perfectamente con los Trustworthiness Checks del A/B testing. No es solo sobre prevenir bugs, sino sobre asegurar que tus datos, métricas y decisiones sean confiables. Cuando un experimento muestra un aumento del 500% en revenue, el primer instinto no debe ser celebrar, sino verificar — probablemente hay un bug en la instrumentación.

Las estrategias para mejorar la calidad incluyen:

Building Quality In: Dejar de depender de la inspección para lograr calidad. Los tests no encuentran calidad, la confirman. La calidad se construye desde el diseño, se codifica en las expectativas, y se valida continuamente tanto técnica como funcionalmente.

Shift Left on Security: Integrar seguridad desde el principio del proceso, no como un gate al final. Los equipos de alto rendimiento gastan 50% menos tiempo remediando issues de seguridad porque los previenen desde el diseño.

Monitoring Proactivo con Guardrails: No esperar a que los usuarios reporten problemas. Establecer métricas guardrail que protejan la experiencia del usuario. Si cualquier cambio degrada estas métricas — latencia, crashes, errores — se revierte automáticamente, sin discusión.

Experimentación Rigurosa: Cada feature debe probar su valor. No es suficiente que funcione técnicamente; debe mover las métricas que importan. Esto requiere instrumentación cuidadosa, análisis estadístico riguroso, y la disciplina de matar features que no aportan valor, sin importar cuánto esfuerzo costaron.

Learning from Failures: Una cultura generativa que trata las fallas como oportunidades de aprendizaje. Pero extendido más allá de incidents técnicos — cada experimento fallido, cada feature que no mueve el OEC, es data valiosa sobre qué no funciona. La calidad mejora cuando aprendes tanto de los éxitos como de los fracasos.

Mirando hacia adelante

Estamos en un punto de inflexión fascinante. Los LLMs nos dieron superpoderes para generar código, pero con gran poder viene gran responsabilidad (sí, la referencia a Spider-Man era obligatoria). La responsabilidad de no solo ir rápido, sino de ir rápido hacia el lugar correcto. De no solo construir, sino de construir cosas que perduren y aporten valor real.

El futuro no pertenece a quienes escriban más código más rápido — ese juego ya lo ganaron las máquinas. El futuro pertenece a quienes entiendan cómo orquestar esa capacidad para resolver problemas complejos de manera elegante. A quienes puedan balancear velocidad y calidad no como fuerzas opuestas, sino como aspectos complementarios del mismo sistema.

En este nuevo mundo, el desarrollador exitoso no es el que escribe el mejor código, sino el que diseña los mejores sistemas. No el que conoce más sintaxis, sino el que entiende más profundamente el problema. No el que trabaja más horas, sino el que crea más valor.

La paradoja es hermosa: ahora que las máquinas pueden escribir código, finalmente podemos enfocarnos en lo que siempre debió ser nuestro trabajo real — pensar, diseñar, validar, iterar, y sobre todo, crear experiencias que hagan la vida de las personas genuinamente mejor.

Ese es el bonito problema que tenemos por delante. Y honestamente, no podría estar más emocionado por resolverlo.