Barrapunto

Toda la razón,

y encima el propio texto lo explica el gran problema: "Si no conoces el problema (un conocimiento profundo, que incluya todas las particularidades y casos raros que inevitablemente aparecen en todo sistema complejo), entonces es muy posible que hagas un diseño que en el mejor de los casos sea inadecuado y en el peor incorrecto."

^^^ Resulta que *nadie* tiene un conocimiento profundo, o bien conoce el problema que quiere solucionar, o bien conoce que estrategia se debe aplicar para solucionar el problema mediante herramientas informaticas (o peor, o ninguna de las dos). Pero la coincidencia en ambas... no la conozco mas alla de kernels y otras historias :-)

Ahh y hay otro problema que no se menciona, pero que se deja entrever por tu comentario. Se supone que el codigo es monolitico y dificil de cambiar, pero lo mismo sucede con todos y cada uno de los pasos tomados hasta obtener el codigo. Cambiar una especificacion puede ser tan complicado como cambiar un codigo (o incluso mas).

Asi que francamente, me parece una falacia todo el planteamiento expuesto digno de la maquinaria comercial de las mayores y mas famosas consultoras que hay en este pequeño planeta.

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.