Trabajar como programador. Viviendo en medio de la presión y los plazos imposibles.

Por descargarpseint / hace 5 meses / 0 Comentarios ».

Hola estimado lector. Ha sido una semana francamente dura donde he sufrido en todo mi cuerpo la dureza de trabajar como programador. Siempre se aprende una lección de los momentos complicados y la mía ha sido que la presión y los plazos imposibles se vencen adquiriendo una visión mucho mas pragmática de la profesión  y aceptando que cuando recibes un salario tienes que aprender a aceptar que la opinión de quien te paga es la que prevalece aunque no siempre sea la mas correcta.

Hace unas semanas os presenté mi primera reflexión sobre la profesión de programador/analista/consultor java y también sobre la mejor forma de aprender los fundamentos del lenguaje.

Allí realicé una defensa del programador que programa frente a aquel que se dedica a copiar y pegar. Justamente hace un par de días surgió un momento límite dentro de los desarrollos y entregas que llevamos entre manos en mi trabajo actual. Estábamos a cinco jornadas laborales de unas pruebas de aceptación donde el cliente quería ver una versión estable y funcional del producto a entregar.

Este proyecto estaba compuesto por dos partes, una basada en procesos pesados que se ejecutan periódicamente y cuya función es la realizar procesos intensivos (por ejemplo firmar 30000 facturas). Otro de estos procesos tenía como finalidad generar un PDF a partir de un conjunto de estas facturas para ofrecer al usuario una versión imprimible múltiple.

La segunda parte del proyecto consistía en el desarrollo de una pequeña aplicación web donde el usuario tendría opción de recuperar facturas y también imprimirlas en formato PDF. Idealmente este modulo se iba a desarrollar rápido gracias a que estaba basado en un Framework propietario pensado para este tipo de desarrollos.

Nuestro jefe viendo que los tiempos iban ajustados tomó la decisión de incorporar a una persona que me ayudara en el desarrollo de esta segunda parte. Así que cada uno comenzó a desarrollar su parte, compartiendo información sobre aquellos aspectos (tablas de base de datos, básicamente) que fueran relevantes para ambas partes.

Hasta aquí todo bien pero entonces esta persona termino su desarrollo (quedando pendiente la impresión en PDF) y comenzó a disfrutar de sus merecidas vacaciones. La idea era que pudiéramos dar soporte a su parte si surgía algún contratiempo.

Mientras tanto yo iba desarrollando mi parte, paso a paso, y puse todo mi empeño en desarrollar una arquitectura java basada en Spring, utilizando su integración con JDBC (Java Database Connectivity) JdbcTemplate. Además realicé un proceso de reutilización de código que a hacer posible que mis servicios de Spring fueran capaces de imprimir facturas en PDF a partir de una plantilla desarrollada en JasperReports, allá por el 2005 y por otra empresa.

Este proceso de adaptación supuso tiempo de inversión que desde el punto de vista de mi empresa eran costes para el proyecto. Esta claro que la visión de un programador y experto en tecnología es muy diferente a la de un gestor experto en cuadrar las finanzas. Sin embargo, aquí también discrepo con la forma de medir el coste. Incluso aquí son cortoplacistas y solo miden el coste directo (en jornadas) de hacer un desarrollo. En cambio, a futuro no le añaden los costes derivados de tomar malas decisiones de diseño y programación.

Con esta presión añadida por los tiempos nos presentamos en esta fecha y quedaba implementar un servicio que imprimiera facturas a petición del usuario desde el portal web. Mi jefe me planteó a las 14:00 (hora de España) que teníamos que cerrar ese desarrollo y probar el resto de módulos ese mismo día como fecha límite.  Así que nos pusimos manos a la obra buscando la solución mas rápida.

Opción 1: Hacer uso de mi servicio de impresión.

Esta posibilidad requería importar una librería jar dentro del proyecto web, añadir el servicio de impresión como un bean de spring (el portal web también utilizaba Spring Framework) y realizar algunos ajustes para que un servicio pensado para generar un PDF y dejarlo en un directorio del sistema operativo se convirtiera en un servicio capaz de integrar el mismo PDF como adjunto en la respuesta HTML en el navegador web.

Opción 2: Utilizar el código original heredado del 2005.

Aquí se contemplaba copiar la clase encargada de generar el PDF del proyecto del 2005 y pegarla en el nuevo. A partir de aquí ir añadiendo las clases necesarias hasta que el código compilara. Y me refiero a traer clases java desde un proyecto Web desarrollado con Struts1 + EJB2  + JDBC a otro proyecto web mucho mas moderno que utilizaba ExJs + Spring + IBatis. (En futuros manuales os iré hablando de todas estas tecnologías)

¿Qué opción piensas que terminamos utilizando?.

Si ya llevas años trabajando bajo presión imagino que habrás acertado la respuesta. Si estás empezando, esta experiencia que te estoy contando te puede servir para que vayas entrenando a tu cabeza a situaciones reales a las que te vas a enfrentar y que no se suelen comentar ni en la universidad, ni en los libros ni tampoco en otro tipo de cursos.

La opción elegida fue la segunda, la situación crítica nos hacia actuar sin pensar. Así nuestros superiores estaban mas tranquilos. Mentalidad muy Española, si trabajas muchas horas y haces muchas cosas entonces tu salario es justo. En cambio, si reflexionas y te tomas tu tiempo para buscar una solución optima, te argumentan que el cliente no ha pagado eso sino una respuesta lo mas rápida posible.

En total han supuesto unas 12 horas adicionales de 2 personas (24 horas en total). Esto para integrar un informe de JasperReport en una aplicación web. (Un informe que ya estaba diseñado).

¿Qué habría ocurrido si me hubieran permitido poner en práctica la primera solución?.

No lo sabemos a ciencia cierta pero tres jornadas es lo que me costó integrar el código ya desarrollado dentro de mi servicio de impresión, incluyendo pruebas de integración. Probablemente en unas 10 horas lo podría haber tenido listo y sobre todo tendríamos un desarrollo fácil de mantener y no como ahora que tenemos un código puesto con pinzas que al mas mínimo cambio supondrá un coste adicional.

¿Quién asumirá este coste?.

Por ahora nadie lo sabe pero lo que es seguro es que habrá un programador que verá ese código y se preguntará como se pudo hacer de esa manera. La respuesta que he encontrado es que el código que se programa a las 10 de la noche, tras llevar 14 horas programando difícilmente podrá cumplir los estándares de calidad deseables.

Otra cosa que he comprendido a la perfección es que el pragmatismo es imprescindible en estos casos. Trabajar como programador tiene un coste emocional derivado de la presión e incomprensión, en algunas ocasiones, que exige desarrollar una inteligencia emocional que nos permita afrontar situaciones límite con confianza en intentando mantener los pies firmes ante las sacudidas de la inmediatez.

Ver: Pseint aprender a programar

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *