Programando… como arte y filosofía de trabajo

Llevo ya 6 meses fuera de España. Trabajando en un proyecto europeo de física. Lo que nunca pensé que pasaría. Y últimamente he vuelto al último año de carrera. No de forma literal, sino que es la sensación que tengo. Fue ese último año cuando, tras haber pasado los años estudiando y profundizando mucho en la física, todo comenzó a encajar. Diariamente con la cabeza funcionando a tope, estudiando lo de clase y más; artículos, papers, blogs, libros. Era como ser una esponja, todo era sencillo de entender y aprender nuevos conceptos o ideas era cuestión de unas horas y algo de práctica. Con el cerebro funcionando al máximo y con más ganas de profundizar en otros campos.

Pues así estoy ahora. Con esa sensación de que cada cosa nueva que aprendo consigo hacerla encajar en todo lo anterior. Es difícil de explicar. Además, ahora que estoy metiéndome en la programación como hace tiempo que tenía ganas, estoy enfocando todo desde un punto de vista especial, orientado no sólo a la parte práctica, sino dando importancia también a los aspéctos teóricos. Así que estoy leyendo muchos artículos y papers sobre paradigmas de programación, fundamentos de cómo funcionan los compiladores y los procesadores; artículos sobre “teoría de la programación” por llamarlo de alguna forma. Y esto ha hecho que haya visto ciertas cosas que pasaban desapercibidas antes sobre el mundo del software y de la computación.

Uno de esos papers que me han impresionado especialmente es un artículo escrito por un auténtico mito de la programación: Donald Knuth. “Programación de Computadoras como Arte”. Este tipo es uno de los padres del desarrollo de software, habiendo escrito la que se considera obra clave de la programación: “The Art of Computer Programming”. Una obra escrita (por el momento) desde 1962 hasta 2011 que salió el último capítulo que la compone… por el momento. Una obra tan general y buena que, según dicen los expertos, sigue siendo actual.

En esencia el artículo anterior, que es de hace un tiempo ya, habla de que la programación de ordenadores tendría que terminar enfocándose hacia ser “un arte”. ¿En qué sentido?

Un ordenador ejecuta las intrucciones de forma lineal. Accede a memoria, lee un dato, hace operaciones, lo guarda, lee otro, recibe parámetros… Algo aparentemente tan simple, puede resultar extremadamente rápido o demasiado lento, dependiendo del orden o la forma en que el programador ha dispuesto que se ejecuten las órdenes. Siendo un poco hábil, se puede conseguir que el mismo programa que ejecuta los mismos cálculos, sea más rápido ejecutándose, ya que se ha elegido un orden o estructura que minimiza esos pasos, evita copias innecesarias de datos en memoria, accesos de lectura, etc. Por tanto, cuando Knuth habla de arte, ya no es sólo que un programador sea capaz de escribir un código que haga lo que se pretende, sino que ese código esté escrito de tal forma que pueda ser más eficiente que de cualquier otra manera. No sólo eso, quizá el algoritmo usado es especialmente bueno por su sencillez. En programación, por lo que he podido comprobar, entre dos algoritmos que realicen la misma tarea, el más simple y compacto será el que mejor se ejecute. Así, que tener una idea feliz que permita reducir una serie de operaciones en varias líneas a, por ejemplo, otro algoritmo recursivo de tres líneas va a suponer una mejora en la calidad y velocidad del programa. No sólo por la posible reducción de tiempo, sino porque cuando otro programador tenga que leer el programa o modificarlo, en lugar de tener que descifrar varias líneas de código, sólo tendrá que entender tres. Siempre es una mejora. Pero para ello, no basta con saber escribir código, sino que hay que pensar cómo escribirlo y entender cómo funciona un ordenador a un nivel básico, o al menos tener una idea. Quizá eso es lo más difícil para alguien que pretende ser buen programador.

En este arte no se contempla la estética tradicional, asociada a los objetos materiales, como podría ser una pincelada maestra o una piedra tallada. Aquí se contempla la inteligencia, el ingenio y la brillantez de aquél que ha conseguido llegar a un resultado por un camino especial que nadie más había descubierto. Mucho de ciencia, aunque también algo de arte.

