Hay muchos artículos sobre lo que unos consideran programar bien, y por eso han inventado muchos conceptos para conseguirlo: encapsulación, modularización, convenciones de nombres, orientación a objetos, comentarios de documentación y muchos más. Así de bonita la teoría.

En la vida real nos encontramos con líneas de código que no caben en una pantalla (y a veces ni en cinco), con funciones de mil líneas, con nombres de variables de una letra y, desde luego, todo sin comentarios. No es que los autores de tanta monstruosidad dirían que programaran bien – lo que hacen es “no perder tiempo con cosas innecesarias”.

Lo curioso es que programadores así muchas veces tienen éxito. Su criterio no es un buen diseño sino “que funcione”. Muchas veces llegan a hacer los programas funcionar antes que los informáticos afectados por conceptos académicos los suyos. Y el primero vende. Puede ser que el programador ordenado triunfa en un concurso de la NASA. En el mercado libre triunfa quien sabe vender. El primero vende su programa y los errores que quedan ya se arreglarán en la segunda versión – a saber cuándo y por cuánto – pero el consumidor ya tendrá la paciencia si una vez está acostumbrado a un producto.

Ahora me pregunto: ¿por qué gente con tanto éxito no escribe libros sobre cómo lo han tenido? Tenemos libros sobre cómo programar bien y otros cómo hacerte rico, pero ninguno sobre cómo hacerte rico programando. ¿Por qué no hay ningún artículo que te cuenta que el secreto no está en programación orientada a objetos sino en la programación orientada a objetivos?

“Orientado a objetivos” es una forma fina de “lo importante es que funcione”. Y no es una idea esotérica: hay bastantes ofertas de trabajo que lo piden – sobre todo para puestos de jefe. Si es así de deseado, ¿entonces por qué no se enseña la programación orientada a objetivos en la universidad? ¿Por qué nadie nos revela el secreto?

Tengo varias teorías:

  • Los profesores no tienen la preocupación de “a ver si gano lo suficiente al fin de mes” y por eso no se sienten lo suficientemente expertos para explicar la programación orientada a objetivos.
  • Hay una conspiración de programadores orientados a objetivos que mantiene secreto el saber de hacerte rico programando.
  • Un programador orientado a objetivos no es realmente un genio sino alguien que dispone de un algún colega ordenado con genio que le arregla los fallos en el código. La razón porque los programadores orientados a objetivos se hacen jefes es más bien porque el puesto de jefe es el único en el departamento de informática en que no hay que escribir código.
  • Personas que trabajan orientadas a objetivos se orientan a objetivos que han establecido otros. Mientras no hay nadie que les da el objetivo de escribir un artículo sobre “por qué es mejor no perder tiempo con buen diseño”, no lo van a hacer.

Pero me queda la esperanza que este artículo inspire a algún veterano de compartir su sabiduría. Cuando reconozco no haber llegado a entender como uno se puede sentir cómodo arreglando a una función con mil líneas, me atrevo a adivinar el verdadero fin de la programación orientado a objetivos: ¡psicología! No programas para un ordenador sino aprovechas las emociones del usuario final!

  • El fin de un programa no es un buen producto sino una buena venta.
  • Los consumidores no compran algo nuevo porque es bueno sino porque es novedoso. Aquellos que siguen la moda tecnológica más de cerca se interesan por lo que su nuevo capricho podría hacer. Para saber si realmente lo puede hacer no tendrán el tiempo suficiente hasta la próxima versión.
  • Las insuficiencias de un programa permiten ofrecer (y vender) una nueva versión del programa que a su vez puede contener nuevos errores.
  • Sacar nuevas versiones frecuentemente da más impresión de mejora continua que un producto que ya funciona bien desde el principio. Cuando más versiones en menos tiempo, menos posibilidades tienen los usuarios a descubrir los errores de una versión en concreto.
  • Siendo el primero en sacar un nuevo producto te convierte automáticamente en “experto” para el dominio. Te asignarán empleados que te ayudan a mantener el código que tú pronto dejarás de entender. Esto permite elogiar a tus colegas como los verdaderos expertos de tu código.
  • Algún empleado igual de listo como tú sabe que una larga lista de errores fijados encantará al director. Y por lo tanto asegurará que siempre habrá una lista larga. Así se cualifica para liderar pronto un equipo.

En todo caso es una estimación y reconozco mi insuficiencia en la materia. Antes de conocer a un experto del tema no me quedará otra que seguir programando como alguien a que castigan a volver a leer y entender su propio código una y otra vez.

Lectura adicional

Para los programadores orientados a objetivos
Para los demás