En la mayoría de empresas, los jefes se creen que todo lo que se escribe en un papel (bueno ahora todo lo que figura en un PowerPoint o en una Excel) automáticamente se incorpora a las aplicaciones informáticas.
En el otro lado, tenemos a los programadores que piensan que los ficheros de datos y el mundo real, se congela cuando ellos terminan su aplicación y que no va a cambiar nunca jamás.
En mi empresa de por la mañanas ahora estoy haciendo tareas de parametrización. La parametrización es un gran avance en nuestros sistemas. Todos los datos que se necesitan para que funcionen los programas y que no son fijos, se almacenan en tablas de forma centralizada. Luego cada aplicación accede a ellos. De esta forma el mantenimiento de los datos solo se hace en un sitio y los programadores se olvidan de esta tarea.
Hace unas semanas, se reunieron unos jefes y reorganizaron una parte de nuestra empresa. De aquella reunión, salió una preciosa presentación y una florida hoja de cálculo con modificaciones importantes sobre la estructura de nuestra empresa. Me llegó el material y me puse a modificar la parametrización general para reflejar la nueva realidad. En algunos casos me costó bastante, porque lo que es tan bonito en el PowerPoint, luego no es tan fácil traducirlo a ficheros y registros. Pero bueno, terminamos la tarea y lo grabamos.
Desde ese momento hemos ido teniendo problemas intermitentes en aplicaciones periféricas de los sistemas. Al final, después de mucho investigar hemos encontrado el problema. Tenemos varios programadores, que pensaban que las tablas de parametría eran como las Tablas de los 10 mandamientos de Moisés, que eran inmutables. Así que asumían como verdad absoluta lo que allí había. En lugar de hacer un proceso de carga de parámetros, asumiendo que hoy hay 10 registros estructurados de una forma y mañana puede haber 30 de otra, pues no, el programa siempre esperaba 10 registros.
Así que ahora estoy inmerso en interminables reuniones, para explicarles a todos que si modifiqué la parametría y ahora hay 30 registros, es porque los jefes lo han decidido, no porque me aburriese y me diese por ahí. Y que si no quieren programar mejor, pues que hablen con la Dirección.
Reconozco que en ocasiones, los programadores van siempre cortos de tiempo y de recursos, pero es que hay cosas que son de Perogrullo. Hace unos meses tuve un problema parecido. Teníamos una tabla con un campo código de 4 posiciones. Pero como teníamos pocos registros en esa tabla, los códigos eran de la siguiente forma: 0001, 0002, 0003, hasta el 0052. Esta tabla almacena datos que son externos a nosotros, pero que usan nuestros sistemas. Un buen día, llega un cambio y hay que dar de alta más de 200 nuevos registros; imaginar que paso. Los programadores, truncaban el campo código y lo dejaban de dos posiciones antes de entrar a sus programas. En cuanto aparecieron códigos del tipo 0101, 0102…. Pues aquello dejó de funcionar. Si el campo tiene cuatro posiciones en la tabla, ¿no será porque en algún momento puede necesitarlas todas?.
5 Comentarios
Comentarios Cerrados
Jooooder… lo del “Embrace Change” no lo tienen muy claro tus pragramadores, eh?
Y si a eso le sumas que tenemos: programadores propios, externos residentes, externos de fuera y aplicaciones compradas fuera… pues el cacao maravillao.
¿Y seguis vivos?
Claro, aplicamos como dicen aquí los informes, “las mejores prácticas del sector” porque como todos lo hacen, no podíamos tener un sistema antiguo… y me tengo que callar aquí.
¡Eh!, que lo que nosotros tenemos en la empresa, que es del mismo tipo que la tuya, también son “las mejores prácticas del sector”. Me temo que las mejores prácticas van a ser igual de malas para todos. Después de unos cuantos años como currante-usuario he descubierto que cuando tienes un problema sólo se trata de tener paciencia, unos días mucha, otros días un poquito, y otros días, simplemente, toca decir al cliente que no se puede. Ánimo.