🔥¡La culpa siempre es de los programadores!

💻 Probablemente, más de una vez, como desarrollador o trabajando en un proyecto de software, te has encontrado con esa sensación que parece dar vida al título de este artículo, sintiendo que todos los problemas recaen sobre un par de líneas de código en alguna rama perdida de tu repositorio. Pero, para tu tranquilidad, no es así.

Siempre me ha llamado profundamente la atención el desinterés, e incluso la subestimación, que se le da a las etapas más importantes en el desarrollo de software. Es cierto que muchas veces sucede por ignorancia 📚, otras por ego 🦚, y en ocasiones simplemente porque no es negocio 📈.

🗣️ He llegado a escuchar frases como: “¡Qué importa la diferencia entre requisito y requerimiento!”, o “¡Eso que decís de los requisitos es una pavada!”.

📖 Sin embargo, como señala Fred Brooks en No Silver Bullet:

"La parte más difícil de construir un sistema de software es decidir exactamente qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requisitos técnicos detallados, incluidos todas los interfaces con las personas, las máquinas y otros sistemas de software. Ninguna otra parte del trabajo afecta tanto al sistema resultante si se hace mal. Ninguna otra parte es más difícil de rectificar más adelante."

💡 Para aquellos que trabajamos en el dominio del software, muchas veces el enamoramiento por las soluciones técnicas 🛠️ o los procesos 🔄 nos desvía de lo esencial.

Nos enfocamos en resolver desafíos inmediatos y olvidamos el valor estratégico de cada etapa.

⚠️ ¿Cuántos desarrolladores, líderes de equipo, líderes técnicos o dueños de producto tienen que cargar con el peso de mantener sistemas atrapados en su propia fragilidad?.

Aplicaciones donde cada pequeño cambio es un terremoto que sacude otras partes del sistema y cada tarea del “cronograma” se casa con la urgencia del momento.

⚒️ La deuda técnica se acumula, y el diseño deficiente convierte cada mejora en una odisea costosa y frustrante. En este escenario, no se trata solo de programar mejor, sino de pensar diferente.

🌱Crecer, no construir

La traspolación de procesos tradicionales y la falta de pensamiento crítico nos han llevado a creer que el software debe "construirse". Sin embargo, como señala Brooks:

📖 "Las estructuras conceptuales que construimos hoy son demasiado complicadas para especificarse con precisión de antemano y demasiado complejas para construirse sin errores. Entonces, debemos adoptar un enfoque radicalmente diferente. Volvamos nuestra mirada a la naturaleza y estudiemos la complejidad en los seres vivos, en lugar de los trabajos inertes del ser humano. Aquí encontramos estructuras cuya complejidad nos asombra: el cerebro, por ejemplo, es intrincado más allá de cualquier mapeo, poderoso más allá de la imitación, rico en diversidad, autosuficiente y capaz de renovarse. El secreto está en que el cerebro crece, no se construye."

🎨 El desarrollo de software es un arte porque requiere abstraer problemas del mundo real, encapsular ese conocimiento en especificaciones y luego traducirlo en un lenguaje que una máquina pueda entender. También es un arte porque combina creatividad, una comprensión profunda de los problemas y la habilidad para diseñar soluciones únicas y efectivas. Cada desarrollador puede abordar un problema desde perspectivas diferentes: algunas funcionales pero complicadas, otras elegantes y minimalistas.

🎯¿Dónde está el verdadero desafío?

🔍 Parece estar claro: Las organizaciones suelen priorizar sus esfuerzos en presionar a los equipos por el “cumplimiento” 📊 más que en formar una cultura del propósito 🌟.

📈 Datos reveladores: No por nada, casi el 67% del tiempo en el trabajo en general se destina a comunicar 🗣️, mientras que solo el 33% se utiliza para crear 🎨 (Microsoft Research). Áreas gerenciales altas, medias o C-levels con poca o nula formación en requisitos y desactualizados en gestión, perpetúan el "Bullshit management" ( fragmento tomado de una publicación de Dr Bart Jaworski citando a David Pereira ).

Esto termina afectando negativamente:

• 📉 La calidad del diseño del software.
• 🛠️ La capacidad de los equipos para innovar.
• 💡 El propósito estratégico a largo plazo.

