Guerra de plataformas

Es algo que se da inevitablemente, las discusiones sobre cual es la "mejor plataforma de desarrollo" se repiten constantemente, por lo general no conducen a nada porque prevalecen los dogmatismos y las personas tendemos a cerrarnos en nuestra posición y a no escuchar a los demás, bueno .... en realidad lo mismo pasa cuando hablamos de fútbol o política.

Actualmente considero que hay tres opciones consolidadas para desarrollar software empresarial a medida: Java, .NET o herramientas tipo CASE (por ejemplo Genexus), cada una con sus ventajas y desventajas.
Personalmente conozco mucho mas el mundo Java porque trabajo en él desde hace varios años, pero también he desarrollado en C# y soy analista Genexus, en cuanto a cual es mejor no tengo una respuesta definitiva, depende mucho del contexto del proyecto y de los recursos materiales/humanos que disponemos.

Lo que si es claro es que se han ejecutados proyectos exitosos con todas las tecnologías, en todo caso los fracasos se dan generalmente a causa de un relevamiento de requerimientos pobre o por una mala conformación del equipo de trabajo, no porque el proyecto se desarrolló en .NET en lugar de Java o viceversa.

Como dice el técnico de fútbol argentino Bambino Veira: "Se ha salido campeón con todos los sistemas tácticos, lo importante es tener buenos jugadores, que estén motivados y convencidos de lograr el objetivo", yo aplicaría esta frase también en nuestro ámbito.

Hasta el próximo post!

Trabajar en el exterior

En mi trabajo anterior tuve la oportunidad de viajar a Chile, India y Méjico durante un año en total para 3 proyectos diferentes, sin dudas fue una experiencia muy enriquecedora en todo sentido.

Aunque no todo lo que brilla es oro como dice el dicho, ahora que se viene el fin de año todavía recuerdo aquel 31 de diciembre de 2004, en pleno festejo tuve que acostarme temprano porque al otro día a las 8 de la mañana comenzaba un viaje interminable y en solitario hacia Bangalore-India, 3 escalas con 5 horas de espera en cada una, casi dos días de "safari". Ni hablar del cambio cultural que significó, desde la comida hasta la forma de relacionarse y encarar el trabajo. Fueron dos meses muy largos y duros pero no me arrepiento de haberlos vivido.

Este tipo de experiencias, mas allá de que pueden servir en lo económico, creo que nos hacen crecer en lo personal y como profesionales al obligarnos a salir de la "chacrita" y tomar otros desafíos.
De todos modos, para vivir me quedo con Uruguay, bendito país!! ... como dice el filósofo Sánchez Padilla ;)

Hasta el próximo post!

Estimación de esfuerzo

Para mi es una de las áreas mas oscuras en el desarrollo de software, sigo siendo escéptico cuando me hablan sobre COCOMO y esas fórmulas "mágicas" con ponderadores que permiten calcular el esfuerzo de desarrollo en Java, Visual Basic o cualquier otra tecnología con solo un par de clicks.
Hay cientos de libros escritos sobre éstos temas y gente muy respetada que se dedica a la docencia, sin embargo no encuentro un método formal pero práctico de usar a la vez.

Cuando tengo que realizar una estimación de esfuerzo me baso en un esquema de clasificación de casos de uso por complejidad y luego según experiencias anteriores asigno una cantidad de horas/hombre para cada nivel. Eso nos da un esfuerzo aproximado de desarrollo, luego hay que sumarle otros items transversales a todo el proyecto, por ejemplo: ajuste del análisis, diseño, definición de la arquitectura, testing y documentación.
Además se presenta otro problema, estas estimaciones se hacen en horas/hombre, es decir imaginando que todas las tareas son realizadas por una sola persona en forma consecutiva. Inevitablemente luego vienen las discusiones cuando se pretende usar la matemática para hacer razonamientos como: "Si la estimación da 12 meses/hombre, entonces con 12 personas lo finalizamos en un mes", NOOO!!!.
En mi opinión ese cálculo simplificado no aplica en éste contexto, intervienen muchas mas variables, como por ejemplo la metodología a usar y la experiencia de las personas.

Generalmente cuando nos enteramos de nuevos proyectos, los vendedores ya han dicho "amén" a todos los requerimientos de los clientes, inclusive prometiendo plazos de entrega sin haber evaluado la factibilidad técnica. Así es como fracasan los proyectos, si desde que comenzamos a desarrollar ya estamos atrasados, los problemas no van a tardar en aparecer.
Seguramente la mayoría hemos pasado por ésto y lo seguiremos sufriendo si quienes se dedican a vender software no encuentran la manera de explicarle a los los clientes que no se trata de "soplar y hacer botellas", mas allá de las urgencias reales que puedan tener.