Impulsa tu negocio: El código que no te frena mañana (IV)
Leadership
Artículo 4 de 6 · Tiempo de lectura: ~8 min
Hay una conversación que se repite en casi todas las empresas de software que llevan más de tres años en el mercado. Empieza siempre igual:
"¿Por qué tardamos tanto en lanzar algo nuevo?"
Y la respuesta honesta, la que pocas veces se dice en voz alta en la sala de dirección, es esta: porque el código que escribimos hace dos años nos está cobrando intereses ahora mismo.
Ese es el punto de partida de este artículo. No hablaremos de lenguajes de programación ni de arquitecturas cloud. Hablaremos de los principios que determinan si tu equipo de desarrollo es el otro motor derecho que sostiene el avión o el lastre que lo arrastra hacia el suelo.
"Crea procesos que aumenten la relación actividad-producción. ¿Cómo podemos producir más sin perder calidad ni aumentar la actividad?"
El mayor malentendido sobre el desarrollo de software
En muchas organizaciones, el equipo de desarrollo existe en un estado paradójico: es a la vez el recurso más crítico del negocio y el menos comprendido por quienes toman las decisiones estratégicas.
Se espera que sean rápidos. Y cuando no lo son, se contrata a más personas. Pero añadir desarrolladores a un proyecto que ya va lento no lo hace más rápido; a menudo lo ralentiza aún más, porque cada nueva persona necesita contexto, genera más coordinación y añade más puntos de fricción al proceso.
La velocidad de un equipo de desarrollo no depende principalmente del número de personas. Depende de la calidad de las decisiones técnicas acumuladas desde el primer día.
Principio 1: La simplicidad no es un defecto de ambición, es el resultado de la maestría
El principio KISS (Keep It Simple, Stupid) tiene décadas de historia en ingeniería de software y sigue siendo el más ignorado. No porque los equipos no lo conozcan, sino porque la complejidad tiene una tentación oculta: parece más inteligente.
Un desarrollador junior escribe código complejo para demostrar lo que sabe. Un desarrollador senior escribe código simple para que cualquiera pueda entenderlo, modificarlo y mejorarlo sin necesidad de que él esté en la sala.
Esta distinción importa más de lo que parece. Un sistema complejo que solo una persona entiende completamente no es un activo: es una dependencia. Y las dependencias humanas son frágiles.
La trampa más cara en el mundo del software es adoptar arquitecturas sofisticadas antes de que el problema las justifique. Microservicios cuando tienes 500 usuarios. Bases de datos distribuidas cuando caben perfectamente en una relacional estándar. Infraestructura de Google para un negocio que genera 10.000 euros al mes.
Basecamp, una herramienta de gestión de proyectos que genera decenas de millones de dólares anuales, funciona sobre una arquitectura monolítica con una base de datos relacional estándar bien optimizada. Sus fundadores, David Heinemeier Hansson y Jason Fried, han documentado extensamente cómo la sobre-ingeniería es casi siempre una forma de procrastinación disfrazada de rigor técnico.
La pregunta correcta antes de añadir cualquier capa técnica nueva no es "¿sería interesante tener esto?". Es: ¿puedo resolver el problema actual sin esto?
Principio 2: La deuda técnica es el préstamo que nadie firma pero todos pagan
Cuando un equipo toma atajos en el código para lanzar más rápido (no escribe pruebas, no refactoriza, acumula soluciones provisionales) está contrayendo deuda técnica. Igual que la deuda financiera, genera intereses: al principio son pequeños e imperceptibles, pero crecen.
La metáfora financiera es perfecta porque captura algo que los datos confirman: según el informe Software Developer Productivity de McKinsey (2023), los equipos de desarrollo dedican entre el 20% y el 40% de su tiempo a gestionar deuda técnica no planificada. Ese porcentaje no va a nuevas funcionalidades. No genera valor para el cliente. Es tiempo que se consume en mantener en pie lo que ya existe.
El coste de la deuda técnica no es lineal. Al principio no se nota. Pero llega un punto de inflexión a partir del cual añadir cualquier funcionalidad nueva requiere entender, deshacer y rehacer partes del sistema que nadie tocó en meses. Lo que antes eran dos días de trabajo pasa a ser cuatro semanas.
La solución no es no tener deuda técnica, eso es utópico y paraliza el progreso, sino gestionarla de forma consciente. La práctica que más consistentemente funciona: reservar entre el 15% y el 20% de la capacidad de cada sprint exclusivamente para limpiar, refactorizar y escribir pruebas automatizadas. No como un lujo. Como mantenimiento preventivo, igual que cambias el aceite del coche aunque el motor todavía funcione.
Principio 3: Ágil no es un tablero de Jira lleno de colores
La metodología Agile ha sufrido el mismo destino que muchas buenas ideas cuando se convierten en industria: se ritualizó hasta perder su esencia.
En muchas empresas, "hacer Agile" significa tener sprints de dos semanas, reuniones de planificación que duran medio día, retrospectivas que nadie toma en serio y un tablero de Jira con decenas de tickets que nadie mueve. El resultado es la ilusión de agilidad sin ninguna de sus ventajas reales.
La esencia del pensamiento ágil se puede destilar en una sola idea: divide el trabajo en trozos lo suficientemente pequeños como para terminarlos completamente en pocos días, y lanza algo funcional al final de cada ciclo.
No diez cosas al 90%. Dos cosas al 100%, probadas, desplegadas y disponibles para el usuario.
Un equipo que adoptó esta mentalidad de forma radical eliminó sus reuniones de estimación basadas en "puntos de historia", que generan debates interminables sobre si algo vale 3 o 5 puntos, y las sustituyó por una sola pregunta: ¿Podemos terminar esto en menos de tres días? Si no, divídelo. Su velocidad de entrega se duplicó en dos meses sin añadir una sola persona al equipo.
La agilidad real no se mide en procesos. Se mide en la frecuencia con la que el usuario recibe valor nuevo.
Principio 4: Si el despliegue requiere intervención manual, no es escalable
El despliegue de código, el proceso de llevar lo que el desarrollador escribió en su ordenador hasta los servidores donde lo usan los clientes, es uno de los momentos de mayor riesgo y estrés en cualquier equipo de desarrollo.
En organizaciones con procesos maduros, ese momento es aburrido por diseño. Cada vez que alguien sube código a la rama principal, un sistema automatizado lo prueba, valida y despliega sin intervención humana. El desarrollador puede ir a comer tranquilamente.
En organizaciones con procesos inmaduros, el despliegue es un evento. Se agenda para el viernes por la noche o el domingo para minimizar el impacto en los usuarios. Hay una persona encargada. Hay una checklist manual. Hay ansiedad. Y cuando algo falla (porque tarde o temprano algo falla) hay un ritual de corrección urgente que arruina el fin de semana de alguien.
La integración y el despliegue continuos (CI/CD, por sus siglas en inglés) resuelven este problema de raíz. No son tecnología de lujo para empresas grandes: son infraestructura básica para cualquier equipo que quiera moverse con seguridad y velocidad. Existen herramientas accesibles desde el primer día como GitHub Actions, GitLab CI, Vercel, Railway, etc. que permiten automatizar este proceso sin una inversión significativa.
El estándar al que aspirar: los equipos más productivos del mundo despliegan código a producción varias veces al día. Sin eventos. Sin estrés. Sin domingos arruinados.
Principio 5: El desarrollador que entiende al usuario vale diez veces más
Esta es quizás la idea más contraintuitiva de todas, y también la más transformadora.
Durante décadas, el mundo del software separó con claridad quién pensaba en el negocio (product managers, directores) y quién escribía código (desarrolladores). Los primeros tomaban decisiones. Los segundos las ejecutaban. El resultado era predecible: código correcto técnicamente pero desconectado de la realidad del usuario.
La ingeniería centrada en el usuario invierte esta lógica. Un desarrollador que entiende por qué el usuario usa el producto, qué le frustra, qué busca conseguir, toma miles de micro-decisiones técnicas diarias con un contexto completamente diferente al de alguien que solo lee tickets.
Una empresa de software adoptó una práctica que puede parecer radical: cada nuevo desarrollador que se incorpora pasa su primera semana completa respondiendo tickets de soporte al cliente. Sin escribir código. Respondiendo preguntas, resolviendo dudas, escuchando frustraciones.
El efecto documentado fue inmediato: el código que escribían después era notablemente más limpio, más usable y más intuitivo. No porque hubieran aprendido a programar mejor en una semana, sino porque habían adquirido el contexto humano que transforma las decisiones técnicas.
No aísles a tu equipo de desarrollo del cliente final. El contexto de negocio no es ruido que distrae del código; es el insumo que convierte el código en valor. Y a la vez, desarrollador, mantén la mente abierta para comprender al cliente.
La lista de verificación del código que no te frena
Antes de cerrar, aquí está la Definición de "Terminado" (Definition of Done) que todo equipo debería tener visible:
Una funcionalidad que no cumple estos seis puntos mínimo no está "terminada". Está al 90%, que en software es lo mismo que al 0% desde el punto de vista del usuario.
El otro motor derecho del avión: construcción sostenible o trampa del crecimiento
Volvemos al modelo del avión. El desarrollo de software es uno de los motores derechos del negocio digital. Un motor construido con deuda técnica acumulada, procesos manuales y equipos desconectados del usuario es un motor que pierde sustentación con cada maniobra. Yo no me subiría a ese avión.
Los cinco principios de este artículo no son mandamientos técnicos. Son decisiones de negocio disfrazadas de decisiones técnicas. La simplicidad, el control de la deuda, la entrega continua, la automatización y la empatía con el usuario son palancas que determinan si tu empresa puede maniobrar en el mercado o si está atrapada gestionando su propio pasado.
En el próximo artículo salimos de los cimientos y nos centramos en lo que convierte el valor en ingresos: el mensaje, el marketing y las ventas. Cómo contar tu historia de forma que la gente quiera escucharla, confiar en ti y, finalmente, comprarte.
🤖 Prompts
Prompt 1 — Auditoría de deuda técnica en lenguaje no técnico
Prompt 2 — Convierte tu proceso de desarrollo en verdaderamente ágil
Prompt 3 — Crea tu Definition of Done personalizada
📚 Bibliografía
Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. (La referencia definitiva sobre código legible y sostenible.)
Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2ª ed.). Addison-Wesley. (Origen del concepto moderno de deuda técnica y refactorización.)
Humble, J. & Farley, D. (2010). Continuous Delivery. Addison-Wesley. (El libro fundacional de los pipelines CI/CD y el despliegue automatizado.)
Fried, J. & Heinemeier Hansson, D. (2018). It Doesn't Have to Be Crazy at Work. HarperBusiness. (Sobre simplicidad técnica y organizativa; el caso de Basecamp.)
McKinsey Digital. (2023). Yes, you can measure software developer productivity. McKinsey & Company.
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. (El estudio empírico más completo sobre qué hace a los equipos de desarrollo de alto rendimiento.)