Cuesta Arriba (Montando la Curva de Aprendizaje)

 Una  de las razones por la que los proyectos informáticos fracasan, si bien no la única pero sí una de las principales, está relacionada con la preparación (readiness) de los recursos para concretarlo. Cuando se inicia una búsqueda para armar un equipo de desarrolladores, normalmente se pide conocimiento sobre una plataforma determinada (PowerBuilder, J2EE, .NET) y quizás sobre un tipo de industria (a la cabeza finanzas seguidas por telcos, salud, etc)

Pero el entorno de trabajo implica más cosas: por ejemplo en un determinado proyecto se puede decidir trabajar con Spring, Struts o con la Enterprise Library, ya que contiene facilidades que ahorran tiempo y líneas de código. Alguien se toma el trabajo de considerar ese costo? El de invertir tiempo y recursos para aprender a manejar piezas que luego se desea que nos ahorren tiempo y recursos?

Qué entendemos normalmente por saber un lenguaje? Generalmente aceptamos que alguien sabe un lenguaje si conoce la sintáxis y sus API’s principales. Me atrevo a decir que solemos incurrir en el error de presumir que si alguien sabe eso, no le va a costar aprender otras API’s para ese lenguaje (sean API’s oficiales o API’s de terceros). Y por qué solemos pensar así? Será que interpretamos que si pudo aprender la sintaxis y las API’s que ya sabía… es cuestión de que se ponga las pilas, que estudie API’s nuevas y las va a aprender también

En mi propia experiencia, no siempre me fue bien con la postura positivista de creer que quien conoce un lenguaje aprende todo lo relacionado con ese lenguaje. Hoy por hoy me siento en condiciones de sacar una conclusión acerca de qué debería significar saber, conocer un lenguaje o plataforma

Conocer la sintaxis, conocer sus API’s (la mayoría de las que el arquitecto decida usar en el proyecto) y fundamentalmente conocer las mejores (y también las peores) prácticas

Un buen proceso de búsqueda (hiring) para cubrir una vacante de desarrollador debería someter al aspirante a un examen donde deba demostrar que conoce los riesgos y las fortalezas de los elementos que dice dominar. El proceso debe completarse con un examen psicológico que entre otros aspectos de la personalidad del individuo (trabajo bajo presión, motivación, reacción ante cambios) muestre una capacidad sensata de aprendizaje. Por capacidad digo "que tenga habilidad para aprender". Por sensatez me refiero a que no trate de aprender demasiado más allá de la necesidad que lo llevó a aprender. Para ponerlo en ejemplos: el que cuando tiene que hacer script en una página HTML se estudia todo JavaScript entero "por si hay algo más que nos pueda servir" está haciendo a mi entender un uso ineficiente del tiempo del proyecto

Idealmente, aunque no quiero ser taxativo en esto, el arquitecto especialmente tiene un compromiso de saber sacar valor de las API’s, poder conocer las mejores y peores prácticas. También, nutrirse del feedback de los desarrolladores en cuanto a facilidad de uso (normalmente el "hola mundo" que el arquitecto llegue a probar investigando la documentación de una API va a funcionar sin mayores complejidades, probablemente el ejemplo siguiente también)

Le cabe al arquitecto presentar vagamente las API’s a los desarrolladores, con las recomendaciones de uso que minimice los riesgos. Por poner un ejemplo: le cabe a los desarrolladores entender pormenores de JDBC o ADO.NET pero es labor del arquitecto decidir mantener un pool de conectores a la base de datos para evitar instanciar y establecer conexiones ante cada requerimiento

Es entonces que quiero decir unas palabras respecto de las certificaciones. Hoy los lenguajes nuevos, las plataformas actuales, están en permanente evolución. Java se encuentra en su quinta mayor versión, J2EE en la cuarta aunque cercanos a ver surgir la quinta (en uso, en promedio está en la tercera generación: la versión J2EE 1.3). Cada nueva versión renueva las viejas API’s o bien, cuando los cambios son muy copernicanos, agrega nuevas API’s con funcionalidades similares pero modelo de programación diferente. Por ejemplo al principio sólo estaban los servlets. Luego, como una forma de contrarrestar el golpe del ASP de Microsoft, surgió JSP. Para no enredar mucho el código en JSP, surgió la API de Taglibs. Hoy que Microsoft ofrece ASP.NET, un modelo de programación que supera al viejo ASP pero también a JSP por la alta productividad de ASP.NET en Visual Studio frente a la innegable complejidad de servlets+JSP/Taglib, surge Java Server Faces (JSF), que promueve un modelo basado en componentes, similar al de ASP.NET pero como estándar abierto. En definitiva, en la medida en que J2EE evoluciona se va convirtiendo en un cementerio de API’s

En la orilla de .NET las cosas no son diferentes: Microsoft acaba de anunciar un cambio mayúsculo con la versión 2.0 de .NET, y en unos meses más, con el lanzamiento de Windows Vista, se vienen mayores cambios en la forma de hacer las cosas (servicios web, interfaces de usuario, etc). A quien le interese, he aquí la lista de cosas que funcionan distinto o dejan de funcionar en la versión 2.0 respecto de la 1.1 (breaking changes)

Aunque deseable, no es obligación usar siempre la última versión de las plataformas sino la que resuelva mejor la ecuación costo/beneficio a la hora de responder a las necesidades del negocio. Una de las motivaciones a migrar a versiones noveles tiene que ver con el hecho de que los beneficios de las nuevas versiones normalmente abaratan el mantenimiento post entrega: la etapa más larga de los proyectos. Lo fundamental sigue siendo conocer cuáles son esas novedades que mejorarán el presupuesto (en definitiva, conocer el business value de los adelantos tecnológicos)

En aplicaciones ya en producción, migrar a una versión posterior merece una justificación semejante a la justificación de migrar de una plataforma a otra (sólo que es probable que encontremos más rápido la justificación para migrar a la versión siguiente que, por caso, para migrar de Windows DNA a .NET)

Párrafos más arriba definía que conocer una plataforma era entonces saber no sólo la sintaxis y principales API’s sino deseablemente lo que funciona y lo que no. Qué ofrecen las grandes compañías para garantizar tener la mejor gente en los proyectos de envergadura? Certificaciones

Sun Microsystems tiene un proceso de certificación para cada una de las versiones de sus plataformas J2SE y J2EE. Si hay que mantener un proyecto J2EE 1.2 (aún quedan pocos pero hay), se le puede exigir al aspirante que presente certificación en esa versión del entorno. Las certificaciones de plataforma Java están acá

Por su lado, Microsoft acaba de renovar recientemente su programa de certificación, en una forma tal que las certificaciones previas no interfieran con las nuevas. Se puede tener acceso al detalle del programa de Microsoft y todas sus categorías acá

Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Una respuesta a Cuesta Arriba (Montando la Curva de Aprendizaje)

  1. Unknown dijo:

    Estimado:Me ha parecido muy acertada la descripción de la evolución de las tecnologías y cualidades requeridas en el ámbito de armar un equipo de desarrolladores.Actualmente estoy intentando definir los frameworks y herramientas que se utilizarán en cierta empresa, la cual está recién partiendo con proyectos JEE. Yo anteriormente he utilizado en otros proyectos, Servlet+JSP, Struts, Velocity, EJB2, Hibernate y otras tantas tecnologías, aunque aún no he visto JSF, Tapestry, Spring ni EJB3, entre otras.Quiero usar JKD5, Eclipse+WTP apuntando a servidor Tomcat o si fuera necesario JBoss.Dada la experiencia anterior y viendo algunas tendencias (30+ pags en google), sospecho que para proyectos de tamaño medianos y grandes me convendría JSF para capa de presentación y Spring en vez de usar EJBs, pero al no haberlos utilizado anteriormente aún tengo dudas. Tengo una lista de ventajas/desventajas y varios documentos que sigo leyendo, pero aún no me convenzo. Agradeceré cualquier comentario que pueda encaminarme a decidir de mejor forma.Saludos cordiales

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s