20.2.13

Es un dato del problema

He decidido empezar este blog con una pequeña anécdota, ya que muchas de las soluciones que veáis por aquí, lo que hacen en realidad es sortear un problema de diseño en el software, o forzar una herramienta para que pueda ser utilizada en un caso de uso nada recomendable. O puede que cosas peores, que os hagan llevar las manos a la cabeza y decir «es que aquí hay un problema de base; habría que rehacerlo todo». Bueno, bienvenidos al mundo real. En ocasiones tenemos que tratar con código heredado que nadie quiere tirar, con imposiciones técnicas por decisiones no técnicas, o simplemente con una fecha tan ajustada que sólo da tiempo a parchear algo de mala manera. Es lo que yo llamo «un dato del problema».

En realidad, el término no es creación mía sino que viene del jefe de proyecto que tuve en mi primer trabajo. Corría el año 1998, y debíamos realizar varias aplicaciones web para un nuevo operador de telefonía. A saber, una intranet para su personal, una extranet para sus distribuidores, y la web corporativa. Las aplicaciones debían correr sobre Java, pero además había una condición por parte del cliente, que nos resultó extraña: El desarrollo debía realizarse con una herramienta llamada NetDynamics, recién adquirida por Sun Microsystems. Cuando preguntamos por qué, teniendo en cuenta la filosofía de Java «write once, run anywhere», y que debería dar igual qué IDE o plataforma usáramos, nuestro jefe de proyecto nos dijo «porque es un dato del problema». Ante nuestras caras de interrogación, nos hizo recordar cómo eran los problemas de matemáticas o física que nos ponían en el colegio. A veces, había partes del enunciado que no sabías muy bien para qué te servían, pero que tenías que meterlas como sea, porque eran un dato del problema. Y si no las usabas, seguro que el profesor te lo calificaba como incorrecto. Esto era lo mismo.

Nuestra experiencia no fue agradable. Pese a que el planteamiento era bueno (no existían en aquel entonces las JSPs, y con esta plataforma podíamos escribir páginas HTML con etiquetas especiales que renderizaban el valor de parámetros de la request o la sesión), la herramienta estaba inmadura, y encontramos algún bug grave. Como además éramos unos novatos imberbes, tardábamos muchísimo en identificar los bugs de NetDynamics como tales, pensando que era culpa nuestra por no saber usar la herramienta. El desarrollo se retrasó una barbaridad, trabajamos día y noche, se crisparon los ánimos... En fin, supongo que algunos habréis pasado por situaciones similares.

A lo largo de mi carrera profesional, me he encontrado con situaciones parecidas (aunque nunca con desenlaces tan desastrosos). Decisiones inamovibles que condicionan el desarrollo del proyecto, sin posibilidad de valorar otras opciones. Lo que desde entonces he llamado, «un dato del problema».

No hay comentarios:

Publicar un comentario