Desarrollamos software para aportar valor a un negocio/organización. En ese sentido el desarrollo de software tiene dos cuestiones centrales que son la fuente de sus mayores complejidades: determinar lo que hay que construir y manejar de forma eficiente las necesidades de cambio. Si bien yo he enumerado estos dos temas como cuestiones disjuntas la realidad es que tienen una íntima relación. Determinar lo que hay que construir debe gran parte de su complejidad al hecho de que una vez determinado lo que se debe construir, lo mismo suele cambiar. De todas todas vayamos por parte.
Determinar lo que hay que construir
Este es un tema que se ha tratado bastante, a punto tal que se ha generado un disciplina alrededor del tema: Ingeniería de requerimientos. Hoy por hoy, luego de haber leido, reflexionado y experimentado creo que el tema puede simplificarse a dos escenarios:
1) requerimientos conocidos y estables
2) requerimientos no-conocidos y/o no estables
Nunca en 15 años de trabajo en la industria me encontré con el caso (1), pero curiosamente creo que gran parte de la bibliografía, técnicas y conocimientos de la ingeniería de requerimientos está enfocada en este tipo de escenarios. Se me ocurre que en estos escenarios puede ameritarse hacer un trabajo intenso sobre los requerimientos antes de comenzar con el desarrollo (digo esto sin estar muy convencido).
Todos mis proyectos se enmarcan en escenarios del tipo (2), en algunos casos me ha tocado desarrollar software sin tener requerimientos conocidos, simplemente teniendo una visión y un objetivo de negocio y debiendo «experimentar sobre los requerimientos». En la gran mayoría de los proyectos en los que he participado me he encontrado con un conjunto de requerimientos cambiantes a satisfacer y ha sido precisamente esa propiedad «cambiante» la fuente de las principales fricciones del proyecto.
Para estos escenarios del tipo 2, no considero que sea útil, ni conveniente realizar un trabajo intenso sobre los requerimientos antes de comenzar el desarrollo. Al contrario, creo que la cuestión pasa por «probar» de una forma sistemática siguiendo 4 premisas:
- Trabajo iterativo
- Involucramiento del usuario
- Entrega frecuente
- Feedback continuo
Manejar de forma eficiente las necesidades de cambio
A mi parecer este solo punto justifica la gran mayoría de las prácticas técnicas de la ingeniería de software (arquitectura, diseño OO, automatización, integración continua, etc). Si uno tuviera la certeza de poder escribir una pieza de código y nunca más modificarla podría no preocuparse por escribir código claro, mantenible y testeable. Curiosamente creo que en la formación académica se hace foco en la enseñanza de las prácticas técnicas pero sin hacer suficiente foco en el por qué de su importancia. Al construir software buscamos cumplir ciertas propiedades para facilitar la evolución/cambios que el software deberá soportar. El no cumplir con dichas propiedades suele generar diversos tipos de perjuicios para el negocio.
Obviamente más allá de estas dos cuestiones hay otras miles que también son relevantes (trabajo en equipo, planificación, etc), pero a mi parecer estas dos son las que están en los primeros puestos de complejidad.