¿Programar sin saber el problema que quiero resolver?

Muchas veces, en las clases de programación, nos encuentro a los profes haciendo mucho énfasis en que los alumnos "entiendan el problema" antes de comenzar a programar. Al escribir esto, imagino que muchos, posiblemente la mayoría, de mis lectores habrán pensado: "¡Obvio!".
Sin embargo, yo miro mi trabajo profesional y la verdad es que no funciona tan así, y no creo que eso sea porque lo hacemos mal. Muy por el contrario, muchas veces eso pasa justamente porque estamos trabajando bien, no es un error metodológico, es un feature de nuestra metodología de desarrollo.

¿Cómo es eso? Bueno, para empezar busquemos un poco de equilibrio en nuestra afirmación. Por supuesto que uno tiene que tener una idea de lo que quiere hacer, y por supuesto que como profes frecuentemente nos encontramos en situaciones en las que le queremos pedir al estudiante que c fa tome un tiempo para entender antes de lanzarse a escribir código. Sí, pero... ¡hasta ahí!

Y aunque tal vez parece demodé discutir esto a 16 años de la publicación del manifiesto ágil, yo creo que seguimos teniendo una contradicción grande frente a nosotros. Imagino que si yo digo que eso es pensar en cascada, a muchos les parecerá anacrónico, nadie piensa ya en desarrollar software en cascada. Los más jóvenes ni saben de lo que estoy hablando. Pero al mismo tiempo, imagino que a muchos (¡todavía!) les da urticaria si escuchan a alguien decir que programa sin entender bien el problema que quiere resolver o que se mandó a codear sin tener un diseño en mente... es que en algunas prácticas, en algunos discursos, en muchos vicios todavía persiste la idea de tener "el análisis primero".

En un desarrollo profesional, no suele pasar que viene alguien con un enunciado inmutable de lo que hay que hacer, como pasa en un parcial. Al contrario, nuestro product owner va puliendo el concepto del producto a medida que avanza el proyecto: se construye una etapa, se enfrenta a los usuarios con estas ideas, se mide el uso, y se toman decisiones que pueden cambiar lo que se hizo antes. A menudo pasa que los programadores negociamos con el product owner, por ejemplo proponiendo alternativas que son más fáciles de desarrollar.
Y si bien muy posiblemente es quien conoce el dominio, los potenciales usuarios y sus problemas quien guía la definición de qué es lo que queremos del producto, nunca lo hace de manera unidireccional, viendo al resto del equipo de desarrollo como una caja negra que convierte sus especificaciones en software funcionando. En cambio, la definición final del rumbo surge de un proceso interactivo, multidisciplinar, en la que intervienen personas con diferentes visiones y conocimientos: dominio del problema, tecnología (que no es sólo programación), user experience, etc.

Sí, lo sé. Nada nuevo bajo el sol. ¿O sí? ¿Será que ya esos conceptos cascadosos ya están olvidados? ¿O nos sigue pasando que debajo de los nombres nuevos seguimos pensando el desarrollo de software como una cadena de montaje?