Estoy teniendo la idea que el administrador es el ultimo de la linea de quejas. Antes creía que era el programador, pero ahora no estoy seguro. El administrador es como el arquero de fútbol : todos le patean la pelota a él. Él solito debe recibir los embates del partido. Cada tiro esta dirigido hacia él. Cada maniobra de equipo esta dirigida hacia él, directa o indirectamente Claro esta, no estamos jugando un partido. Estamos administrando sistemas desarrollados por programadores. En el caso de administración de base de datos, la manera en que el programa solicita las cosas es muy importante. ¿Pero que es lo que sucede entre el programador y el administrador de una base de datos? Mi punto de vista ...

Yo he trabajado un tiempo de programador. Debo hacer mea culpa al decir que no me interesaba mucho las performance de mis programas. Solo me interesaba programar. Esto empezó a cambiar al trabajar con bases de datos. En otras palabras, con volúmenes enormes de datos. Las optimizaciones y las preocupaciones pro-eficacia hicieron su entrada, a través de las quejas o los requerimientos absurdos de los clientes.

El programador inicia un nuevo proyecto con mucha alegría y poco tiempo. Esto evidentemente acabara con cualquier alegría que se pueda tener antes de empezar. "Nuevo proyecto!." dice el ejecutivo. "Nuevo desafío" piensa el programador. "Hay que entregar en una semana." dice el ejecutivo. "Nuevos problemas!" piensa el programador. Pero el programador valiente se despreocupa, y programa como si fuera un mes o más su tiempo limite.

Aquí todo pasa a una segunda etapa. El programador implanta su programa. Lo pone en funcionamiento. Con el tiempo los datos crecen, los requerimientos aumentan por lo que los tiempos de respuesta del programa disminuyen y las quejas se incrementan. "Va lento! Va muy lento! Si andaba rápido! Que paso?" El director dirige quejas como estas al programador. El programador se decide entre un "Te lo dije! Te avise que había que tomarse su tiempo y mejorarlo antes de implementar, a pesar que andaba rápido y bien!" O un tímido "No lo se! Sera la base de datos o sera el hosting el del problema?" A la primera opción, lo mas probable es que tenga que sufrir una discusión elevada de tono donde se discutirá la competencia laboral de programador y del ejecutivo (que yo he sufrido en carne propia como programador). A la segunda opción la culpa recaerá en el administrador. Se aproxima al área! Y tira al arco!. El administrador intenta atajar.

Así habló el maestro programador:
"Aunque un programa sólo tenga tres líneas de largo, algún día tendrá que ser mantenido."

Esta es una gran verdad que muchos directores de proyectos empresariales parecen no comprender. Ok que no lo entiendan. No es su tarea mantener un programa o saber de programación, aunque no les vendría mal tenerlo en cuenta. Digo, para mejorar el estado anímico del programador. Pero lo lamentable no es esto. Muchos programadores nunca piensan en la mantenimiento del programa que crean. Los diseñan para el estado actual de cosas. Nunca piensan en el día de mañana. Esto es lo veradaderamente lamentable ... para el administrador. El administrador termina buscando formas de acelerar todo en lugares que nunca las encontrara. Se debe acelerar el camino y no el auto : nuevas pavimentaciones, nueva señalizaciones, nuevos peatones, etc. Todo para que un Ford-T logre mejores tiempos. O pero, para un conductor que no conoce el acelerador de su propio auto.

Este punto de vista es algo simplista de mi parte, pero es el extremo contrario del hobillo. Para cerrar una reflexión más del Tao :

¿Acaso un buen granjero abandona la cosecha que ha plantado?
¿Acaso un buen maestro pasa por alto aún al más humilde estudiante?
¿Acaso un buen padre permite que uno sólo de sus hijos se muera de hambre?
¿Acaso un buen programador se rehúsa a mantener su código?

Hasta acá el sermón ...