Los grandes programadores

Hace unos años me regalaron (a mi y a Virginia, fue un regalo compartido de un jefe) un libro que leí con mucho interés. Ahora el autor del regalo, escribe sobre él en esta entrada del CES Digital:
Los maestros programadores.

El hoy arquitecto jefe de software de Microsoft, Ray Ozzie, se explayaba así: “los proyectos complejos de programación dirigidos por directores que no son programadores están frecuentemente condenados al fracaso, porque ellos no comprenden los intricados entresijos de los componentes del proyecto, ni las personalidades de los trabajadores. Los directores de proyectos de software han de comprender a las personas que trabajan para ellos. Yo conozco lo mejor que puedo la situación familiar, el estilo de vida y los hábitos de trabajo de cada una de las personas que trabajan conmigo. Sé que no podemos trabajar jornadas de nueve a cinco y sacar el proyecto adelante. También sé que no puedo presionar a la gente para que trabaje 24 horas durante todo el proyecto. Pero sé que, cuando llega el punto decisivo, puedo contar con ellos para trabajar día y noche si es necesario. Ahora, también tengo que saber cuándo hay que aflojar”.

No voy a sacar el recurrente tema de si los jefes de proyecto deben tener un perfil técnico o basta con un perfil de gestión. Lo que me interesa destacar son dos puntos:

• Hay que planificar los proyectos para que la gente los pueda hacer "de nueve a cinco", durante todo el proyecto. Ya vendrán problemas que no se te habían ocurrido. Seguro.
  
• Al tomar la responsabilidad de dirigir proyectos me he dado cuenta que esto no es realmente la informática. Dejas de enfrentarte a problemas matemático-lógicos, para enfrentarte (otras veces, afortunadamente, para colaborar) con las personas.

Ahora tengo encima de la mesa este artículo sobre "A scalable concurrent malloc implementation for FreeBSD". Un artículo que desde luego no tiene nada que ver con la gestión de proyectos, ni siquiera con la programación que hago actualmente. Pero es interesante.
La informática intenta resolver problemas de la gente, mejorar sus procesos, automatizar trabajos,... etc... pero los problemas realmente interesantes para un informático-programador son los que la propia informática genera a bajo nivel. Esos que nos empeñamos en dejar cada vez más abajo y dejarselos a los frikis de las universidades, o de las grandes empresas.
Ahora que busco desesperadamente mi marca personal, he pensado muchas veces en que los problemas que más me gusta resolver son los que no resuelven problemas de personas, si no problemas de computación. Aunque ya no tengo la experiencia necesaria.
Me gusta ser responsable de proyecto, decidir estrategias, implantaciones, tácticas, técnicas... enseñar todo lo que sé al equipo, hacer que trabajemos todos coordinados... pero... me gusta programar.
Si no podeis conseguir leer el libro Programers at Work, al menos leete el artículo de C. Urtasun.

Scrum y XP desde las trincheras castellanas

No puedo dejar de recomendar y agradecer la traducción que se han trabajado en Proyectalis del magnífico libro publicado en InfoQ Scrum and XP from the Trenches. Ahora tenemos este libro en un primer borrador traducido a castellano en: Scrum y Xp desde las trincheras .
Si eres de los que le da pereza leer en inglés, ya no tienes excusa.

El producto es el equipo!

He empezado a leer "Software for your Head" siguiendo la recomendación de Mario, y la verdad es que promete. Lo recomendó comparándolo con "Peopleware", así que tiene el listón muy alto.
Pero la idea básica que da en las primeras páginas, ya te lleva a reflexionar. Se plantean una investigación con equipos de desarrollo de software, y su estudio bajo esta sencilla premisa:

Equipos = Software

Y buscan los patrones que hacen funcionar a un buen equipo para desarrollar software de calidad y en plazos. Ahora bien, la primera idea interesante es cuando sben de nivel en la jerarquía. Ahora que soy responsable de proyectos, o eso que llaman mando intermedio también, he seguido pensando que mi trabajo es desarrollar software. Con más responsabilidad, más radio de acción, etc... pero que básicamente me encargo de desarrollar software con un equipo de personas.
Pero es por que no me he dado cuenta que ahora para mi, mi producto como resultado de mi trabajo, no es el software.

Mi producto es el equipo

Y plantearte eso te hace cambiar bastante algunos conceptos. El primero y más obvio, ¿qué narices sé yo de fabricar buenos equipos? El segundo un poco , un poco desasosegante... si hasta ahora lo que me gustaba es producir software... ¿qué hago yo aquí? Aunque, ¿puedo producir equipos que produzcan software si yo no sabría hacerlo? Juraría que no, y por ahí también intuyo que va el libro cuando habla de que el equipo debe tener las características que le pedimos al software que fabrica: estabilidad, escalabilidad, que no tenga/cometa errores,...
Otra idea me lleva a apoyar aún más con estos argumentos a las metodologías ágiles de desarrollo. "La persona sobre el proceso", ¿no implica el equipo sobre la gestión?.

Creo que me va a gustar mucho el libro, por que ya os digo que no he leido más de una pequeña introducción... y me ha dado mucho para pensar, aunque afortunadamente para vosotros, lo dejo para otros posts ;)

La chispa de la vida

Hoy hemos acabado discutiendo si los proyectos de software son como los de construcción o los de hacer tortillas de patatas (sic).
La gestión "clásica" de los proyectos (tipo CMMI, con toda la literatura que eso implica) con todas las técnicas y procesos de gestión de requerimientos, gestion de riesgos, planificaciones,... pueden ser usadas para todos los proyectos que creamos las personas. Pero un nivel 5 de CMMI no implica un éxito garantizado de los proyectos de software.
Tampoco la gestión ágil de los proyectos (XP, o SCRUM,...), como contraposición al modelo anterior garantiza que el desarrollo del proyecto vaya a ser un éxito. Tiene otro enfoque, ni mejor ni peor, depende de la ocasión y el contexto.
Sin duda Juan Palacio lo presentaba acertadamente como la tesis y la antítesis, de la que saldrá una síntesis en gestión de proyectos. Pero ¿puede existir algo que haga exitosos todos los proyectos software? Quizás demasiado complejo para implementarlo, pero ¿podría existir? Unos pasos previos que nos pongan en alerta ante cualquier fallo de software ANTES de que ocurra.
Un arquitecto sabe si se le va a caer el edificio o el puente antes de construirlo, le basta con simularlo. Pero no podemos simular un software, su simulación real requeriría la construcción del propio programa, con lo cual no lo simulamos, si no que lo probamos.
Un cocinero sabe qué queda despues de mezclar los huevos con las patatas, pero un desarrollador no puede estar seguro como va a ser la integración de dos componentes interactuando juntos, si tendrán problemas de integración, hasta que no los prueba.
En definitiva, que sabemos que no existe la "bala de plata", y que esta no va a existir. Esto hace mucho más divertido e interesante nuestro trabajo, o ¿no nos reiríamos más si de vez en cuando se cayese un puente o la tortilla de patatas no cuajase por más que la cociesemos?

Al final Oracle compra BEA, ¡y SUN mysql!

Pues al final la compró. Ahora solo hay que poner la cuenta atrás a ver cuando lo estropea :).
Y no sólo eso es interesante. SUN ha comprado mysql.
¿SUN puede hacer daño a Oracle con mysql en su mejor terreno, las bases de datos? Este movimiento me parece que puede tener mayor repercusión en el mercado que el de Oracle y BEA. Al final, Oracle volverá a cambiar de servidor de aplicaciones, lo que apostaría que echará a sus clientes más hartos, pero el mercado no cambiará demasiado.
Pero si SUN se plantea hacer frente a OracleDB con mysql, creo que estos se pueden poner algo nerviosos. ¿será casualidad que se comuniquen estas noticias el mismo día? SUN reforzará su mercado de software libre, e inyectará un buen capital para rematar algunos desarrollos que pueden hacer a mysql enfrentarse en grandes instalaciones a Oracle.

Me entero por Pensamientos.

El libro

Otra vez voy a hablar de un libro que no tiene nada que ver con el tema general de este blog-o lo que queda- pero que es muy cercano a mi.
Se trata de un libro titulado "El médico rural que tocaba a J.S.Bach", y lo ha escrito mi padre, Luis Carlos Díaz, sobre la vida de mi abuelo basándose en sus diarios. Vamos, más personal no puede ser.
No conocí a mi abuelo paterno, era médico rural en extremadura, y luego forense en San Sebastian-el juicio de Burgos le tocó, por ejemplo, como cuentan en el prólogo del libro-. Recuerdo cuando íbamos a San Martín de Trevejo (Extremadura) y todavía se usaba como mesa en la "boiga" una vieja tabla de madera que se usaba para los Rayos-X... ¡y la batería estaba en una esquina llena de telarañas! Ahora espero impaciente a hacerme con una copia del libro para conocer un poco más a mi abuelo.
Si os apetece leer algo diferente, os invito a acercaros a este libro. Podeis leer un pequeño resumen en una entrevista al autor. (Si quereis comprarlo, mejor poneros en contacto conmigo para obtenerlo directamente del autor ;) ).

Oracle a por BEA

Y no se trata de BEA la fea. Oracle va a intentar comprar BEA, ofreciendo un jugoso 25% de incremento sobre el valor actual de la acción. Ya hablabamos antes (mucho antes) de que Oracle necesitaba una posición más fuerte en el segmento de los middleware, y desde luego BEA es joya de la corona en ese segmento en mi opinión.

REDWOOD SHORES, Calif., Oct. 12, 2007—Oracle Corporation (NASDAQ: ORCL) today confirmed that it delivered a letter to the Board of Directors of BEA Systems, Inc. (NASDAQ: BEAS) on October 9 in which Oracle proposes to acquire BEA for $17.00 per share in cash. The $17.00 per share offer is a 25% premium over yesterday's closing price of $13.62.

Con semejante adquisición (aparte de que los desarrolladores de Oracle deberán otra vez liarse la manta a la cabeza y aprender nuevas tecnologías adquiridas) Oracle podrá hacer frente a las amenazas de Microsoft, SAP y RedHat/JBoss.
Para "variar", Oracle prefiere comprar la innovación o la tecnología a crearla -afortunadamente para ellos viendo como hacen algunas cosas :)-. Y este movimiento puede dar una ventaja muy importante a Oracle en los entornos empresariales de gran tamaño, el mismo suministrador con un middleware decente, y una base de datos consolidada.
Supongo que ahora estará en manos de los accionistas el vender la empresa, pero si yo fuese cliente de BEA la verdad que sabría si este movimiento me perjudicaría o favorecería. Veremos qué da de sí esta noticia.

Actualización: Parece que BEA ha rechazado la oferta. Una opinión interesante de alguien que dice ser empleado de BEA.

Lockpicking

Hace un tiempo escribí un post describiendo un simil que se me había ocurrido entre el software libre y el conocimiento de cerrajería [Cerrajeros y seguridad], y me he sonreido al leer un foro donde los propios cerrajeros se plantean la misma cuestión de libertades pero asociada a su profesión, así que aquí les hago trackback-back-again: Lockpicking Sport. Echadle un vistazo, es curioso ver otro punto de vista, no sé si extrapolable o no, pero curioso.
Un saludo a todos los cerrajeros :)

Free Burma!

Estrategia Open-source: No lo sé

What is the business model for this? (for Open-source)

What's the business model? I don't know. But if you don't have adoption, it won't matter what business model you use. Companies that sell open source are prioritizing community and adoption over instant monetization. We will win.

Q&A: Jonathan Schwartz on Sun's open-source business strategy

El oráculo

¿Habeis visto últimamente Oracle.ES? Así empieza su nuevo mensaje :)

Estimados visitantes:

En primer lugar presentarme, soy P.P.G. , actual propietario del dominio ORACLE.es , y escribo para informarles personalmente y como es justo del estado de la página, que había estado usando con referencia a los oráculos antes de este escrito, y 6 meses después de mi registro me van a quitar para dársela a Oracle Iberica SL.

Hay que ser muy muy [?] para que se "te olvide" un dominio de semejante importancia. Pero bueno, estas cosas pasan... y yo sin enterarme.

Tus series favoritas de médicos y su "código fuente"

De vez en cuando la "inspiración" viene de sitios insospechados. Esto he recibido por email hoy mismo, de un aficionado al ajedrez.

¿Por qué en las series como 'Hospital Central', 'Anatomía de Grey' o 'House' el que más sabe de medicina, aunque sea el director del Hospital, el que más cobra, está a pie de mesa de quirófano o visitando pacientes y, en cambio, en el desarrollo de software el que tiene más responsabilidad no ve ni una línea de código, ni igual un mapa de la arquitectura de la aplicación.

Quizás leo demasiados blogs...

Puede ser que tenga en mi cuenta de Bloglines demasiados "feeds"(105), pero cada vez que me interesa un tema, "casualmente" veo referencias a comentarios en blogs que lo tratan.
Lo que sospecho es que siempre leo entradas sobre cientos de temas diferentes, y dada la amplitud y selección de temáticas a los que estoy suscrito, siempre al focalizar mi mente en algún tema en concreto durante un tiempo, "aparecen" posts sobre ese tema. Aunque claro, no es que aparezcan y me interesen, si no que me interesa el tema y entonces los marco como interesantes.
Si estoy mirando cómo vender lo "ágil" o entrevistar a futuros candidatos, Juan Palacio hablará sobre ello. Si quiero averigüar como reorientar mi carrera, Andrés Perez comentará siempre algo interesante para mi marca. Si me harto de tanta bienaventuranza webdoscera, Rogelio tendrá un comentario irónico que me reconciliará con la red. Y si estoy poco inspirado en mi vida, Telémaco soltará algun post genial que me de una buena idea. Y así podría seguir con mis otros 100 blogs...

Ahora tengo un problema, no sé que va antes, si mi pensamiento, o el de la blogsfera... :)

¿Vende "Lo Agil"?

Vender proyectos sin asignar un presupuesto cerrado al inicio es dificil... ¿o imposible? Vale, sé que Juan Palacio los hace, pero ¿quién vende proyectos sin ir contra presupuesto cerrado? La confianza necesaria para ello con un cliente no nace de la "fama" que pueda tener la empresa o el equipo, si no solo posiblemente tras una relación larga de éxitos.
Mi duda, que planteaba también hace cinco minutos en este interesante post de Rodrigo Corral, es cómo encajar una metodología ágil dentro de proyectos con requerimientos y presupuesto cerrados en la primera fase. Obviamente, rompe dos esquemas importantes del manifiesto ágil:

Customer collaboration over contract negotiation
Responding to change over following a plan

Las buenas prácticas de las implemenaciones de las metodologías ágiles están aquí para quedarse y son de gran ayuda, pero rompiendo dos de las cuatro frases objetivo del manifiesto... ¿usarás una metodología ágil?

Infraestructura web JAVA

¿Qué harías si sabes que cualquier cosa (herramienta, framework,...) que elijas sabes que la vas a tener que cambiar en unos años? Pues prepararte para el cambio: buscándolo.
El montaje que hemos realizado para los desarrollos JAVA sigue la clásica configuración de tres capas: presentación, servicios y persistencia, intentando no atarnos a ninguna tecnología demasiado de la que nos sea imposible prencindir en un momento dado.
La elección de las tecnologías depende de muchos factores que no son solo tecnológicos, como el conocimiento con el que puedes contar en la organización para empezar a trabajar, o la disponibilidad de personas formadas para una posible contratación. Después ver que eficacia y eficiencia puedes esperar de ellas.

• Presentación: Necesitas un framework ágil, en el que se pueda ser eficiente y rápido desarrollando la interfaz. Ese framework no es Struts 1.X., ¿podrá ser Struts 2, o Wicket? Hay muchas opciones en esta capa. Ahora hemos elegido Struts 1.x... jeje, sí, ese que no es ágil y es pesado de desarrollar (muchos xml, clases), por que era donde teníamos mayor conocimiento y experiencia.
• Servicios: Al decidir seguir una arquitectura basada en servicios, debes decidir también como va a ser el acceso a los mismos: EJBs, clases locales, servicios web... La opción que parece que ofrece más flexibilidad es Spring. Permite la utilización de IoC de manera que nos facilita el acceso a los servicios inyectándolos en la capa de presentación, y además tiene utilidades para hacer transparente el cambio de EJBs a clases o viceversa.
  
• Persistencia: Para proyectos que no requieren de excesivo énfasis en el rendimiento, un framework de persistencia objeto-relacional parece hoy en día la opción más interesante. Aquí vamos con Hibernate.

Spring es una pieza muy importante en esta arquitectura que estamos implementado. Es un poco el pegamento entre las capas, y además ofrece muchas prestaciones interesantes: gestión de transacciones, aspectos, soporte de pruebas unitarias,...
La evolución de esta arquitectura está clara:

