Barrapunto

...en la gran cascada, claro.
La cascada es el mejor método para un proyecto... si los diseñadores tienen 100% claro qué es lo que hacen y los programadores entienden 100% lo que desarrollan. Y suponiendo que todo esto se cumpla a rajatabla, siempre quedará el usuario final o el jefecillo de turno que no tendrán ni pajolera idea de todo el meollo y pondrán pegas y habrá que cambiarlo para acomodarlo a sus necesidades (a veces nuevas, porque hasta que no ven el programa ni se les ocurren). La cascada falla porque el diseño y programación de software no es algo estable NUNCA. Los requisitos cambiantes mataron a al diseño en cascada desde su nacimiento, pues ya hasta antes de acabar el diseño hay lumbreras por ahí a los que se les ocurre cambiar una pequeña cosa de nada que te hace replanteartelo todo desde el principio o hacer un parche, porque cuando ya se está programando los desarrolladores descubren que con la tecnología que tienen hay cosas que son demasiado complejas de hacer, imposibles o se tropiezan con que hay que hacer un rediseño porque a veces tienen más visión a largo plazo que los propios analistas y ven que no va a poder ampliarse/mantenerse el código como ellos planearon, o simplemente parchearán porque hay que sacar el programa para mañana y no hay tiempo para tonterías, ya si eso se rediseñará cuando pidan más cosas (que siempre pasa) y se comerán el marrón los mismos analistas del principio. En el caso de que los programadores sean los analistas esto es más sangrante, porque los cambios los harán sobre la marcha sin replantearse ni rediseñar nada y quedará un pastiche enorme que en el futuro será imposible de manejar. ¿Lo pinto muy negro? quizá. Quizá en un mundo mejor se harían las cosas bien y esto no pasaría. Pero estamos en un mundo donde prima la cantidad en lugar de la calidad, aunque a la larga retrase los proyectos y los haga inmanejables.

El conocimiento profundo del problema lo tienen las personas que están resolviendo el problema mediante otra solución, informática o no, en el cliente. Tal vez no cada uno por separado, pero sí en conjunto. El cómo extraer esa información de manera útil para poder implementar una solución es precisamente la labor del analista, igual que el saber decidir qué estrategia se debe aplicar para implementar esa solución mediante herramientas informáticas es tarea del diseñador. Y fíjate que lo que he descrito no tiene nada que ver con que luego desarrolles usando cascada, iterativo, Agile o lo que te parezca, pero sigue siendo básico: Si no haces esos pasos bien te espera un mundo de dolor, frustración y pasos atrás independientemente de la metodología que uses.

Cambiar el código implica recodificar una parte, volver a probar y desplegar. Cambiar la especificación significa rehacer el análisis, adaptar el diseño, recodificar una parte del código, volver a probar y desplegar. ¿Y resulta que es mejor lanzarse a codificar prototipo tras prototipo mientras averiguas sobre la marcha cuál debería ser el diseño apropiado, o si tu análisis era correcto?. Yo flipo.

Y los Illuminati. Y el Club Bilderberg, que siempre se libran, los muy cabrones.