Explicar a veces es difícil

Hoy en el twitter, @lolo_es comentaba lo siguiente: “Lo siento por el que no conoce la sensación de euforia cuando, tras mucho tiempo depurando un trozo de código, ¡funciona!” Nos contaba la alegría que embarga al programador, cuando por fin el programa con el que está trabajando funciona de forma correcta. A mi me pasa lo mismo, la sensación de felicidad, cuando ese programa hace lo que debe, es algo impagable.

Pero en ocasiones, esa alegría dura poco. Puesto que una vez que el programa funciona, pues hay que hacer más cosas. Estos días he estado yo peleándome con un problema parecido. Tuve que escribir código, pero no mucho. Realmente necesitaba un procedimiento y una forma de obtener una respuesta con un montón de datos que no la mostraban de forma clara.

En mi empresa de por las mañanas, estamos otra vez de movida. Cambiando de host, en pleno proceso de conversión. Y para ajustar la migración de una aplicación debíamos obtener una información, que no estaba así almacenada en nuestros sistemas. Así que había que tratar de con los datos que teníamos conseguir una respuesta. Como siempre los programadores de una externa llevaban unas semanas con la tarea. Pero los resultados que nos mostraban no parecían correctos. El problema era que la pregunta que parecía muy sencilla era realmente complicada. Y más que conocimientos de programación y de bases de datos, requería saber como introducían los usuarios la información en el sistema y entender realmente que queríamos convertir. Como se acercaba la fecha de cumplimiento de plazo de la tarea, mi jefe me dijo si podía ayudar. Yo no tengo acceso directo a los datos del host, pero resulta que he tenido muchos años de experiencia en el proceso que se estaba analizando, tanto por haber sido usuario, analista y probador. Así que me puse con mi juego de herramientas digitales de la Señorita Pepis: ficheros planos del host, una Excel, y un Access. Y me costó conseguir un resultado. Y lo peor, no era ya llegar a un resultado, sino además hacer una batería de pruebas, que nos permitiese validar que los datos eran buenos. Era un información que nunca se había sacado (ni se sacará, solo se necesita para esta migración) y no teníamos donde comparar.

Pero como decía al principio, tras la alegría de conseguir un resultado, vino la tristeza de tratar de explicar. Me puse a explorar con los datos y la solución fue muy heterodoxa. Y me costó casi más explicar a mis superiores como había llegado a ella y además explicar que los datos eran buenos. Lo malo es que mis jefes y compañeros son informáticos de carrera, y yo soy más un analista que los azares corporativos han dejado entre ellos. A lo que iba, ellos esperaban una bonita sentencia SQL con unas tablas relacionadas que se pudiesen consultar. Y en su lugar yo venía con dos módulos Access, y una varias macros en Excel. Y al final como prueba de la bondad de mis resultados, consultas directas a resultados de programas en real. Me sentí como Edison en la anécdota del cálculo del volumen de la bombilla. Edison quería saber el volumen de aire que había en un modelo de bombilla. Así que puso a un matemático a trabajar en al tarea. Pero éste tardaba en darle una respuesta. Así que Edison fue a lo rápido, llenó la bombilla de agua y midió el volumen de forma experimental. Y algo parecido había hecho yo con el problema que mis jefes me habían encargado.

Menos mal que al final entendieron mi razonamiento.