• Migración de Struts 1.x a otro framework, que sea más ágil, ofrezca una velocidad de desarrollo mayor y basado en plantillas que la gente de diseño pueda tocar más fácilmente. Wicket parece una gran opción.
• Eliminación del trabajo manual de modelado de la persistencia. Hibernate Annotations simplifica el trabajo de mantenimiento de la persistencia, pero la automatización del proceso es un objetivo más ambicioso. Estuve probando androMDA, pero la verdad que no lo hice funcionar satisfactoriamente.
• Despliegue automático de las aplicaciones en versiones EJBs o clases locales o servicios web. Una vez que se tiene las clases de implementación de los servicios, un objetivo sería poder desplegar los mismos de manera automática en cualquier plataforma.
  

¿Qué más ideas se os ocurren? Obviamente hay mucho más que hablar sobre arquitectura, estais invitados. :)

Camino sin Destino

Al final llegué a la conclusión que con mi cambio de hace unos meses no acerté. El trabajo que estaba desarrollando no me resultó demasiado interesante, y las ventajas que tenía no han podido convencerme.
Así que justo cuando ya me planteé en serio el hecho de cambiar de trabajo me llamó un amigo que necesitaban un jefe de proyecto, para una oficina que van a abrir hemos abierto en San Sebastian. Casualidades de la vida, así que ahora que voy descubriendo, o intentando convencerme, de que lo bueno no es el Destino si no el camino que te lleva a él, me embarco en mi sexta aventura profesional. Con muchas ganas, por que es el tipo de trabajo que quizás llevaba buscando algún tiempo. Intentaré hablar algo más sobre él.
Llevaba algo más de tres meses sin escribir por aquí. Pero nos os he dejado de leer...

Empresas piramidales

Al de arriba le pinchan, canta la canción... y todos intentan hacerle el coro.

Esta es la manera de los que tienen miedo.
Esto debe ser el efecto de la fiebre. Quizás necesite otro chute de Nolotil.

Bissines Intelligence - Open Source

Hace tiempo que les había prometido en un comentario que les iba a dedicar un post a este blog tan interesante de TodoBI. Aquí ya sospechamos ;) que en un futuro solo quedará el software libre, y en el campo de Bussines Intelligence en Stratebi lo plantean realmente bien. Cuatro packs para el acercamiento a sus soluciones, de manera gradual y según las necesidades.
Ahora han preparado un curso preparado especialmente para la gente que quiera iniciarse en este mundo e iniciar su carrera profesional en esa linea. El precio me parece bastante ajustado, así que si os interesa el tema, no dudeis en echarle un vistazo.

Especialmente dirigido a recién licenciados, a punto de concluir o con reciente experiencia profesional !!

Queremos crear un gran equipo!!

Este curso es el primer paso para que podáis desarrollar vuestra carrera en el mundo del Business Intelligence con tecnología Java Open Source y Stratebi os ofrece grandes oportunidades para comenzar.

Publicidad "contextual" en videos

Acabo de ver el video sobre el N95 de Nokia en El Mundo, y no sé como establecen la publicidad que meten al inicio, pero me han puesto publicidad del Tomate Orlando. Vamos, que muy contextualizada no me ha parecido.
Espero que las campañas de publicidad que se ciernen sobre nosotros en los videos sean un poco más refinadas.

Cita de masas

Este es el mayor peligro que hoy amenaza la civilización: la estatificación de la vida, el intervencionismo del estado, la absorción de toda espontaneidad social por parte del Estado; es decir, la anulación de la espontaneidad histórica, que en definitiva sostiene, nutre y empuja los destinos humanos. Cuando la masa siente alguna desventura o, simplemente, algún fuerte apetito, es para ella esa permanente y segura posibilidad de conseguir todo -sin esfuerzo, lucha, duda, ni riesgo- sin más que tocar el resorte y hacer funcionar la portentosa máquina. La masa se dice: "El Estado soy yo", lo cual es un perfecto error. El Estado es la masa sólo en el sentido en que puede decirse de dos hombres que son idénticos, por que ninguno se llama Juan. Estado contemporaneo y masa coinciden sólo en ser anónimos. Pero el caso es que el hombre-masa cree, en efecto, que él es el Estado, y tenderá cada vez más a hacerlo funcionar con cualquier pretexto, a aplastar con él toda la minoría creadora que lo perturbe -que lo perturbe en cualquier orden: en política, en ideas en industria.

Jose Ortega y Gasset
La Rebelión de las masas

Este es uno de mis libros de mesilla favoritos. Y perdón por la pedantería.