¿Te gusta programar?: La Infelicidad del Programador o por qué hacer software "orgánico"

¿Por qué cada vez odiamos más programar?
Trato de responder a esta pregunta comparando las respuestas entre amigos y tomandome un café "orgánico".

Hace poco le pregunté a mis amigos informáticos si les gusta programar. La respuesta fue un rotundo NO.
Y no programan porque:
> programar es pesado y frustrante
> Se ven más bien como jefes de programadores
> Prefieren administrar o supervisar
> Prefieren contratar a un tercero

Lo mismo hice con mis amigos electrónicos (es decir, más allegados al hardware). La respuesta fue cercana a un Sí porque:
> son tercos y persistentes: escudo antifrustración
> les gusta inspirarse y traer nuevas ideas
> les gusta plantearse retos que deben superar
> les gusta la satisfacción de lo logrado

¿Y si le preguntamos a un pintor por qué gusta de pintar?
> le gusta inspirarse
> le gusta plantearse nuevas formas de pintar
> le gusta la satisfacción de tener un trabajo bien hecho
> persistente, terco

Pienso que quien programa tiene una especial pasión por programar, y quien programa debe encontrar formas (metodologías) que le permitan programar para inspirarse, para encontrar nuevos retos y lograr la satisfacción de lo bien hecho.

Sin embargo, el programador se torna infeliz y frustrado.
Origen de estas frustraciones son los famosos "contratos basados en especificaciones iniciales", que limitan el trabajo a algo supestamente medido por los requisitos de entrada, y donde existen fechas establecidas de entrega y donde, al confrontar lo desarrollado con el cliente, el producto termina siendo malo e incompleto.

¿Por qué no desarrollar un software "orgánico", en constante crecimiento y mejora?, es decir, ¿por qué no plantearle al cliente un método de desarrollo donde la comunicación y las "pequeñas entregas" sean la base para aproximarse a un producto bien hecho y que cubra más allá de las intenciones iniciales?

El "ciclo de desarrollo" es evolutivo, pero tiene "mutaciones" que se originan al contactarse con el cliente y presentar lo desarrollado. Es en esos momentos de confrontación donde realmente conocemos a dónde debe ir el desarrollo. Y si hacemos que las confrontaciones sean el origen del cambio y mejora y no una verificación de lo acordado logramos un sofware que mejora, que cambia y que se transforma en un producto "bien hecho" y, por qué no, aceptémoslo, trae la "Felicidad del Programador".

Vean este video de la gente de RailsEnvy, donde compara el método de desarrolo ágil con el convencional desarrollo orientado a especificaciones y plantea el origen de la Infelicidad del Programador y su solución.

http://www.railsenvy.com/2007/3/22/ruby-on-rails-video-presentation