El desarrollo de software está lleno de paradojas difíciles de manejar. Sin embargo, nuestro trabajo es entregar software.. A pesar de ellas.
Nadie sabe cuánto tomará el trabajo, pero el cliente exige una fecha de entrega
Probablemente esta es la paradoja más grande del desarrollo de software: nunca sabemos con certeza cuánto tiempo tomará un proyecto. Estimamos, sí, pero casi siempre estamos muy equivocados—generalmente subestimamos.
Y aunque esto sea comprensible para los desarrolladores, los clientes no lo entienden. Quieren una fecha y se frustran cuando no se cumple. Las técnicas ágiles como planning poker o story points ayudan, pero no rompen la ley de Hofstadter: “Siempre toma más tiempo del que esperas, incluso si tienes en cuenta la Ley de Hofstadter”.
Agregar desarrolladores a un proyecto retrasado lo retrasa aún más ⏳
Esta es la famosa Ley de Brooks y puede parecer ilógica al principio. En otros campos, más manos implican más velocidad. En desarrollo de software, cada nuevo integrante necesita tiempo para ponerse al día y además aumenta la carga de comunicación y coordinación.
Fred Brooks lo explicó claramente en The Mythical Man-Month y sigue siendo cierto hoy: “Agregar gente a un proyecto retrasado solo lo hace más lento (y más caro)”.
Cuanto mejor codificas, menos codificas
A medida que un desarrollador gana experiencia, comienza a escribir código más limpio, más eficiente y con mejor diseño.
Pero también empieza a tener más responsabilidades fuera del código: Planificación, diseño de arquitectura, revisión de PRs, mentoría…
Irónicamente, mejorar como desarrollador a menudo significa dejar de escribir tanto código. Tu impacto crece, aunque tu cantidad de líneas escritas no lo refleje.
Las herramientas mejoran, pero el software no se desarrolla más rápido ️
Tenemos herramientas increíbles: React, Next.js, Astro.. Plataformas que hacen que construir software sea mucho más fácil que en los días del CGI y HTML a mano. Más los tiempos de entrega no se han reducido tanto como esperaríamos.
¿Por qué? Porque cada nueva herramienta resuelve problemas y crea otros: Pipelines de build lentos, configuraciones complejas, paquetes innecesarios. Lo que antes era simple, ahora puede ser más abstracto y difícil de depurar.
Nuestro software luce mejor y es más complejo, pero no necesariamente se desarrolla o ejecuta más rápido.
Una última paradoja: el software nunca está realmente terminado
Siempre hay una nueva funcionalidad que agregar. Siempre hay un “y si también hiciera..”. A diferencia de un puente, que tiene un fin claro, el software está en constante evolución.