Java esta de moda

Ha llegado a mis manos la publicación de TIOBE (www.tiobe.com) sobre los lenguajes más populares. Es una estadística que se basa en las búsquedas realizadas sobre google, yahoo, msn…



Desde el principio de la publicación del indicador Java ha sido el más popular, y eso hace por lo menos 8 años, según el gráfico que os presento a continuación.



Como observareis salvo en Octubre de 2004, Java ha sido siempre el líder. Cuando lo vi me llamó la atención y comencé a pensar que podía ser que coincidiera con el lanzamiento de alguna versión de .net o algo así. Nada más lejos de la realidad. No es que java dejara de ser el más popular sino que Google cambio su manera de calificar las búsquedas.. quede esto como anécdota.

Creo que para todos 8 años son mucho tiempo, pero evidentemente no representa lo mismo para una persona, para un perro o para un Drago milenario. Lo que está claro que 8 años en informática es mucho, mucho tiempo.

La informática ha demostrado ser imparable, realizando en menos tiempo que cualquier ingeniería una evolución exponencial, y ha sido la tool del resto, desde aeronáutica, caminos, industriales, química, etc , Por eso a este nivel una década, marca una tendencia y Java sin duda es el rey de la misma.

Cuando Java se debate entre los evolucionistas que pretenden que java siga cambiando (o mutando ¿?) continuamente con versiones de JDK y los inmovilistas que creen que java debe frenar su evolución y su continuo chorreo de versiones, que prefieren dejar para lenguajes como Groovy y Scala, EXISTEN personas que creen que Java no debe ser un lenguaje apto para enseñar en la Universidad. Se imaginan que en la facultad de Medicina solo se dieran las enfermedades de hace más de 50 años, o que en Arquitectura no permitieran el uso de programas tipo Autocad, o en Física no usaran los ordenadores, .. Impensable verdad??.

Hoy por hoy, llegan universitarios a la Software Factory que no conocen Java, ni tampoco .net, ni Cobol, ni SAP… siento decir que la Universidad no hace su trabajo y no mira por sus clientes, los alumnos. Si esto sigue así la informática corre el riesgo de salir de la Universidad, y eso espero que nunca ocurra porque creo que Informática y empresa deben ir de la mano.

Entiendo a dos amigos que uno con una asignatura y otro con el proyecto, dicen que para ellos es una bobada tener la carrera. Que razón tienen !! Lo único que les conviene acabar por "El que dirán.. los de RRHH", aunque tampoco hay una carrera de RRHH.. :-D (con cariño que algunos son muy buenos y grandes amigos).

Cuando era mas joven

Hace unos años publique un articulo en la revista de mi antigua empresa, de cuyo titulo no logro acordarme, ya que se puso en la publicación y no dispongo de ella. He añadido un par de imagenes para complementarlo. Os dejo con el..

Encontrándome ante la tesitura de tener que impartir un curso para Jefes de Proyecto empecé a recabar información sobre la que apoyarme y que me aportara una visión externa de los proyectos y una buena base teórica. Buscando unos datos para la introducción me acorde de Mr Gartner (en realidad es una consultora).

El ver las estadísticas de Gartner hace pensar a cualquiera sobre los proyectos del sector de las Tecnologías de la Información, no tengo intención de dar cifras pero puedo resumir que dependiendo del tipo de proyecto el porcentaje de éxito/fracaso está sobre 50 %. Normalmente esto supone unas perdidas económicas terribles tanto a compradores como vendedores de proyectos.



No puedo imaginar que solo el 50 % de las autopistas que se construyen acabaran exitosamente, o aviones, o edificios o puentes. La informática también es una ingeniería o eso me han contado. Parece que es jugársela a cara o cruz cada vez que alguien se plantea hacer un nuevo proyecto. Evidentemente algo no funciona en el sector.

Una deducción rápida permite afirmar que el 50 % de los proyectos no deben hacerse, la complejidad reside en determinar cuales antes de empezar con ellos, ¿bola de cristal? No, mejor una Metodología.

Claro, la Metodología, que fácil era. Espera no tan rápido, ¿eso no fue la conclusión que se saco en la crisis del SW de los 70? ¿Pero no tenemos ya un montón? RUP, Merisse, Metrica 3, Extreme Programming, etc. Todas tienen éxitos y fracasos, por tanto hemos vuelto al principio.

Cada año aparecen nuevas metodologías milagro que han conseguido éxitos en proyectos en la India o en China, siempre bien lejos, como Pair Programming, ¡ dos programadores por ordenador¡. ¿Cómo no se me había ocurrido antes? Supongo que porque los ordenadores solo tienen un teclado.

Sin embargo para encontrar el camino es mejor mirar donde se ha acertado y cuando se ha acertado y con que. El sector financiero (Banca y Seguros) históricamente ha sido uno de los sectores más robustos en cuanto a sus sistemas y aplicaciones Sw. La mayoría de ellos aún cuentan con todas sus reglas de negocio y core sw realizados en antiguas tecnologías como cobol y RPG, todo ello construido en los 80, y funciona. Cada vez que intentan migrar o generar nuevos procesos se enfrentan al cara y cruz, por eso prefieren, si pueden, no tocarlo.



Tecnologías obsoletas, con menos medios, e informáticos ya jubilados son los que parece que lo hicieron bien, y ni siquiera Microsoft había inventado el Project.

Evidentemente la tecnología es imparable y ahora sin duda todo es mejor, ¿pero funciona mejor?.


Publicado en Te Interesa. Marzo 2006

Fabricas del Software

En esta entrada del Blog voy a comentaros mi última adquisición literaria "Fabricas del Software: Experiencias, Tecnologías y Organización" publicado en Diciembre de 2007 por Ra-Ma.

En este punto solo puedo daros unas primeras impresiones, ya que no he podido completar su lectura aún, pero no quería esperar más para daros esa primera visión.

En primer lugar se agradece que alguien se adentre en este mundo y ponga un libro en nuestro idioma en la calle y a disposición de todos. En ese punto solo puedo aplaudir a los autores y a Ra-Ma por darles cobertura.

El libro tiene a mi modo de ver dos partes totalmente diferenciadas:

- La primera que repasa la historia de las “software factories”, tecnologías, modelos de desarrollo, orientación a procesos y calidad.

- Una segunda parte en que nos encontramos con varios casos de estudio sobre fabricas del software existentes en la actualidad, unas con más información que otras, pero en cualquier caso da una medida del mercado.

De momento he atacado algunos capítulos, no creo que sea necesario leerlos en orden, y puedo decir que la visión de resumen y la forma de llevar temas que son pesados a quince o veinte páginas me ha gustado. Además aporta una extensa bibliografía al final de cada capítulo para el que quiera profundizar.

En principio es recomendable para todos los públicos, desde comerciales, directores, jefes de proyecto y programadores con inquietudes..

De momento alabo la idea y el formato, además la existencia de varios autores hace pensar en que cada experto tiene "su tema". Ahora solo me queda esperar que los contenidos también sean buenos.. pero eso lo comentaré más adelante.

Lo podéis adquirir tanto en Ra-Ma como en la Casa del libro.

10 cosas que todo Arquitecto debe saber..

Como mucha gente sabe una de mis pasiones es la vertiente más tecnológica de la Ingeniería del Software, personificada en el concepto de Arquitectura. Antes de nada os dejo una pequeña reflexión.

Cuando hablo de Concepto Arquitectura pienso, sobre todo, en que cada día se demuestra más la tendencia a que vamos a una ingeniera del software gobernada por la Arquitectura, y sin embargo desde el punto de vista del usuario de negocio, esto tiene que dejar de existir ya. La tecnología debe dejar de ser una barrera, sobre todo en cuanto a su continua evolución, y cada día vemos más empresas manteniendo viejos sistemas, aunque es mejor que migrarlos todos cada poco.. no es la solución.

Para mi cada vez esta más claro que el éxito de las arquitecturas empresariales viene dado por pensar en una clara orientación a servicios (SOA) , (quizás es pronto para orientación a eventos EDA) para acabar llegando a BPM. Donde el usuario de negocio debe ser capaz de definir sus propios procesos de negocio… que si ¡!! que esto es viable, preguntar a BEA.

Tenemos que pensar que no podemos construir un BPM como primer paso, sino empezar a pensar en una estructura de Gobierno SOA sobre la cual vayamos creciendo hasta tener una suficiente estructura de servicios de negocio, que nos permitan montar BPM. Por tanto el modo de llegar es ir dando pasos.. no esperar a empezar los últimos la carrera.

A donde quería llegar, sobre las arquitecturas, es proporcionaros un interesante documento que ha llegado a mis manos, el cual se titula “ 10 cosas que todo arquitecto debe saber” y la verdad es que son ciertamente interesantes:

1. La base esta en las personas.

2. Todas las soluciones llegan a ser obsoletas.

3. Los Datos son para siempre.

4. La flexibilidad genera complejidad.

5. Nada funciona según se esperaba.

6. La documentación es el codigo fuente universal.

7. Conozca el negocio.

8. Mantenga la visión.

9. Los arquitectos deben ser programadores.

10. La experiencia es insustituible.

Sobre cada una existen frases reflexivas, que realmente dan que pensar.

Doy las gracias al autor del mismo Richard Monson-Haefel por sus “10 Things Every Architect Should Know”, que aquí publico, creo que siguiendo correctamente la licencia.