Versiones preliminares

En algunos desarrollos por cuestiones de diseño, de funcionalidad, de innovación o simplemente por ser demasiado aventureros, nos enfrentamos a la difícil elección de trabajar con versiones preliminares de una determinada tecnología. ¿Qué inconvenientes puede llegar a plantear esto? ¿Es factible afrontar dicha operación? En definitiva, ¿debemos correr el riesgo de usarla?

En este caso, con preliminar me refiero a que aún no disponemos de la versión 1 de dicho software. En estas condiciones nos enfrentamos a que dicha tecnología está demasiado verde y aún le faltan muchas cuestiones por resolver. En el caso de Java, puede que la API a utilizar no esté aún demasiado pensada, y esta podría sufrir cambios muy significativos antes de alcanzar la versión 1 oficial. Lo que nos desembocaría en cambios en las clases y métodos utilizados por que estos han desaparecido.

En algunas ocasiones se tiene tendencia a respetar versiones anteriores, sin embargo no habiendo alcanzado la versión primera, aún podrían existir muchos movimientos e incluso cambios bastante sustanciales, en arquitectura, diseño, etc. Si estás cerca de una release candidate esto podría cambiar, puesto que al estar cerca de la versión 1, es posible que las decisiones estén más que tomadas y los diseños muy aceptados. Sin embargo si te encontrases en una 0.5, por ejemplo, podría ser que la forma de hacer las cosas variase mucho antes de llegar a la 1.0.

En estos casos, lo más preocupante para el programador, no es que va a pasar, sino como resolver el día a día con dicha tecnología. Es muy importante, no sólo el hecho de disponer de una tecnología, sino poder utilizarla. Para esto nos solemos apoyar principalmente en artículos, tutoriales, libros, etc. Y para resolver problemas concretos en foros, listas de correo, etc. Sin embargo imagina que no existen libros de dicha API o de dicho software. Imagina que los tutoriales aún no existen, porque la tecnología lleva poco tiempo, y los que mejor la conocen son sus propios desarrolladores, que áun no han tenido tiempo para generar un tutorial, a sabiendas de que todo está aún muy en pañales. Y si tienes más imaginación, piensa que para ponerte en marcha tu único punto de partida podría ser un artículo que podría estar desfasado dada la velocidad de cambio en el desarrollo. Por otro lado, es posible que en los foros cuando busques solución a algún que otro problema, encuentres que las fechas de publicación de las dudas, no tienen ni un mes de antiguedad y que algunas resoluciones pasan por cambios o corrección de errores dentro de los desarrolladores de la librería.

Además de la consabida cuestión de la elección, podría suceder un desastre aún mayor dado que dicho desarrollo podría no terminar nunca, por motivos varios, tales como: falta de desarrolladores, desinterés del público en general, etc. O incluso como ha pasado en algunos casos curiosos, que el propio desarrollo se ha liado tanto que nunca parecen llegar a la primera versión. En este caso juega un papel fundamental que detrás se encuentre una asociación, organización o X de la cual podamos tener certeza de que van a responder bien. Por ejemplo, no es lo mismo que esto suceda con un software desarrollado por el equipo de gente que forman Apache, que sea un software que se encuentre en SourceForge. Del primero tenemos una cierta certeza de que no se nos va a defraudar, por tener detras a más gente de la que realmente está desarrollando; en cierto momento podrían hacerse cargo del desarrollo otras personas, para no abandonar el desarrollo. Sin embargo en el caso de alguien que haya creado un proyecto en SourceForge, apenas tenemos certezas de nada, para confiar en ellos, necesitaríamos ver que tienen detrás a un equipo humano más amplio, que están trabajando intensamente en el desarrollo. Nuestra elección también puede venir por la obligación de tener que usar dicho software, porque no nos quede más remedio, aunque esto estaría por ver.

La conclusión es que para adaptarse a una tecnología en estas condiciones uno debe confiar mucho en su instinto, en las ventajas que dicha tecnología plantearía para el equipo de desarrollo, en los motivos por los cuales es una buena decisión y debe ser capaz de hacer un análisis de su viabilidad, para si merece la pena apostar por ella o no. En definitiva, debe evaluar los posibles daños y perjuicios que podrían causar en el proyecto y si existiría una gran problemática para sustituirla a futuro.