Como el cine

Pero como todo “arte”, sufre de mercantilización. Esto es, la programación como cadena de montaje. Todos esos programas de mala calidad, o tremendamente oscuros que hace que sea un infiernos mantenerlos, arreglar bugs o actualizarlos. Algo muy dado en las consultoras tecnológicas. Esto surge de tiempos de entrega absurdamente cortos, decisiones de gestión basadas sólo en criterios económicos sin base técnica. Programadores noveles (como podría ser yo) trabajando en sistemas complejos y haciendo lo mejor que saben lo más rápido que pueden. Esto sólo da trabajos mediocres que pasan el apuro y poco más. Parches sobre parches puestos sobre correcciones hechas con prisas. Esto provoca que en un momento en que más dependemos de la tecnología, ésta resulta ser, en término medio, mediocre desde el punto de vista del software. Pero no mediocre en el sentido meramente intelectual, friki o como se quiera llamar. Existe un problema con el hecho de tener ingentes cantidades de código oscuro, escrito por multitud de personas distintas que no llegaron a entender del todo lo que ya había hecho (por los motivos anteriores o simple pasotismo) y con multitud de parcheos o arreglos parciales: bugs en potencia.

Y esto es más grave de lo que podría parecer. Como dice Bjarne Stoustrup, el creador de C++, en este artículo, subyace un problema de seguridad y confiabilidad en este asunto. Empresas que basan su negocio en estructuras complejas de software que ninguno de sus trabajadores llega a entender en profundidad debido a que aquellos que pudieron llegar a entenderlo eran demasiado caros. Entonces se sigue avanzando con programadores “mecanizados” que realizan su trabajo sin pensar demasiado, como el trabajador de una fábrica que aprieta una tuerca, ajusta una junta o engrasa un mecanismo sin entender en realidad para qué sirve exactamente cada una de esas piezas. Esto hace que se tengan complejos sistemas que funcionan siempre al borde del desastre y en los que cada nueva actualización supone tocar algo de esa intrincada maraña de código que, potencialmente, puede interaccionar de forma desastrosa mandando todo al carajo. Y eso es un problema: si nadie en la empresa entiende en profundidad el software y este se viene abajo, en realidad nadie sabrá encontrar una solución duradera.

En definitiva, esto es algo así como el cine: muchas películas, algunas rematadamente malas, otras que “cumplen” razonablemente pero no marcan ninguna diferencia; y entre todo ese maremágnum, algunos programas verdaderamente buenos y sólidos; trabajos realmente geniales.

Código y empresa

Y mi corta experiencia con programación de software científico ya me ha enseñado algo sobre eso. En el trabajo anterior en el que estuve vi cómo se desperdiciaba tiempo, horas de trabajo, dinero y esfuerzo en crear código que no iba a servir de nada, principalmente porque o no se iba a usar o una vez usado, no se iba a dedicar recursos a mantenerlo, corregirlo y mejorarlo. De forma que inversiones cuantiosas de dinero en pagar desarrollos de software eran desperdiciadas en el momento en que se terminaba de implementar el programa. La empresa desarrolladora se desligaba y la entidad que había pagado por el trabajo no dedicaba ni uno sólo de sus empleados a la tarea de comprender ese código y mantenerlo. Simplemente se usaba hasta que surgía algún problema o aparecía alguna situación no prevista que provocaba que ese programa no resultase útil. Y en lugar de desarrollar más el código añadiendo las funcionalidades nuevas, simplemente se buscaba un nuevo software que sustituyese al anterior, aún sin amortizar. Previo paso por caja otra vez, por supuesto.

Creo que nunca tuve una sensación tan clara como allí que mi trabajo era, literalmente, una pérdida de tiempo. El esfuerzo puesto en pensar la mejor forma de resolver un problema, de desarrollar una solución adecuada, era inútil totalmente. Ya que ese programa o código probablemente no saldría ni de mi ordenador. Como mucho, lo observarían mientras yo demostraba lo que había conseguido y me daban la enhorabuena o me sugerían algún cambio. Nada más.

