Si hay algo que desde hace años vengo notando en el mundo de la programación, es que cada vez es más y más difícil encontrar documentación de Calidad.
Hace unos años, cuando uno quería empezar con algún nuevo lenguaje de programación, a poco que tuviese un mínimo de interés era más o menos sencillo encontrar documentación, tutoriales, ejemplos y todo lo que un desarrollador podía necesitar para dar sus primeros pasos para luego pasar a crear sistemas cada vez más complejos.
Así, en su día empecé con PowerBuilder en entornos Cliente-Servidor, con Pro-C o el JAVA con el que llevo desde hace más de 10 años, partiendo de manuales y tutoriales que intentaban guiarte en el proceso del desarrollo de software.
La Evolución.
Pero a medida que pasan los años, el Software evoluciona, se van creando nuevos y más potentes Frameworks de desarrollo, que a su vez te obligan a tomarte más tiempo para dominarlos e integrarlos en tus proyectos.
Uno podría pensar que la documentación también se va volviendo más compleja y te obliga a dedicar más tiempo a esos primeros pasos, pero con la posterior recompensa de obtener mejores aplicaciones o tiempos de desarrollo más cortos.
Pero lo cierto es que no siempre es así, puesto que el esfuerzo dedicado a crear esos más completos y complejos Frameworks de desarrollo se han llevado por delante las fuerzas para algo que cada vez se hace más necesario: DOCUMENTAR.
Pasando de proyectos y Frameworks donde la documentación te valía para empezar y perfeccionar tus conocimientos, a proyectos donde lo habitual es encontramos el típico 'Hola Mundo', que es tan absurdo como inútil cuando de lo que se trata es de construir grandes sistemas.
Objetivo: Productividad.
AJAX, JSON, HTML5, MVC, JPA... todo esto e incluso más vienen a ser el día a día en el desarrollo de Webs Dinámicas, con RIAs complejas y potentes, donde todo se ha complicado a cambio de asegurarnos una alta productividad.
O al menos así debería ser, porque la triste realidad es que encontrar documentación de calidad que enseñe cómo integrar las distintas tecnologías de hoy, cómo resolver los problemas diversos que uno puede encontrarse en esa integración, se ha convertido en un ejercicio similar a la pesca... solo que hemos cambiado nuestro río o lago favorito por Google, y nuestro cebo por esas palabras clave que nos han de ayudar a discenir las soluciones del resto de miles de desarrolladores que también se ahogan en los mismos problemas que nosotros.
 |
| Tienes suerte si das con tu solución en el vasto mar de los resultados de Google. |
Y todo porque las mismas personas que son capaces de retorcer las líneas de código para domarlas y crear estos frameworks de alta productividad, adolecen de interés, capacidad o las dotes pedagógicas necesarias para sentarse delante de un procesador de textos y escribir una guía que explique algo más que el
Así que lo que debería ser un alto esfuerzo inicial para convertirse en bajos tiempos de desarrollo, termina siendo un ENORME Y FRUSTRANTE esfuerzo de días y semanas para no solo pensar en cómo crear aplicaciones de verdad, sino para resolver los mil y un problemas que nos podemos encontrar hasta empezar a entender cómo usar realmente las cosas.
Pero bueno, si estuviésemos hablando de Proyectos Open Source, realizados por chavales recién licenciados con ganas de escribir líneas y líneas de código, pero no de explicar lo que hacen, uno hasta podría entenderlo.
Pero cuando uno se tiene que enfrentar a Frameworks respaldados por gente que se presupone seria y con recursos, dotados para hacer bien las cosas, se enfrenta a esa ENORME FRUSTRACIÓN, es cuando me empiezo a preguntar: ¿Pero qué coño está pasando?
Y en este caso me refiero a ni más ni menos que a Google y su GWT, y Spring Roo de SpringSource, que no son precisamente poca cosa.
El Camino a la Frustración.
Hace dos semanas y con el objetivo de decidir qué tecnología usar para un pequeño desarrollo web en el trabajo, tras estar buscando posibles opciones y teniendo muchas ganas de desarrollar algo con GWT, llegué hasta esta página:
Rapid Application Development for the Cloud
Uno lee el título, el encabezado y comienza a leer el 'tutorial', y empieza a pensar que ha encontrado lo que necesitaba.
Y con ese objetivo me descargo el entorno de desarrollo de Spring STS, el pdf 'Getting Started with Roo', dispuesto a confiar en estas 2 grandes empresas y dedicar mi tiempo a saber cómo crear un proyecto con estas herramientas.
Pues estas dos semanas se pueden resumir en: rabia, una gran frustración y sensación de tiempo perdido.
El entorno es bueno, Spring Roo es una gran idea, GWT un gran Framework para RIA... pero, la documentación ES PENOSA.
El libro de Roo está desactualizado, escrito para la versión 1.5.5 cuando ya se ha publicado la versión 1.2.0, algo que se podría pasar por alto si no fuese por los errores que te encuentras al seguir los ejemplos.
 | |
