No todo tiene igual riesgo

Mucho se habla de gestión de riesgos, ya sea en metodologías ágiles como en, cof cof, waterfall, y claro, mucho se colocan tablas y con una mayor o menor pericia se indican los impactos y probabilidades respectivas, hasta ahí “lo normal”.

Lo usual es que por lo usual los criterios de experiencia que se toman están basados en el tipo de proyecto: ERP, almacén, web o desktop o también en el grado de complejidad del negocio, estado de las relaciones con el cliente, primera vez, time to market etc, nada fuera de lo habitual.

El problema es que muchas veces la visión “de negocio” logra opacar al criterio técnico en un factor muy importante: no todas las tecnologías tienen igual riesgo, y no, no me refiero al hecho de que por ejemplo un consultor de SAP cobre mas que un diseñador gráfico (llevándolo a extremos), sino que las diversas tecnologías tienen diferentes niveles de disponibilidad de recursos de aprendizaje, lo cual quieras que no, impacta en las previsiones que se requieren tomar para un proyecto.

En algunos casos es evidente que hay muchos mas recursos (ojo, en este blog nunca hablamos de personas como “recursos”, ¿ok?) para SQL Server y Oracle que para Informix o Sybase, por lo cual el tiempo en que un equipo puede llegar a ser productivo en un proyecto con estas dos tecnologías “raras” es mayor, pero mal que bien se puede solventar con la experiencia previa en otros motores de base de datos, así que tenemos un riesgo ligeramente mayor, pero justificable.

Visto a este contexto debemos pasar a un diferente tipo de escenario, los frameworks o soluciones “listas para usar”, productos que se espera que puedan ser usados directamente por un usuario final, “casi” sin necesidad de desarrollo, pero claro eventualmente terminan pidiendose personalizaciones y como la aplicación tiene una API en un lenguaje “conocido” como PHP, C# o Java pues se empieza el desarrollo tomando los mismo criterios que cualquier otro proyecto a medida y .. ahi empiezan los problemas.

En concreto estas aplicaciones (concretamente los CMS que son con los que he tenido experiencia) presentan dos problemas que los hacen “bestias” diferentes a cualquier desarrollo a medida:

  1. Esfuerzo extra para configurar los entornos, tanto de desarrollo, como de producción, en el caso de SharePoint por ejemplo era muy complicado, tan así que no se podía trabajar contra un servidor compartido sino que cada desarrollador debía de tener una Maquina Virtual para tener un entorno de trabajo, todo lo cual involucraba un esfuerzo que no era trivial.
  2. Cambio de paradigma respecto a como desarrollar y/o depurar, pues aquí no eres tu desarrollando una aplicación, estas intentando construir algo sobre los cimientos que alguien mas hizo, y que le puso reglas que pueden ser no usuales (y sobre todo contraintuitivas), pero necesarias para que el producto funcione, lo cual deriva en una necesidad de conocimiento (y tiempo de aprendizaje) mas allá de cuan experto uno crea ser en el lenguaje en cuestión.

Queda claro que estos dos factores tienen alta probabilidad de incidir sobre el tiempo que le puede tomar al equipo implementar la solución, por lo que seria un grave error asumir proyecciones sin tomar en cuenta el esfuerzo extra mencionado, si, es difícil acometer estas cosas que nos dejan productos como Magnolia, Vignette, o SharePoint, pero al final son retos técnicos que terminan siendo superados, a menos claro que la dirección asuma que “.net es .net” y no tome en cuenta detalles como estos en sus proyecciones, ahora que si a estas dos cosas, se le suma la poca experiencia local, o poca documentación actualizada en foros, asumimos grandes riesgos que no podemos dejar de informar de antemano, y créanme, en el caso de CMS (salvo que tengas miembros del equipo que actúen como pilares del resto) siempre pasa algo de lo mencionado, por lo que debemos estar alertas, regresando al titulo de este post, no todo tiene igual riesgo (técnico).

Lo tenia delante pero no sabia decir porque no me gustaba: Java

Cuando uno llega a una situacion u opinion es porque ha recorrido un camino previo, nadie te ha teletransportado ahi, solo que a veces nos olvidamos de dicho camino.

Concretamente debo referirme a la predileccion como desarrollador que tengo para con la plataforma .Net, el porque termine ahi y lo prefiero frente a Java … tiene su historia.

Luego del paso obligatorio por Pascal, C/C++, COBOL tocaba enfrentarse a las herramientas de desarrollo “real”, con la que se hacian las cosas en las empresas, y sobre todo, las que permitian desarrollar para Windows. Tuve ocasion de hacer un curso de Gupta SQL Windows, el cual me dejo un mal sabor de boca.

Es por esa epoca que tambien me expongo ante Visual Basic 4/3, se comenta algo sobre Java, pero aun no recuerdo el como y porque (creo que lo que lei por ahi) termino en mi casa haciendo experimentos con Borland Delphi 1 y fue quedar seducido por la propuesta hecha: un poderoso lenguaje Orientado a Objetos, con una interfaz que cogia lo mejor de los conceptos drag and drop popularizados por Visual Basic.

Pero claro, lamentablemente en Peru Delphi era un lenguaje casi de “culto”, por lo que urgia revisar las cosas que iban apareciendo en el mercado y una de esas cosas fue algo que me comentaron a poco de terminar mi primera Feria del Hogar: un lenguaje llamado Java el cual prometia traer la interaccion a la web mediante los llamados “applets”, propuesta interesante la verdad, el caso es que no me pude poner a probar Java sino hasta el 97 en que pude instalar Windows 95, esto debido a que no habia opciones para correr Java en W3.11 como no sea mediante el proyecto ADK que no se en que habra terminado.

Intente darle su espacio a Java, pero entonces me topaba con unos problemas que para entonces eran criticos:
– Ausencia de un IDE lo suficientemente rapido, aun el Borland JBuilder era muy lento, siendo que aun VB (5 para entonces) era mucho mas rapido y ni que hablar de Delphi (3 y 4).
– No continuidad en el modelo de presentacion grafica, de un momento a otro se decidio que las AWT debian dar paso al modelo Swing.

El lenguaje en si no daba muchos problemas (regresaremos a esto), pues ya contaba con la base de saber C/C++, pero lamentablemente costaba mucho ser productivo, siendo que con Delphi implementar algo era relativamente simple (pero no tan innecesariamente simple como con VB). Tambien es conviente notar que como el enfoque era hacia dar “dinamismo” a la web, surgieron herramientas que proponian alejarte del codigo para generar applets (semi prefabricados) de manera mas agil, hablo de Kinetix y Jamba. Y claro, por otro lado teniamos a Kawa, que fundamentalmente era un gestor de proyectos que tras bastidores llamaba por linea de comandos al JDK.

Es asi que me volvi en uno de los pocos defensores de Delphi en Lima de esa epoca, hice experimentos con las opciones de desarrollar paginas con ISAPI, controles ActiveX incrustados, desarrollo en 3 capas mediante Midas, y claro un buen rato metido en el newsgroup non-technical de Borland asi como en ClubDelphi, circunstancias que me llevaron a conocer a Claudio Briceño (responsable comercial de Borland para Latinomaerica) quien me vino a visitar a mi trabajo de entonces, lo cual luego conduciria (gracias a la posterior coordinacion de un comunidad de Linux en el Peru) a la posterior presentacion de John Kaster en el Hotel Los Delfines para presentar los avances que hacia Borland en desarrollar Kylix un entorno Delphi para Linux, y si, ahi estoy yo… :

Luego me tocaria cenar tanto con Claudio y John a la espera de posteriores acciones que permitieran potenciar la presencia de Delphi en el mercado peruano, lo cual no logro a materializarse.

En esas circunstancias, veo que las cosas cambian, nadie habla de applets, todo se orienta hacia los servlets, y a los EJB, les doy una revision… nuevamente, cuesta hacer algo simple de manera rapida, se nos habla de que ya saldran los JSP….. Lo interesante es que a pesar de esas limitaciones Java estaba cogiendo un mayor arrastre, el cambio de lo “visual” hacia los modelos de componentes orientados a servidor habian probado ser buenos para la estrategia de Sun, ya que habia una demanda en el mercado por una solucion no atada a Microsoft, mas orientada a objetos y que fuera robusta, en ese sentido los Application Server lanzados por diversos fabricantes permitieron consolidar su posicion en el mundo corporativo.

Es en esas circunstancias que (me)ocurrieron varios eventos de manera casi consecutiva, Microsoft anuncia .NET prometiendo una plataforma totalmente Orientada a Objetos(*), soy admitido en una beca de Microsoft para estudiar VS 6 y ceso en mi trabajo de entonces.

Estudiar lo que ofrecia VS (VB + Interdev fundamentalmente) me hace ver ciertos detalles que no eran tan claros para mi, era perfectamente viable construir aplicaciones robustas con esas herramientas, pero que muchas veces la simplicidad te conducia a errores de diseño que penalizaban la performance y la mantenibilidad, siendo necesario un conocimiento serio de la arquitectura detras (algo en lo que los cursos de Certificacion enfatizaban bastante).

A pesar de haber “cambiado” de herramienta por razones de mercado, sabia que esto era algo transitorio, pues veia la fuerza que iba a arrastrar el lanzamiento de .NET, producto al que recibia con expectativas positivas debido a que el cerebro detras de esto era nada menos que Anders Hejlsberg quien habia sido arquitecto de Delphi en sus dos primeras versiones, del cual solo podria esperar que introdujera en la nueva plataforma la evolucion de las innovaciones que habian sido introducidas originalmente en Delphi.

(Para ese entonces Borland libera Kylix, el cual debo decir que nunca use)

Obviamente que apenas pude me consegui una de las primeras Beta de Visual Studio .NET, aparatoso como buena beta, ya dejaba ver que habia asumido totalmente el modelo de objetos, y por todas partes se notan los guiños a Delphi, especialmente en C# en el tema de la gestion de eventos, comprendi entonces que me encontraba ante una herramienta potente y sobre todo que introducia la programacion RAD y orientada a eventos al desarrollo Web, algo tan simple y a la vez potente era algo por lo que los desarrolladores habiamos estado esperando buen tiempo. Pero lo mas importante era que todo lo aprendido sobre OOP en Delphi se aplicaba directamente en la nueva plataforma, y a estas alturas creo que mi transicion fue mucho mas simple que si hubiera venido solo procedente de VB6, lenguaje que con todo lo flexible que era, te enmascaraba muchos detalles los cuales no te permitian una total potencia en el desarrollo.

Para cuando llegue a España ya habia experimentado con la Beta 2 (y una pre-Beta2 no lanzada masivamente pero que me fue facilitada en Microsoft Peru), por lo que seria cuestion de tiempo que me terminara involucrando en proyectos de .NET como ha sido hasta la fecha, incluyendo examenes de certificacion en el interin.

Han pasado los años y es gracias a CampusMVP que me entero de unos articulos de Ian Marteens(al cual ya habia leido por 1999) en los que se hacen interesantes comparativas entre Java y C#, enterandome de que la implementacion de los Generics en C# es mejor que en Java, pero confirmando algo que ya habia intuido en mis primeras peleas con Java: su implementacion de eventos es penosa, ya que como el mismo Marteens dice “Los diseñadores de Java eran personajes que odiaban los punteros, y nunca hubiesen aceptado implementar los eventos al estilo Delphi. De hecho, ni siquiera tuvieron en cuenta el soporte para eventos cuando crearon Java”. No vieran el alivio que tuve al leer esto, durante mucho tiempo creia que era yo quien podria estar haciendo algo mal cuando trate de implementar cosas en Java, pero como se puede ver en esta serie de articulos, hay errores (llamalos caracteristicas si quieres) en la implementacion del lenguaje, y era algo que alguien que provenia del entorno Delphi podia intuir, pero es bueno saber que hay bases formales para entender las ventajas de un lenguaje (lenguaje, no plataforma, esa es otra guerra) sobre otro.

Como digo, es un camino el que me ha traido hasta aqui y ese camino empezo con la experimentacion de Delphi, herramienta que a pesar de no trabajar con ella en años, no puedo sino recordar con cariño y agradecimiento por las bases que me dejo.

(*)Recordemos los fuertes ataques que recibia VB por no incluir algo tan simple como la herencia.

¿Un MUG sin Microsoft?

MUG: Microsoft Users Group o MSDN Users Group, siglas de significado claro, y es el usado por varias comunidades de usuarios de los productos Microsoft en varias partes del mundo.

En un momento dado Microsoft trato de potenciar las comunidades dentro de las universidades, con resultados dispares, luego el medio de comunicacion resultaron siendo los lanzamientos de productos y por supuesto los esperados Developer Days, en ese interin se tuvo una lista de interes llamada MUG que corria en los servidores de Unired, para luego pasarnos a la lista MSDN esta vez en los servidores de la RCP, de toda esa etapa recuerdo la presencia activa de representantes de Microsoft como Eduardo Saldarriaga, Jorge Oblitas, Fernando Covecino y Sergio Vitorio, asi como que siempre habia MCTs respondiendo las dudas que podiamos tener.

Casi coincidiendo con mi tiempo final en Peru, se decide potenciar nuevamente las comunidades, y ya estando en España me entero de su inicio de actividades, destacando especialmente su involucracion en la recordada campaña de Desarrollador 5 Estrellas, ahi es cuando me entero que unos amigos mios habian decidido involucrarse activamente en la organizacion de la Comunidad, y asi se sucedieron muchas cosas interesantes, el paso de http://groups.msn.com/MugPeru a www.mugperu.com, los cursos virtuales para lograr las estrellas avanzadas, la afiliacion a INETA, expositores internacionales, seminarios … talleres.

Luego, las cosas se enfriaron un poco en tanto a los lazos con Microsoft, pero las actividades seguian, incluyendo no solo temas de desarrollo sino ya de metodologias de gestion de proyectos (aunque claro, se les fue la mano cuando anunciaron que dictarian Cobit), pero ya no se estaba tan con lo ultimo: en pleno 2007 se seguian dictando temas como SQL Server 2000 (aduciendo que aun se usa, pero claro.. tambien se sigue usando COBOL), MOSS brillaba por su ausencia, los acercamientos al .NET Framework 3.0/3.5 fueron mas bien timidos, y claro un topico tan importante como Team Foundation Server (que MS y sus partners han impulsado activamente desde el 2005) ha sido ignorado a pesar de la utilidad que trae a los ciclos de desarrollo de software.

Todo esto me iba enterando mediante los avisos que periodicamente recibia por email, pero lo que ya fue de veras sorprendente fue que este lunes recibi un mail anunciando un Taller Presencial de “Construcción de Aplicaciones con Java”, revisando un poco la web veo que se han creado esta semana sendos foros dedicados a Java y PHP.

No tengo nada en contra de dichas tecnologias, pero dentro de la poca informacion con la que cuento me parece poco coherente que esta comunidad de usuarios que nacio para apoyar en la difusion del conocimiento de tecnologias de desarrollo Microsoft, opte por una poco saludable diversificacion, en lugar de apostar por las nuevas cosas que van saliendo: WCF, WPF, Silverlight, Performance Point, TFS 2008, hay mucho tema nuevo en el cual dar apoyo a los desarrolladores Microsoft como para ir perdiendo el rumbo.