T2E4 - El software no se construye, se cultiva | Eduardo Ferro (Clarity.ai)
ESDescription
Esta entrevista explora el cambio de una mentalidad de construcción a una evolutiva en el desarrollo de software, enfocándose en minimizar los costes basales, priorizar la sostenibilidad y alinear la excelencia técnica con el impacto de negocio para impulsar la innovación continua.
🎯 Key Learning
El desarrollo de software debe cambiar de una mentalidad de "construcción" a una evolutiva, priorizando la creación del máximo impacto de negocio con la mínima cantidad de código para asegurar sostenibilidad a largo plazo. Lograr esto requiere alinear la excelencia técnica con la estrategia de negocio, usando prácticas como continuous delivery y testing automatizado para gestionar el "coste basal" del software y mantener la capacidad para innovación futura.
📋 Key Points
- Software como evolución: Cambio desde una metáfora de "construcción" hacia una mentalidad evolutiva o de "jardinería", reconociendo que el software es un sistema vivo que requiere modificación continua en lugar de un edificio estático.
- Gestión del coste basal: Cada línea de código y feature añadida incrementa el coste basal de mantenimiento y carga cognitiva, lo que progresivamente reduce la capacidad del equipo para innovación futura.
- Desarrollo minimalista: El objetivo final de un ingeniero es lograr el máximo impacto de negocio usando la mínima cantidad de tecnología o código posible.
- Alineación calidad-velocidad: Alta velocidad de entrega se logra mediante alta calidad interna, no sacrificándola; la excelencia técnica es un prerrequisito para velocidad sostenible y ciclos de feedback rápidos.
- Mentalidad de Product Engineering: Los desarrolladores deben actuar como Product Engineers que empatizan con los clientes, entienden la estrategia de negocio y evalúan los trade-offs de las soluciones más allá de la mera implementación.
- Continuous Delivery como disciplina: Prácticas como testing automatizado, TDD y trunk-based development son herramientas esenciales que permiten a los equipos trabajar en pequeños pasos seguros y mantener un ritmo sostenible.
- Platform Engineering como palanca: Las plataformas internas deben acelerar a los equipos "stream-aligned" proporcionando infraestructura self-service y componentes, reduciendo fricción y manejando compliance o seguridad automáticamente.
- Medición de la salud de ingeniería: Usar métricas DORA (Lead Time, Deployment Frequency, Change Failure Rate y MTTR) para evaluar objetivamente la salud del proceso de entrega y balancear velocidad con estabilidad.
- Technical debt consciente: Distinguir entre "código de mala calidad" y technical debt, que debe ser una decisión de negocio consciente y temporal que eventualmente debe pagarse para evitar ralentizar el desarrollo.
- Autonomía y ownership del equipo: Los equipos deben tener responsabilidad end-to-end de sus productos, integrando habilidades necesarias como QA dentro del equipo para evitar silos y largos lead times causados por handovers.
- Innovación sostenible: Alinear decisiones técnicas con sostenibilidad a largo plazo, asegurando que la arquitectura pueda soportar necesidades de negocio futuras sin requerir una reescritura completa cada pocos años.