| ¿Y por qué a mi no me funciona? ¿Qué he hecho mal? |
Primero por estar detrás de un proxy, lo que por algún motivo hacía que los drivers para la conexión JDBC no se instalasen aunque la aplicación dijese que todo había ido bien.
Luego porque te vas encontrando con errores surgidos no se sabe muy bien de dónde, que te obligan a perder mucho tiempo en buscar soluciones por los foros.
Soluciones que muchas veces no encuentras y solo consigues 'resolver' por el método de 'borrar proyecto' - 'crear nuevo proyecto'.
Y el último porque cuando intentas generar tu primera aplicación con GWT + Spring Roo, lo que se supone que son apenas 4 líneas en la shell de Roo para tener una aplicación, se convierte en un...
'¿Y AHORA POR QUÉ COÑO FALLA?'
Mas un sinfín de errores inexplicables, cuando se supone que tras compilar todo ha ido bien y debería de ejecutarse sin problemas:
 |
| Resultado tras seguir los pasos indicados en el libro 'Getting Started with Roo'. Aquí estuve a punto de echarme a llorar. |
La Resaca.
Y en ese punto estoy, en el de decidir si darle una oportunidad más, dedicar uno o dos días más a averiguar porqué demonios falla, o decantarme por otras opciones más sencillas.
Si ahora mismo me preguntasen...
¿Lo recomiendas para que lo use la gente a tu cargo?
Mi respuesta sería un rotundo: NO.
No porque no sean buenos productos, no porque no sean potentes, no porque no se pueda terminar obteniendo una alta productividad... si no porque cuando las fechas son cortas, cuando el soporte no va más allá de un triste tutorial de una página o un libro incompleto y lleno de errores, o un foro donde nadie te asegura que vayas a obtener una respuesta... con el presupuesto en la mano debería dejar de lado estos productos hasta que o bien se mejore su documentación, o bien funcionen como se espera de ellos.
De momento voy a darles uno o dos días más de margen, pero si los problemas persisten habrá llegado el momento de darlos de lado hasta que alguien en Google o en Spring se de cuenta de que tan importante como hacer que las cosas funcionen, es hacer que la documentación sera seria y completa.
Reflexión.
Creo que la conclusión es obvia, cuando grandes como Google y Spring fallan en algo tan importante como proporcionar una buena, completa y actualizada documentación... ¿qué no estaremos haciendo mal los demás?
Quizás sean las prisas, la falta de tiempo o simple dejadez, pero basta con buscar por internet distintos tutoriales para encontrar escuetos artículos donde apenas se profundiza en el tema.
Pero, ¿alguien cree que JAVA hubiese llegado a ser lo que es hoy si SUN no hubiese entregado un completo API con cada Release? ¿o si no hubiese llenado su web de ejemplos sobre cómo desarrollar aplicaciones de escritorio con Swing o cómo construir aplicaciones web?
Desafortunadamente esos tiempos parecen haberse ido para siempre, dejando tiempo a un momento en el que todo son prisas y es más importante ir entregando nuevas versiones antes que explicar bien a quien quiera usarlas cómo puede hacerlo.
Estamos convirtiendo el Arte del Software, el trabajo del Maestro Artesano, en el trabajo de una cadena de producción donde lo que importa no es entender qué haces, si no aprender qué botones hay que pulsar en cada momento.