💬 El resultado: Un entorno donde las decisiones se toman basándose en urgencias inmediatas y no en la creación de valor real y sostenible.

👀A esto se suma que se dedica poco o ningún esfuerzo a identificar y cultivar grandes diseñadores.

⚠️Esto es un error crítico porque: "La excelencia de los productos dependerá en última instancia de los grandes diseñadores." Fred Brooks

❌ Es cierto que tendremos errores de sintaxis o, en ocasiones, elegiremos soluciones ineficientes para problemas específicos.

Sin embargo: Esos errores no tienen comparación con los errores conceptuales, que surgen de la omisión o la mala gestión de las etapas iniciales del desarrollo, especialmente durante la especificación y gestión de los requisitos.

🌪️ Estos errores conceptuales no solo complican el desarrollo, sino que se convierten en una bola de nieve que crece descontroladamente, sin un horizonte claro. Este escenario termina atrapando a los equipos en un ciclo interminable de ajustes y compromisos, comprometiendo tanto la calidad del producto como la eficiencia del proceso.

😔 Peor aún: Esto genera una cascada de culpa, donde cada pequeño fallo mata lentamente cualquier chispa de motivación, dejando a los equipos desmoralizados y a los proyectos cada vez más lejos de su propósito original.

🏢 Con el tiempo (y no faltará mucho), solo subsistirán aquellas empresas que comprendan y apliquen estos conceptos.

💡 Por el contrario: Aquellas organizaciones que no lo hagan serán reemplazadas por “buenos diseños de software” antes que por el “programa” de alguien que simplemente encontró la oportunidad de venta 💼.

🔧 La diferencia radica en: Un diseño bien pensado trasciende el momento de la venta y se convierte en la base para sistemas sostenibles y escalables, mientras que un "software improvisado" puede colapsar bajo su propia fragilidad.

⚠️ Consecuencia: En un mercado cada vez más competitivo, la supervivencia dependerá no solo de quién llega primero, sino de quién ofrece soluciones robustas y con visión de futuro 🌟.

Es simple: ya sea que crees desarrollo orientado a producto o a servicios, tus clientes no estarán dispuestos a seguir pagando los platos rotos de las malas decisiones de diseño. La competencia, siempre atenta, encontrará rápidamente el lugar para reemplazarte con soluciones mejor diseñadas, más eficientes y sostenibles. En este contexto, la calidad en el diseño no es solo una ventaja, es una necesidad estratégica para sobrevivir, sino mira el caso de Nu cómo logró revolucionar el sector bancario tradicional.

📈 Esto se debe a que, a medida que un desarrollo crece en tamaño, complejidad, número de personas involucradas, deuda técnica y rigidez organizacional:

• La productividad por unidad de esfuerzo disminuye drásticamente.
• Los costos aumentan de forma desproporcionada.
• Aumento de esfuerzo por la pérdida de conocimiento debido a la rotación de las personas en los equipos.

💡 "Software excelente = requisitos excelentes"

"Los grandes diseños provienen de grandes diseñadores. La construcción de software es un proceso creativo. Los métodos sólidos pueden empoderar y liberar la mente creativa, pero no pueden encender ni inspirar al que carece de pasión. Las diferencias no son menores; son como la diferencia entre Salieri y Mozart. Estudio tras estudio muestra que los mejores diseñadores producen estructuras más rápidas, más pequeñas, más simples, más limpias y con menos esfuerzo."

🤝 Entonces, esta problemática no es exclusiva de los desarrolladores; es un tema que nos compete a todos.

✅ Está en nosotros cultivar y fomentar una cultura donde:

• Los requisitos sean valorados y tratados como la base del éxito 📜.
• Cada decisión sea consciente de su impacto a largo plazo 🔄.
• Se empodere a los analistas para enfrentar la complejidad con creatividad y pasión 🌟.

📚Si quieres saber por donde empezar te recomiendo leas: Software Requirements "third edition" de Karl Wiegers una joya de la ingeniería de requisitos.

✔ Solo así podremos construir sistemas sostenibles, que no solo respondan a las necesidades actuales, sino que también sean capaces de crecer y adaptarse al futuro.