Citar:

El problema de ese tipo de desarrollo es que a veces los árboles no te dejan ver el bosque..., uno se centra en la pequeña parcela y después vienen los problemas globales.

Lo importante es comprender cabalmente que es lo que queda implicado cuando se propone un ciclo de desarrollo iterativo y evolutivo o incremental. Esto cambia la manera en que se piensa sobre cómo se debe desarrollar un programa y cobra más importancia cuando el proyecto de mediano a grande o cuando debe ser realizado por un equipo.

Cuando se programa de forma individual el proceso de desarrollo y la metodología que se aplica debe adecuarse a esa situación y si el proyecto es pequeño es posible aplicar sin mayores problemas un proceso de desarrollo en cascada (análisis -> diseño -> codificación -> pruebas -> implantación -> mantenimiento), pero de todos modos sería mejor no ceñirse nunca a eso y aplicar siempre un proceso iterativo y al menos algunos conceptos de agilidad (metodologías ágiles) como TDD.

Citar:

Empezaba a hacer el diagrama y a mitad ya lo tenía claro y el terminar de escribirlo me parecía una pérdida de tiempo.

Coincido plenamente, si ya había cumplido su propósito aún sin estar terminado, ¿para qué concluirlo? Solamente sería necesario hacerlo si se tratara de un desarrollo en equipo.

Citar:

No escribo nada, empiezo a teclear de inmediato sin meditármelo mucho, etc. etc... A veces me arrepiento, claro, pero ¿qué sería de la vida sin riesgo?

Pero es que el propósito para el que se usan los diagramas generalmente se puede cumplir escribiendo código. Por ejemplo, la arquitectura se puede describir en términos de las interfaces de las rutinas, módulos o clases que la componen por medio de código. Pero esto implica que ese código es un bosquejo, que debe ser refinado y que generalmente o evoluciona hacia un diseño diferente o termina siendo reemplazado por otro diseño completamente distinto, y uno no debe tener pudor de tirarlo a la papelera porque, al igual que un diagrama, ya cumplió su función de permitir que se profundice el conocimiento sobre cómo deberá construirse el programa.

Sin embargo, cuando el proyecto es de mediano a grande a veces resulta útil dibujar diagramas (de componentes, de clases, de estado) cuando necesitas una visión general y resumida de la arquitectura que sea fácil de visualizar.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Totalmente de acuerdo. Si por "diagramas" en sentido amplio podemos entender lo que yo llamo, cuando me dirijo a mis clientes, "bocetos", es decir una versión esquelética de la aplicación donde, a veces, sólo aparece una pantalla detrás de un botón que dice algo así como "Aquí vendrá todo el sistema de copias de seguridad", etc. etc.... pues vale, sí escribo diagramas.

También coincido contigo en la falta de pudor a la hora de mandar mi código a la papelera una vez queda obsoleto. Muchas veces los defectos de un trozo de código concreto no salen a la luz hasta ser confrontados con "la globalidad" del programa, o con la rigidez o flexibilidad del diseño global a la hora de ser ampliado o modificado.

Además, muchas veces me ha pasado que he utilizado, pongamos, 100 o 200 líneas de código para hacer una función concreta. Funcionan, pero no me convencen, las reescribo, las reenfoco, las retoco y al final me quedo con 10 líneas de una "decepcionante" simplicidad. ¿Dónde quedaron mis bucles dentro de bucles? ¿Dónde mis arrays multidimensionales? Dónde mis docenas de líneas igualando docenas de variables a docenas de campos? Apenas un par de consultas sql bien meditadas, apenas un simple bucle de tres líneas y el resultado es el mismo, pero más sólido, más claro, más limpio. A la basura todo lo de antes y me quedo con ese "destilado". Que hay que ver qué difícil es ser simple algunas veces...

===================
No podemos regresar