¿Cómo tomamos decisiones en la ingeniería de software?
La ingeniería de software enfrenta una crisis desde hace más de 50 años, identificada por primera vez en la Conferencia de la OTAN de 1968. Edsger Dijkstra describió esta crisis en su discurso del Premio Turing, señalando que el crecimiento exponencial del poder computacional ha hecho que la programación se vuelva cada vez más compleja y difícil de manejar.
Con el tiempo, hemos creado más código, más abstracciones y una cantidad creciente de sistemas que, lejos de simplificarse, se han vuelto cada vez más difíciles de mantener y modernizar. La industria del software ha priorizado la creación de nuevas soluciones, sin un enfoque adecuado en la gestión del software heredado, lo que nos ha llevado a una acumulación de sistemas antiguos que requieren un esfuerzo significativo para ser comprendidos, modificados o reemplazados.
El problema del software heredado no solo afecta a las empresas tecnológicas, sino a todas las industrias que dependen de la tecnología. Este libro propone una solución: replantear la ingeniería de software como un proceso de toma de decisiones eficiente y sistemático, en lugar de un proceso basado en la lectura manual de código.
El concepto de desarrollo documentado nos permite transformar la manera en que exploramos los sistemas, optimizando la toma de decisiones y permitiendo una comprensión más clara y precisa de la arquitectura y el funcionamiento del software.
¿Por qué hablar de toma de decisiones?
Los desarrolladores dedicamos más del 50% de nuestro tiempo a comprender los sistemas en los que trabajamos antes de poder realizar cualquier cambio o mejora. Analizamos el impacto de modificaciones, investigamos errores y diseñamos nuevas funcionalidades. Sin embargo, pocas veces reflexionamos sobre el proceso de toma de decisiones en sí mismo.
En la mayoría de los casos, nos enfocamos en evaluar si una decisión fue correcta, pero no en analizar si la manera en que tomamos esa decisión fue la mejor. Para optimizar nuestro trabajo, es fundamental mejorar el proceso de toma de decisiones en sí mismo.
El proceso de toma de decisiones en ingeniería de software
En términos generales, el proceso de toma de decisiones en software sigue estos pasos:
- Evaluamos el problema: Antes de tomar cualquier acción, debemos entender el contexto del problema.
- Exploramos el sistema: Investigamos los componentes del sistema y cómo interactúan entre sí.
- Conversamos con otras personas o con el sistema: Recopilamos información a través de documentación, información del cliente, compañeros o pruebas directas en el código.
- Compartimos información: Organizamos lo que hemos aprendido para poder tomar decisiones informadas.
- Sintetizamos la información obtenida: Extraemos conclusiones a partir de los datos analizados.
- Utilizamos herramientas de desarrollo: Interactuamos con el sistema a través de herramientas que nos permitan verificar y validar nuestras hipótesis.
Sin embargo, en la práctica, este proceso suele ser altamente manual y depende de herramientas monolíticas que no están optimizadas para la exploración de sistemas.
Problemas en la toma de decisiones actual
En la mayoría de los equipos de desarrollo, la toma de decisiones enfrenta obstáculos significativos que afectan la eficiencia y calidad del trabajo. Algunos de los principales problemas incluyen:
- Dependencia de herramientas monolíticas: La mayoría de las herramientas de desarrollo actuales están diseñadas para un uso genérico y no se adaptan a las necesidades específicas de cada contexto. Esto limita la capacidad de los equipos para visualizar datos clave de manera efectiva y tomar decisiones informadas.
- Exploración no estructurada: La mayoría de los desarrolladores analizan sistemas mediante inspección manual y lectura de código sin una metodología definida, lo que hace que el proceso sea ineficiente y propenso a errores.
- Diagramas arquitectónicos inexactos: Muchas veces, los diagramas de arquitectura son generados manualmente, lo que introduce sesgos y errores de interpretación. Además, con el tiempo, suelen quedar desactualizados y no reflejan fielmente la estructura real del sistema.
- Falta de optimización en la comprensión del código: Se asume que la única forma de entender un sistema es leyendo grandes volúmenes de código, cuando en realidad existen enfoques alternativos más eficientes para la exploración y visualización de la información.
Desarrollo documentado
Para abordar este proceso de toma de decisiones y documentación, el desarrollo documentado “Rewilding software engineering” propone una nueva forma de tomar decisiones en software. En lugar de depender de herramientas monolíticas y procesos manuales, adopta un enfoque basado en la generación de micro herramientas especializadas.
¿Cómo funciona el desarrollo documentado?
- Creación de micro herramientas personalizadas: En lugar de depender de una única herramienta general, se crean pequeñas herramientas diseñadas para responder preguntas específicas sobre el sistema.
- Modelado en vivo: Se generan vistas interactivas del sistema, eliminando la necesidad de diagramas manuales.
- Exploración estructurada: Se optimiza la forma en que se analiza el código, reduciendo la necesidad de lectura manual.
- Optimización de la toma de decisiones: Se agiliza el proceso de evaluación y modificación de sistemas, mejorando la eficiencia del equipo de desarrollo.
Caso práctivo: Optimización de un pipeline de datos
Pongamos como caso práctico un equipo de sistemas que intentó durante años mejorar el rendimiento de un pipeline de datos crítico para la organización, que un antiguo compañero dejó programado y sin documentar en detalle. Sin embargo, pese a la inversión de miles de euros y cientos de horas-personas de esfuerzo, los resultados no cambiaban.
Al aplicar una metodología de evaluar, comprender y documentar como propone el desarrollo documentado, en solo dos meses lograron identificar y solucionar problemas fundamentales en la arquitectura del sistema. Descubrieron un servicio externo que desconocían que afectaba el rendimiento, visualizaron la cantidad de datos innecesarios generados y optimizaron los procesos de transformación de datos. La metodología permitió un 600x de mejora en eficiencia comparado con el enfoque tradicional.
Conclusión
La ingeniería de software debe verse como un proceso de toma de decisiones optimizado. La metodología actual en general es ineficiente y se basa en creencias y herramientas limitadas. En la gran mayoría de proyectos se espera que como ingenieros de software tengamos la respuesta al problema, dando por entendido que conoceremos la infraestructura y desarrollo que otro equipo ha desarrollado. Mediante el desarrollo documentado, podemos mejorar significativamente la toma de decisiones, reducir la deuda técnica y optimizar la manera en que interactuamos con sistemas complejos.
Reflexiona sobre la toma de decisiones en tu organización
Reúne a tu equipo y discutir las siguientes preguntas:
- ¿Estamos de acuerdo en que más del 50% del equipo se dedica a leer y entender sistemas?
- ¿Cuándo fue la última vez que hablamos sobre cómo leemos código, y no solo sobre el código en sí?
- ¿Tenemos modelos de nuestro sistema que nos permitan investigar problemas de rendimiento, seguridad o negocio de manera programática?
- ¿Cómo obtenemos nuestros diagramas de arquitectura? ¿Son generados a partir de las fuentes del sistema o creados manualmente? ¿Cómo verificamos su precisión?
Responder estas preguntas permitirá identificar áreas de mejora en la toma de decisiones y optimizar el trabajo con sistemas heredados.
No hay un mejor framework de documentación, pero sin duda exponer los detalles del desarrollo son cruciales para abordar dificultades en el futuro.
Referencias: