Vuelta al Blog y algunos consejos para la carrera

Cambios de Empresa, Viajes a Shanghai, a Palo Alto, en el mismísimo Silicon Valley, construcción de plataformas para Cloud Computing, uso intensivo de Git, GitHub, continuous Integration (Integracion Contínua), implementacion de Continuous Deployment (Despliegue continuo), Culturas de Start Ups, etc., son algunas de las novedades de este año que ya se termina. Son demasiadas para un solo post. Vamos a ir retomando de a poco este espacio de reflexión sobre tecnología de la información, buenas practicas de Desarrollo y todo lo que hace a las metodologias ágiles y al desarrollo de software en general.

La verdad es que tuvimos un poco abandonado (tachen "un poco") a este blog gran parte del año. Hemos estado envueltos en un proyecto altamente demandante de tiempo en una empresa Start Up. Algún día con un poco mas de perspectiva escribiremos sobre esta experiencia que ha tenido de TODO menos aburrimiento. En parte es por eso que no hemos podido escribir en este blog. Estuvimos en unos de esos periodos de aprendizaje intensivo, mezclados con no-pocos-cambios y experiencias de toda índole. Y todo suceso de este estilo conllevan un ritmo que no dan mucho margen para pararse a pensar y reflexionar demasiado sobre lo que esta sucediendo.

Hoy quiero dejarles esta reflexión.

Cuando recién empezaba en esta profesión (hace poquísimos años....bueno tampoco tantos che! unos 16 añitos...) no había la diversidad de ofertas que hay en este momento. Uno elegía entre dos o tres opciones a lo sumo e iba pasando de proyecto en proyecto mas o menos como y cuando podía. Tampoco me importaba demasiado porque en ese momento pensaba (no lo pensaba, en verdad, lo "sentia" de alguna manera porque si me paraba a pensarlo es obvio que no es asi) que tenia infinitos proyectos por delante.

Habiendo ahora tantos proyectos, tantas empresas y ofertas dando vueltas por el mundo veo a un montón de gente que se conforma con lugares mediocres, con proyectos tan interesantes como palear las arenas del Sahara en verano y se aferran a trabajos malsanos o ambientes enfermos como si estuviéramos hace 30 años atrás donde un empleado entraba a una gran empresa y sabia que se iba a retirar en ella.

Por el otro lado veo tambien a chicos muy jóvenes, con mucho empuje y ganas pero que en lugar de elegir lugares adonde aprender, repito: adonde r-e-a-l-m-e-n-t-e aprender, van saltando de trabajo en trabajo como sapo perseguido porque un trabajo le ofrece 10 pesos mas que otro, sin planificar a mediano plazo. Sin planificar en que área, en que tipo de proyectos le gustaría trabajar. La gente que trabaja en IT en USA tienen muy claro esto de planificar sus carreras a mediano plazo digamos.

Muchas veces he tenido que elegir entre proyectos. A veces entre ganar mas plata y hacer algo que me interese. Elegir entre el bolsillo o el corazón. Y créanme lo que les digo, las veces que elegí con el bolsillo... nunca salieron como esperaba.

No estamos planteando acá una postura romántica o naif o a la San-Francisco-De-Asis, "Salven al mundo!! Sigan sus corazones", "Viva la pobreza", "Si a la Revolución Arabe", no (es decir, Si a la revolución Arabe pero no a Vivir en la pobreza ). Sabemos que uno trabaja principalmente por dinero y que lo que busca en general al cambiarse de trabajo es un crecimiento...en dinero.

Pero lo cierto es que si es "solo" el dinero, si el trabajo no te motiva, es aburrido o te desmotiva a cada paso, tarde o temprano terminarás odiando lo que haces, o a tus compañeros o jefes o a todos juntos... incluyendote. Y 40 horas semanales (o mas!) es demasiado tiempo para hacer algo que uno odia, verdad?.

Asi que les dejo la GRAN VERDAD NUMERO 1 de este fin de año, a modo de reflexión.

GRAN VERDAD NUMERO 1:

Hay un numero limitado de proyectos de desarrollo en los que participaremos en nuestras vidas. Elijamos aquellos que realmente nos apasionen. Somos de los poquitos profesionales en el mundo, los de IT, que podemos darnos este lujo.

Asi que, aún cuando esten recien comenzando la carrera, y sobre todo si estan en esta situacion, empiecen por pensar que quieren, que les gusta. Que les gustaria hacer los proximos años.

1. Si solo conocieron un lenguaje de programación, experimenten con otros.
2. Si solo estuvieron en consultoras de sistemas, traten de estar en el depto de sistemas de una gran empresa.
3. Si solo estuvieron en un determinado tipo de proyectos o metodología, experimenten con otros.
4. Traten de cambiar a proyectos que sean interesantes, por la tecnología o por el tema de negocio relacionado.
5. Traten de rodearse de personas que sepan mas que ustedes.
6. Empiecen un blog de sus temas favoritos, participen en foros,
7. Hagan de su CV un diamante en bruto, al cual agreguen items puliendolo asi dia a dia.

Y si hacen algún trabajo que realmente los apasiona, si son buenos y se esfuerzan cada dia por mejorar, por crecer profesionalmente, si se preocupan y toman cada nuevo comienzo como una gran oportunidad, y piden reconocimiento (noten que no dije "esperen reconocimiento"), créanme, va a suceder. Van a ganar dinero y hacer algo que les apasione.

Elijan siempre con el corazón.

Editorial de fin del año del 2010 - De vuelta a las bases

Henos aquí al final del año 2010. Primer fin de año de este blog que esperamos que sea el primero de muchos.

La verdad, en estos casi 9 meses de vida (chiste obvio al margen) nos hemos dado algunos gustos. Como dicen por ahi, justamente los gustos hay que darselos en vida y así lo hicimos.

Recuerdo cuando era chico miraba series de televisión (y aquí voy a delatar nuestra edad, ey, tengan en cuenta que la mitad de nosotros somos treintañeros todavia!! mas respeto!) como los angeles de charlie, los dukes de hazzard, BJ (la del camionero con el mono), el Sheriff Lobo (imperdible), el hombre de la Atlantida (ju juuu por DioS!), buck roger o el auto fantástico. Cuando terminaba la temporada de estas series era habitual que el ultimo capitulo fuera en realidad una selección de las mejores partes de los capítulos que se habían emitido este año. Va aquí nuestro homenaje a esta práctica, como modo de resumen del año 2010.

Hemos repasado algunos principios básicos de objetos en la-ley-de-demetrio-y-otras-yerbas-oo y en poo-ejemplos-de-la-ley-de-demeter. No quiero olvidarme tampoco de la seria sobre patrones de tests de unidad: patterns-de-tests-de-unidad-1-como-deberian-ser-los-tests-de-unidad, patrones-de-test-de-unidad-2-humble-objects o como-lograr-tests-de-unidad-rapidos.

Estos principios y patrones parecen bastante obvios y trillados(bah, así nos parecían) pero charlando con mi amigo y co-autor de Blog nos hemos dado cuenta que en estos tiempos muchas veces debido a la falta de recursos para programación o porque hay otros temas mas "fashions", lo cierto es que muchos programadores nuevos no conocen ni a estos ni a los principios más básicos de la Programación Orientada a Objetos.

Hemos recién empezado a charlar sobre un tema muy interesante, importante como buena practica pero bastante extenso como son los Code Smells en code-smells, desgranando algunos en detalle como: desconfien-de-los-parametros-booleanos, o obsesion-primitiva y comentarios

Emprendimos una batalla, desigual desde ya, tratando de aclarar cuestiones muchas veces malentendidas o mal interpretadas de las metódologías ágiles, como en con-scrum-no-alcanza o estas-realmente-haciendo-desarrollo-Agil y dos en particular que me gustaron mucho, por la repercusión que tuvieron y porque fueron generadas con discusión dentro de la comunidad ágil iberoamericana: metaforas-del-desarrollo-de-software-i y metaforas-del-desarrollo-de-software-ii. Para terminar con el articulo fundamental de como encarar el aprendizaje de cualquier nuevo conocimiento y en particular de una metodología ágil : el-camino-del-conocimiento-de-aprendiz-a-maestro.

Como niños buenos e hijos de la generación "La inmaginacion al poder", hemos discutido como debe ser un buen líder y otras cuestiones de liderazgo en liderazgo-i y liderazgo-ii. Pero por otra parte, cuestionando nuestra conciencia, nos hemos encargado de recordar las obligaciones que tenemos como verdaderos profesionales de formarnos constantemente: cuantos-libros-tecnicos-leiste-este-año, y trabajar sobre lo que tienen importancia como en mantenibilidad-vs-reusabilidad, por-que-funciona-pair-programming y nos hemos auto-retado cuando perdemos el tiempo como en larga-el-twitte o productividad-la-espartana.

Para finalizar queremos resaltar dos articulos en particular, ambos han tenido mucha difusión, y creemos saber, al menos parte de, la causa: El primero es flexibilidad-ante-el-cambio que habla sobre porque hay que estar preparados para el cambio en todo proyecto de desarrollo, sobre como descubren lo que quieren los usuarios y como el cambio es esencialmente imparable porque es sencillamente parte de la realidad. Y el otro es pasos-de-bebe-el-fin-del-debugging, una de las herramientas menos utilizadas, difundidas y comprendidas de la programación pero que nosotros le asignamos una importancia capital para enfrentar el caos de la complejidad que impone El Cambio sobre el desarrollo de software, junto, claro está con las prácticas de TDD y pair programming.

Para cerrar el balance , además de los artículos, este año organizamos dos Code Retreats, que nos permitieron compartir tiempo con otros locos (perdón, quiero decir: con otros entusiastas de estos temas) capaces de juntarse un sábado a las ocho de la mañana a programar de a pares, resolver problemas y razonar sobre como mejorar nuestro arte.

Bueno, eso es todo. Lo que hemos tratado humildemente de hacer este primer año desde este espacio es describir y promover conceptos, libros, técnicas y herramientas que consideramos poco habituales dentro del ámbito de la programación.

Creemos que la terrible presión de la ola de información junto con la inundación de nuevos lenguajes, herramientas y frameworks impone tal ritmo al programador profesional que arrasa con cuestiones de base y produce que todo se confunda en un lodazal de conocimientos superficiales y la Ultima-bala-de-plata-que-viene-a-solucionar-todos-tus-problemas.

Lo que se necesita en realidad es adquirir buenos hábitos, aplicar Buenas Practicas de desarrollo y volver a las bases.

Por eso brindamos. Salud!.

La foto del brindis es propiedad de larrazun. Algunos derechos reservados.

Flexibilidad ante el cambio

Inmaginense la siguiente situación: Comienzo de un proyecto, el Gran-Gerente de proyecto, Gran-Jefe-Saco-Agua-De-Las-Piedras reune a todo el equipo y anuncia "El equipo de funcionales va a comenzar con la (Gran)Etapa de relevamiento, durará unos 10 meses. Queremos lograr entender completamente lo que quiere el usuario asi no vamos a tener ningún cambio y vamos a saber todo para cuando entremos en la etapa de desarrollo, que durará unos 3 meses.". Esta es una situacion real, números de meses incluidos. Me sucedió a mi.

Una y otra vez todos hemos estado en proyectos adonde pasa mas o menos lo mismo: Una Gran Etapa De Relevamiento al principio del mismo para "evitar" tener que realizar Cambios y para aprender TODO lo que hay que aprender. Una y otra vez hemos llegado a la mitad o al final del proyecto, con varios meses de retraso respecto de la fecha original, cuando, al mostrarsele el sistema a los usuarios comienzan a aparecer estos "cambios-que-se-suponian-que-no-tenian-que-existir".

Porqué pasa esto? Son los usuarios una fraternidad de sádicos a los que les gusta torturarnos? Son los funcionales, los desarrolladores personas altamente perturbadas y disfuncionales (eh... mejor no contestemos esto) que no pueden entender lo que el usuario les pide? Existe el destino y se empeña en ponernos piedras en el camino?

O será que el cambio es una parte normal de todo proyecto?

Hasta el surgimiento de las metodologías ágiles el cambio se trataba (se sigue tratando) como una anomalía, como un error del usuario o como un síntoma de que alguien se equivocó y no relevó lo suficiente. Cuando hablamos de cambio lo hacemos en todo sentido pero particularmente de los requerimientos y necesidades del usuario.

Por este motivo es que Waterfall indica que debe realizarse una Gran Etapa de Relevamiento al Principio (en inglés, BRUF, Big Requirements Up Front), seguido de escritura de casos de uso (indicado por el DR. RUP) y terminando con requerimientos firmados por usuarios temerosos (de meterse en camisas de once varas y de estar firmando los "10 mandamientos del sistema" tallados en Mármol!).

