Sí, de hecho es algo en lo que se incide desde introducción a ing. software.

Es cierto que eso es un problema, pero si hubiese una lista de los males de la programación, el copypaste estaría bastante más arriba en ella.

Si, pero el tema es que en COBOL la cosa es como dice Mike Miller, y no solo se trata de evitar el GOTO, sino de saber usarlo.
En otras funciones de cosas la capacidad puede ser anexa sin perjuicio de tecnicas modernas o concepciones arcaicas, esa dicotomía que nos llevaria a una espiral de charlas y contubernios sin salida. Ahi si se evidencia la peresocidad del personal de desarrollo, si puede charlar lo hara y si spuede salir a fumar tambien.

¡Otro tema interesante!

Creo que aquí la regla de oro es “mide primero, optimiza después”. Porque muchas veces se pierde tiempo en algo que “gana mucho tiempo”, sin determinarse primero “cuánto” (en milisegundos, o segundos, o lo que sea).

Alguien me dijo en una ocasión: “Oye ¿tu sabes cuánto le cuesta ejecutar un IF al ordenador? ¿Y sabes cuánto tiempo y riesgos se corren a veces intentando quitar algunos de estos IFs?”
Yo creo en la optimización desde el diseño. Y pondré un ejemplo concreto. Muchas veces lo primero que se hace en una aplicación es modelizar la base de datos. Al normalizar el modelo suelen salir bastantes tablas. Sucede que el tiempo que una transacción tarda en ejecutarse en básicamente proporcional al número de tablas en las que tenga que escribir. El resultado final son amenudo transacciones lentas, porque nadie tuvo suficiente picardía en el diseño del modelo de datos.

Exacto, Sergio. La optimización de diseño es la única que merece la pena hacerse “a priori”.

Pero sí creo, como comentaba en esta cita, que hay que tener mucha experiencia para hacer este tipo de optimización. Porque sino al final obtienes un sistema “overenginered”. Lo típico es el novato que pilla un sistema y lo llena de “patrones”. Empieza a meter factorías a diestro y siniestro para cosas que jamás van a tener más de una implementación. O el que abusa de los EJB (“por si acaso esto se tiene que balancear”) y acaba teniendo un sistema lentísimo para hacer una actualización a una BBDD.

Yo detesto los programas “no locales” en los cuales la implementación real del método que estás buscando está ocho clases más p’allá perdida en algún ignoto paquete o el nombre del directorio que necesitas para saber dónde se están grabando los archivos, está puesto en un oscuro fichero de configuración oculto tras el séptimo sello.
Sobre las aplicaciones en tres capas opino lo mismo: casi siempre traen más complicaciones y quebraderos de cabeza que beneficios.
A veces el software es como la contabilidad: cuanto más aburrido y predecible es lo que te encuentras, mejor que mejor.