Así que, aunque sirvió como proceso de aprendizaje, cuando no se le da valor a lo que haces, es fácil perder las ganas o la pasión. Fue uno de los motivos por los que ahora mismo estoy en medio de Europa aprendiendo una lengua infernal. Quizá no fuese tan malo al fin y al cabo.

Conclusión

La conclusión personal que saco es que la filosofía empresarial no es la adecuada porque coarta y no recompensa el esfuerzo que supone crear un producto de calidad. Salvo casos particulares, esa es la tónica que se aprecia en las empresas de IT y de consultoría, en las que lo menos importante, irónicamente, es la propia tecnología y desarrollo. En concreto, su estrategia podría llamarse “la estrategia de la escopeta” que consiste en tener una gran cantidad de trabajadores picando código a destajo, sin conocimientos suficientes y sin alicientes para mejorar ese conocimiento, condiciones duras de trabajo en cuanto a horas y una política empresarial realmente absurda, que van sacando versiones de código, parches y ampliaciones que, incidental y temporalmente al menos, solucionarán el problema que debe resolver la empresa. Como disparar un cartucho contra un blanco: algún perdigón dará en el objetivo, aunque sea de refilón. Pero el resultado es una cantidad grande de trabajo no útil debido a errores y falta de planificación, así como falta de conocimientos y de tiempo para adquirirlos por parte de los trabajadores.

Esto tendrá que cambiar. Puede que simplemente ya estemos en ese proceso de cambio, ya que la tecnología se ha filtrado rápidamente en todos los ámbitos de la vida actual, de forma que habrá que replantearse los estándares de calidad y los objetivos que se persiguen. Llegará un momento en que no nos podremos permitir programas inestables ni sistemas que dependan de los mismos y quizá entonces, cambie esta cultura empresarial. Aunque creo que para ello no sólo tiene que cambiar el paradigma de trabajo en la empresa,  sino la misma definición de lo que es trabajar. Es decir, que el teletrabajo se convierta en una realidad más extendida. En ciertos ámbitos como el desarrollo de software o la investigación científica, trabajos tecnológicos que requieran un ordenador en general, el trabajo con un horario fijo dentro de un mismo edificio está dejando de tener sentido. Es más, en muchas ocasiones resulta contraproducente. Personalmente creo que sería ideal teletrabajar. A diario, mis interacciones con mis compañeros de proyecto se fundamentan en ocasionales visitas para consultar dudas o pedir sugerencias y, mayormente, comunicación por mail. De hecho, podría perfectamente trabajar sin necesidad de verles directamente, y en ocasiones ocurre que no nos vemos durante días (salvo en los pasillos) pero la coordinación se mantiene a diario. Lo que significa que podría trabajar desde casa usando la conexión a internet y coordinándonos con mails y demás herramientas. Quizá iría un par de días a la oficina para alguna reunión personal y para sociabilizar con los demás departamentos que siempre tienen algo interesante que compartir.

La conclusión a la que llegué hace tiempo y que cada día se hace más fuerte es que la tecnología permite formas de trabajo impensables hace unos años, lo que ha provocado que ahora mismo estemos en un momento en que las horas en la empresa no son todo lo rentables que podrían ser en muchos empleos. El atar la productividad a un horario fijo cuando tenemos todas las herramientas necesarias durante todo el día en cualquier lugar, es algo absurdo.

Cuando sólo las empresas podían permitirse ordenadores y redes, el trabajo se tenía que hacer a la fuerza en la misma. Pero en un momento en que lo único que necesita un desarrollador o científico es una conexión a internet y un portátil, donde se puede trabajar en remoto en los servidores de la compañia, ligar el trabajo a objetivos en lugar de horas cumplidas en oficina (que no son horas de trabajo reales) permitiría desde luego un resultado (al menos) igual o de mejor calidad y trabajadores con mejor caldad de vida. Si soy capaz de obtener un resultado un martes por la noche y el objetivo era presentarlo el viernes, puedo dedicar más tiempo de la semana a mis hobbies y asuntos personales, además de a formación, haciendo que me plantee con distinto ánimo el seguir con el siguiente objetivo. Si tengo la obligación de ir 8 horas a la epresa, en un horario fijado, ¿qué motivación tengo para dedicar la tarde a ello por mucho que haya tenido una idea que pueda funcionar? Esto pasa, que lees algo o de repente se te ocurre alguna solución para el problema que se tiene entre manos en el trabajo, pero claro, si al día siguiente tengo que ir igualmente a la oficina, ¿para qué molestarme ahora? Apunto la idea que en ocasiones es algo difusa, y confío en que al día siguiete y con esas notas me acuerde lo suficiente como para hacerla funcionar.