PMI lo trata con un proceso de "gestión de cambio" o "Control de Cambio" adonde en base a un pedido de cambio del relevamiento inicial se realiza un "cambio de alcance", lo cual implica reestimar costos, chequear asignación de recursos, reestimar tiempos, replanificar y obtener la autorización del sponsor / Gerentes del proyecto para proceder con el cambio. Cualquier parecido con la tortuga de Mafalda es pura coincidencia (La tortuga se llamaba Burocracia).

Justamente uno de los principios comúnes a todas las metodologías ágiles es: El cambio es parte de la realidad!

No es un hecho excepcional, no es causado por usuarios viles y sádicos que quieren hacer un infierno de nuestras vida. No es causado por analistas funcionales perezosos (bah, vagos) o que no saben como escribir un caso de uso (que los hay, los hay) ni por malos programadores que malinterpretan lo que esta escrito en la lista de requerimientos (de estos también hay). Sencillamente es que no importa cuanto tiempo le dediquemos al relevamiento, no importa cuantas Maquetas, prototipos o casos de uso hagamos para mostrarle al usuario, no importa cuanto esfuerzo le dediquemos a reuniones de validación, siempre siempre siempre va a haber cambios a partir del relevamiento inicial (por favor, vuelvan atras y lean de nuevo esta frase).

Porqué? bueno, los principales motivos son :

1. El usuario ve el sistema funcionando y ahí se da cuenta lo que realmente quería .
2. El usuario descubrió a lo largo de todo el tiempo de trabajo en conjunto con analistas y desarrolladores lo que necesita.
3. Funcionales y Programadores aprendieron del dominio del problema y son capaces finalmente de entender lo que el negocio necesita ahora que el usuario finalmente aprendió.
4. El negocio simple y sencillamente cambió.
5. La legislación cambió.
6. El/Los usuarios cambiaron (y usuarios distintos quieren soluciones distintas).

Es decir, simple y sencillamente porque es NORMAL que la realidad cambie (un cambio en alguna regulación, etc, el mercado cambia, aparece un nuevo producto, etc). Y es NORMAL que el conocimiento cambie a medida que uno va teniendo más información y aprendiendo. Esta información solo se puede obtener a través de la experiencia. Esto es así porque al ser un sistema un modelo abstracto de la realidad el usuario sólo se da cuenta de las consecuencias de lo que pidió cuando lo ve funcionando, cuando lo "toca".

Que mente perversa nos metió en la cabeza la idea de que podemos preveer de entrada la forma en que se va a comportar la realidad!? Que cambios se van a producir en el mercado? que leyes saldrán? que va a querer el nuevo usuario o de que se va a dar cuenta el usuario que tenemos cuando le mostremos el comportamiento de las reglas de negocio que relevamos en casos concretos? seria como predecir el clima, pero de aca a un año!.

Una simple muestra para ver el lugar que ocupa el cambio en las metodologías ágiles, en el primer libro de XP, llamado "XP Explained", de Kent Beck, tenia como subtitulo "Embrace Change", abracemos el cambio!

Escuchemos de nuevo finalmente a Kent Beck, en un fragmento de su libro "Implementations Patterns" :

"Nuestra industria parece adicta a la idea de que solo si diseñamos el software bien de entrada no tendremos que cambiar luego el sistema.

Recientemente lei una lista de razones por las que el software cambia. En la lista estaban los programadores que no hacen bien su trabajo al entender los requerimientos, sponsors y usuarios que cambian de parecer y otros motivos mas. El unico factor que faltaba en la lista era justamente el cambio legítimo. La lista asumía que el cambio es siempre un error.

¿Porque no sirve un pronostico del tiempo para todos los dias? Porque el tiempo cambia de manera impredecible. ¿Porque no podemos listar de una sola vez todas las formas en las que necesitaremos que el sistema sea flexible? Porque los requerimientos y la tecnología cambian de manera impredecible.

Esto no nos releva de nuestra responsabilidad de hacer lo mejor que podamos para desarrollar el sistema que el usuario necesita ahora pero sugiere que hay límites al valor de hacer sistemas a prueba-de-cambios-futuros, a través de la especulación.

Poniendo todos estos factores juntos, la necesidad para que el sistema sea flexible ante el cambio, el costo de esa flexibilidad, la impredecibilidad de adonde será necesaria, me lleva a creer que el momento para introducir esa flexibilidad es sólo cuando la misma es absolutamente necesaria".