Me ha encantado una cita:
Los programas feos son como los puentes colgantes feos: tienen más probabilidades de colapsar que los puentes bonitos, porque la forma en que los humanos (especialmente los humanos-ingenieros) perciben la belleza está íntimamemente relacionada con la habilidad para procesar y comprender la complejidad — Eric Raymond.
La he encontrado en esta entrada de Ricardo Galli. A él, ESR como se conoce a Eric no parece caerle bien pero desde luego la cita se sale. Es algo en lo que yo he pensado muchas veces. De hecho es uno de mis motores para programar, o debería decir mis frenos. A mi me cuesta bastante arrancar, necesito mucha preparación sobre lo que voy a hacer. Me paso mucho tiempo preparando, buscando una coherencia, un simetría. Me viene ahora a la cabeza las cosas que se leían hace unos años sobre Patrones de Diseño y Christopher Alexander y su influencia en la ingeniería del software. Recuerdo que yo llegué a eso a través de la revista RPP y los artículos de Ricardo Devis Botella, al poco me compre sus libros de C++ (1 y 2).
Fue en esa época cuando empecé a buscar una estética o simetría en el diseño, en el modelo de clases, en la solución. La verdad creo firmemente en que es cierto que las soluciones «bonitas» los son porque logran desmarañar la complejidad. Y con ello consigues un resultado que en intrinsecamente flexible, extensible, eficiente, etc. En contraposición a las soluciones por «fuerza bruta» o «on the fly» que a base de chapurrear código e ir parcheando acaban «funcionando» pero son un infierno de mantener, imposibles de extender y al final incluso ineficientes. Por eso es importante dedicarle tiempo a «diseñar» lo que vamos a hacer.
Pero para conseguir eso, el profesional debe estar en un estado de concentración y motivación especial. Eso o haberlo estado tantas veces que es capaz de aplicar buenas técnicas aprendidas. Me quedo con el primer método a ser posible. Y a ser posible en grupo.
lboisset's Ruminations 
Bonita filosofia para programar, difícil quizá de vender porque muchos clientes y gerentes no saben mirar a largo plazo, sino sólo a corto, al precio, a la rentabilidad.
@jp Si, tampoco pretendo venderla «públicamente», es más una postura personal y del equipo. Los resultados en general no hace falta mucho para verlos ya que las soluciones «buenas» y flexibles las sientes pronto, a las pocas horas de estar programando el proyecto, como mucho en la primera o segunda extensión del ámbito del mismo.
En realidad yo creo que es mucho más común, al menos en los grandes programas, no me refiero al tamaño sino a su importancia. Lo notas cuando trabajas con un buen «Framework», lo notas cuando utilizas o «reutilizas» un programa de código abierto que es fácil de «manipular», enseguida sientes que está «bien» diseñado.
A mi me pasó con la VCL de Borland, o con el «Framework» que hicimos en mi compañía. Y sin embargo creo que otros no lo están siendo.
Quizá digo una tontería, pero simplificar esos programas puede ser un interesante proyecto interno que motive y forme a tu equipo.
Un saludo.
@Carlo Pues en esencia ese es el proyecto. Mi idea es un poco catártica puesto que no quiero dirigirles demasiado, pero la idea es construir la nueva generación de nuestros productos partiendo de una serie de premisas pero con libertad de construir el producto que ellos crean que es mejor. El que más y el que menos ya lleva suficiente tiempo con nosotros como para tener una opinión interesante para incorporar al sistema.
Esas premisas son por mi parte arquitectónicas: que sea flexible y extensible. Y funcionales: que incorpore novedades en la forma de hacer las cosas, no funcionalidad extra. Tiene que ser un cambio «radicar» de experiencia de usuario, tiene que ser 2.0.
Ahora que ellos invente, propongan, demuestren y construyan su futuro.