Si añadiésemos más flexibilidad (real) y renunciásemos al concepto de trabajo por horas para acercarnos al de trabajo por objetivos, los resultados de media y a la larga serían mejores. Tengo esta convicción porque sé que a mí me motiva esa forma de trabajar, sé que cuando uno tiene libertad para dejar de trabajar cuando está demasiado cansado y seguir un par de horas después (después de hacer la compra, ver una película, hacer deporte o tomar el sol) cuando se encuentra más centrado, hace que trabajar no sea esa pesada carga que hay que llevar para vivir, sino una pasión más de la vida de cada uno. Y habrá gente que no funcionaría con esta forma de trabajo. Pero siempre tendría la opción de ir sus 8 horas a la oficina y olvidarse el resto del día. Cuestión de elecciones personales.

Lo malo es que la flexibilidad no está bien entendida, o no se quiere entender bien por parte de sectores empresariales (hablo de España principalmente). Cuando uno habla del trabajo por objetivos en nuestro país, un escalofrío recorre la espina dorsal del aspirante al puesto. Trabajo por objetivos: concepto este que se enarbola únicamente para dar apariencia de modernidad y para justificar o maquillar la exigencia implícita de horas extra no remuneradas; de llamadas en vacaciones o festivos cuando alguna parte del sistema se ha caído; explotación del trabajador por la asignación de objetivos demasiado amplios a una misma persona o por un tiempo de entrega calculado en base a las necesidades de la empresa en lugar de basarlo en las horas al día que el trabajador firmó que haría cuando entró a la empresa. Curiosamente, el trabajo por objetivos debe ir asociado a una estimación o acuerdo de las horas que la persona va a dedicar al día. Se trata de una media, porque quizá un día apenas dedique 4 horas, pero al siguiente dedique 10. Pero si no se hace una estimación de ese tipo, en nuestro país las grandes empresas de consultoría se lo tomarían como un contrato en el que disponen de todas las horas del trabajador para sus necesidades. Algo que ya creen en ocasiones aunque el trabajo sea con horario fijo.

A este respecto, recomiendo este post de Enrique Dans a raíz de la noticia de que Francia iba a prohibir enviar y recibir correos de trabajo a partir de las 6 de la tarde. Esta es la flexibilidad de la que hablo.

Como digo, mucho tiene que cambiar. En ciertos sectores y empresas europeas y americanas ya se acepta esta cultura como parte del futuro. Ya se ve al trabajador como un valor importante que debe sentirse cómodo y trabajar a gusto. Se está produciendo el cambio hacia el paradigma del siglo XXI, aunque aún queda mucho por cambiar. Y en España… lo único que puedo decir es que no me veo trabajando en España en una empresa de allí. Lo haré si tengo que hacerlo, desde luego, pero si puedo evitarlo es algo que no ocurrirá.

Para acabar cerrando con algo relacionado con el título de la entrada, he de decir que para programar con arte, con calidad y obtener buenos resultados, el trabajo por objetivos no es realmente necesario. La esencia de todo es la cultura o filosofía empresarial. Las empresas que valoran y cuidan a sus empleados son las que obtendrán mejores resultados, las que producirán software de calidad, las que permitirían el teletrabajo si viesen que con ellos sus empleados mejorarían su vida y sus resultados. Así que todo es cuestión de paradigmas: trabajo entendido como en el siglo XIX frente a trabajo entendido como en el siglo XXI (el siglo XX lo dejamos aparte, a nadie le importa). Es definitiva, tantas letras para concluir que no hay “nada nuevo bajo el sol”.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s