martes, 29 de marzo de 2011

Lo vital en el arte del software: trabajo en equipo.



Entre mis contemporáneos no hay mucho amor por el dedicarse a reflexionar y pensar, cosa que le atribuyo al haber crecido detestando a Pitufo Filósofo. No obstante, los ingenieros tenemos claro que correr a actuar (construir, codificar, perseguirnos la cola) sin un claro entendimiento de un problema, sin la evaluación de alternativas de solución, probablemente nos deje increiblemente cansados y frustrados, porque seguro que vamos a haber invertido un tiempo valioso aplicando una solución (si es que llega a ser solución) probablemente sub-óptima. Nada más frustrante que darnos cuenta, luego de haber invertido la energía, que había una manera órdenes de magnitud más simple de resolver lo mismo que hemos estado haciendo por horas o días (peor si son semanas o meses).

En mi humilde experiencia he podido presenciar varias veces la demostración de aquella máxima que dicta que para resolver grandes problemas y lograr grandes metas se necesitan de grandes equipos, no de grandes individualidades. En el mundo del deporte, de los mejores ejemplos lo tenemos con el Real Madrid en su era galáctica, que no por tener a los jugadores más costosos de la época y que exhibían gala de ser posiblemente los mejores en sus posiciones en el momento, podía ser calificado como el mejor equipo del mundo o consistentemente siquiera como el mejor de su liga. Un equipo es más que la suma de sus miembros, y los grandes equipos, aunque seguramente puedan contar en ocasiones con personas excepcionales, saben que lo más importante es lograr la resonancia y la sinergia interna para que en conjunto puedan lograr metas que parecerían inalcanzables si simplemente lo atacamos cada uno por separado.

Como líder de un equipo que tiene la meta declarada de tener alto desempeño y parte de una organización que consistentemente se reinventa y decide ser Beta por Siempre, siempre estoy motivando a los miembros de mi equipo y a mis colegas en general a ser mejores cada día, a superar su marca personal. Pero no es suficiente con la conformación de un equipo de los mejores profesionales en sus ramas para resolver los más grandes problemas, sino porque logremos esa resonancia, esa sinergia que hace que el equipo desarrolle esas propiedades emergentes que sólo consiguen los sistemas bien integrados.

Más humildad, menos arrogancia. Más ayuda entre todos, menos apuntar dedos. Más conocer nuestras fortalezas y las de nuestros compañeros, menos contar sólo con lo que una persona puede hacer. Más hacer nuestro aporte de lo que necesita el equipo, menos protagonismo y pensar en sólo en mí.

Para la conclusión les dejo estas anécdotas personales. En mis años de universitario representaba a mi Alma Mater en una competencia internacional de programación, y junto a mí estaban dos de las mentes más brillantes y prodigiosas que he tenido a suerte conocer. Hacíamos cosas increíbles, pero las individualidades pesaban más que el equipo, y a pesar de ser un all-stars, no logramos llegar al podio. Por el mismo tiempo fue con ellos que hice mis primeros intentos de emprendimiento matando tigres, y tampoco logramos concretar siquiera un sistema completo.

En contraposición, en mi primer trabajo como ingeniero graduado me correspondió trabajar con un ex-compañero de clases que había sido sobresaliente... en rumbas y fiestas, pero distaba de ser un virtuoso de la programación, que incluso me había quedado mal en algún proyecto académico. Eso era para mi como pagar un castigo. La lección increíble que la vida me dio allí fue que, no con cero conflictos, y luego de la conversa plana de como nos sentíamos (no creo que para él haya sido tampoco una felicidad encontrarme de nuevo), nos dedicamos no sólo a dar lo mejor de cada quien, sino a integrar magistralmente cada uno sus fortalezas con las del otro, y a pesar de factores exógenos que habrían hecho de ese proyecto un fracaso más, ese se convirtió en el primer sistema que logré llevar a producción y que estuvo allí por no menos de 7 años después. Lo que no pude lograr antes con un equipo de sólo estrellas.

viernes, 7 de enero de 2011

De vuelta a la reflexión

Recuerdo claramente el día que inicié esta conversa con el mundo, quizás conmigo mismo. Estaba en tierra extraña, aprendiendo muchísimas cosas, cuestionándome aquello que creía que sabía. Trataba sobre el software, la forma de hacerlo, su manera de crear valor, y como podía yo mismo agregar valor haciendo una de las cosas que más me ha gustado hacer en mi vida: programar.

Más de 3 años han pasado, y las preguntas no son muy distintas, aunque si son formuladas con más contexto. Mi perspectiva personal sí es distinta: Ahora casado, con un hijo, ya graduado de mi maestría, y con 3 años de experiencia en la co-creación de startups basados en software.

Asi que con año nuevo, década nueva, aprovecho el sabor propio de un nuevo comienzo para exponer mis puntos de vista y quizás aprender un poco de la reflexión y los comentarios de la audiencia. Así que bienvenidos sean!

Feliz año 2011!!! Pronto compartiré nuevas reflexiones con Uds.

viernes, 16 de enero de 2009

2008: El año de los métodos no convencionales de desarrollo de software

Luego de un largo y profundo silencio en las publicaciones, me veo nuevamente inspirado para escribir. Ese silencio tenía mucho que ver con una pausa necesaria para pensar, especialmente por las vertientes académicas y profesionales que generalmente me inspiran a hacerlo. El 2008 fue un año muy movido tanto en lo académico, profesional y en lo personal - ahora soy un hombre casado :D.

La actividad intelectual a lo largo del año 2008 estuvo muy centrada en lo que yo llamaría métodos no convencionales de desarrollo de software, distinto a lo que habitualmente se consigue en el mercado que suele oscilar entre programación heróica (code-and-fix) y métodos prescriptivos de desarrollo, también conocidos como heavy-weight (como RUP o aquellos hechos en casa con certificaciones CMM-CMMI).

De hecho, algo de esto se puede extrapolar de mi publicación anterior, donde mencionaba mi participación en el CIBESS 2008 donde hice una presentación que analizaba el método de desarrollo del software libre, el Bazar, como lo denominó Eric S. Raymond en su archiconocido ensayo, La Catedral y El Bazar.

Además del caso del Software Libre, hay dos fuentes más de ideas que sobre las que he estado estudiando. Una, ha sido el Desarrollo Ágil de Software. He sido fuertemente seducido por las ideas que tras esta filosofía se esconden, la mayor parte de ellas nada contrarias a lo que proponen muchos de los métodos prescriptivos de software. Sin embargo, consigo mayor seducción en las ideas que muchos consideran subversivas y que son parte esencial de esta manera de hacer software. Un buen sitio para comenzar con estas ideas es sin lugar a dudas el Manifiesto Ágil que pueden encontrar aquí.

La otra vertiente de la que he estado extrayendo ideas es el mundo de la Web 2.0. Entender que esto es una actitud, una filosofía, antes que una tecnología o un grupo de ellas, es una herramienta poderosa; la masificación y la descentralización en la producción de contenidos ha llevado a la web a un nuevo estadio. ¿Qué mejor ejemplo que la popularización en la publicación de contenidos que un blog como en el que hoy escribo?. Gracias al poder detrás de esta actitud, han surgido ideas acerca de como aprovechar dicho poder en las organizaciones y para muestra aquí tenemos un ejemplo. Ello me llevó también durante el año pasado a hacer una aproximación de como podemos sacar provecho de esta actitud en el desarrollo de software, propuesta que llevé a las pasadas XXI Jornadas Infociencias de la UCLA en Barquisimeto, Venezuela, con el nombre de Desarrollo de Software en la Web 2.0.

Desarrollar software hoy por hoy sigue siendo considerada una tarea altamente compleja, que sigue siendo estudiada en el mundo académico y la Crisis del Software sigue siendo tan vigente como hace 40 años, aunque en menor medida. Cada método de desarrollo de software viene (o debería venir) con su lista de excepciones a las condiciones bajo las cuales no puede ser aplicado, porque es ampliamente aceptado que no hay una bala de plata para resolver todas los distintos sabores del desarrollo de software. Ante este escenario, la búsqueda de métodos alternativos como estos que les he resumido es perfectamente válida para responder a la pregunta de: ¿Que hacer si mi proyecto cae justamente en los casos no cubiertos por los métodos conocidos de desarrollo de software?

En futuras publicaciones, ahondaré en cada uno de estos métodos no convencionales de desarrollo de software.

lunes, 10 de marzo de 2008

El Software Libre rompiendo paradigmas en CIBESS



Aprovechando el valor aportado por las investigaciones académicas y el trabajo del día a día, desarrollé una investigación personal de la comparativa entre las metodologías de desarrollo de Software Libre y las tradicionales de manera de incentivar la evolución de la manera en que desarrollamos software, sea o no libre, y generar valor a partir de tomar lo mejor de diferentes mundos.

Esta investigación personal culminó en un logro que no me esperaba, y pude hacer llegar mi mensaje a una audiencia estudiantil bien nutrida en la pasada edición de CIBESS. La receptividad del público fue excelente en realidad.

Pueden encontrarse la presentación usada en mi ponencia en CIBESS en el siguiente link.

Esto es un verdadero incentivo a seguir produciendo conocimientos (o al menos dudas) entorno al arte y la ingeniería del software.

Gracias amigos de CIBESS y DBACCESS, por darme la oportunidad de extender mi mensaje y mis ideas.

Impulsando el Arte en la ingeniería y la Ingeniería en el arte

Luego de un gran período de silencio, de dedicarme a recuperar las energías luego de un año intenso y de recuperar un poco de mi salud, he vuelto a las andanzas y a la inspiración para escribir.

Pero bien, retornemos a nuestra tónica acostumbrada.

Recientemente, mientras estaba en esta recuperación necesaria, volví un poco a las preguntas canónicas del desarrollo: ¿Cual es la mejor manera de hacer las cosas? ¿Cómo evitar los problemas de la archiconocida Crisis del Software? ¿Cómo cubrir con las expectativas de tiempo y costo sin tener que llegar a la pérdida de la salud, de la motivación o las energías?. Estas preguntas son habituales en aquellos que hemos presenciado proyectos desastrosos y deseamos evitar presenciarlos nuevamente.

Un poco con esto me recuerda el caso de Fred Brooks, quien luego de pasar por un episodio desastroso con la administración del proyecto del OS/360 en IBM, decidió dedicarse al mundo académico y a escribir ensayos clásicos de ingeniería de software como The Mythical Man-Month y No Silver Bullet.

No me parece absurda la conclusión de que luego de experiencias duras en el desarrollo de software comenzamos a pensar en mejores técnicas de desarrollo, en reforzar los procesos usados; en general, en Ingeniería de Software y en como implementar una metodología de desarrollo reforzada para evitar. Claro que no existe la panacea (idea esta dibujada en el mencionado ensayo No Silver Bullet), pero igual uno espera conseguir un mecanismo para disminuir riesgos en el futuro.

La metodología de desarrollo de software es un determinante del éxito del proyecto, de esto no me queda la menor duda. No obstante, hoy por hoy no existe la metodología que lo resuelve todo; una metodología no se va a adaptar completamente a todos los distintos casos, ni podemos esperar que una receta de cocina vaya a funcionar para todos los imprevistos y todas las situaciones inesperadas que la Ley de Murphy va colocando a lo largo de nuestro trayecto. Lo que les puedo asegurar es que un proyecto que no define su metodología (sus actividades, sus prácticas, sus técnicas, sus herramientas y sus estándares) va más derecho al fracaso del proyecto que a su éxito. Recordemos que un proyecto no es exitoso sólo porque su producto funcione, sino que hace falta que cliente, equipo de desarrollo y producto puedan (y/o quieran) seguir avanzando en sus relaciones de manera fructífera.

En mi humilde opinión, una metodología debe aportar los líneamientos necesarios de ingeniería que aporten valor sin ralentizar en demasía el avance y debe permitir el nivel suficiente de libertad para permitir que los artistas de software expresen su creatividad sin mayores ataduras.

Próximamente, hablaremos de las técnicas más útiles encontradas en diferentes metodologías.

viernes, 13 de julio de 2007

De la tecnica al arte: La evolucion del conocimiento

Prepararse y mantenerse al día en Tecnologías de Información es un trabajo bastante duro puesto que requiere manejar mucha información. Si quisieramos mantenernos al día por recibir cursos universitarios formales, o por capacitación en talleres, quizás pasaríamos más tiempo recibiendo información, que usándola y compartiéndola.

No. Definitivamente ser un profesional de TI requiere ser o convertirse en un autodidacta, o prepararse para la extinción.

El trabajo de un autodidacta debe comenzar por entender de que manera aprendemos y tener una disciplina de autoaprendizaje. Nótese que es un trabajo bien personalizado, donde afectan elementos como nuestra disposición al aprendizaje visual, auditivo y kinestésico (http://www.vaknlp.com/es/), así como otros elementos.

Como buen autodidacta, me dediqué en gran parte de mis estudios formales a encontrar el mejor mecanismo para disponer la información de manera tal que fuese bien sencillo aprenderlo. De esa manera comencé a dar mis primeros pasos en el mundo del desarrollo de software, aunque mucho de ese mecanismo lo aproveché mientras estaba sacando la ingeniería.

He querido exponer mi sistema de autoaprendizaje aqui, porque también pude aprovecharlo para dictar algunos cursos de programación en mis años universitarios, y resultó ser un muy buen mecanismo para enseñar, especialmente a quienes sentían que requería mucho esfuerzo el aprender a programar. Con el tiempo, esto se convirtió en mi filosofía personal acerca del conocimiento.

En mi humilde opinión, la adquisición del conocimiento práctico (como lo es la gran mayoría de los conceptos en TI) comienza por el hacer, por la técnica. "Aprender haciendo" es una consigna que es verídica. "Uno aprende el 40% de lo que lee, y hasta el 60% de lo que escribe; pero aprende casi el 90% de lo que hace", afirmaba Manuel Marco Méndez, uno de mis profesores en la universidad.

Si quieres aprender carpintería, debes comenzar por conocer las herramientas, por entender las técnicas de serruchado, el uso de la sierra, de la lija y el sellador. Las propiedades y usos del aserrín, y la mejor técnica para clavar. Podrás convertirte en un carpintero.

Pero la técnica no lo es todo: Aqui podrás dominar lo que se hace, pero no podrás tener el completo contexto de que promovió que se hiciese de esa manera, o como podrías optimizar tal proceso. Aquí es donde la ciencia se hace importante: Entender el por qué de las cosas. Conocer las teorías, los conceptos, las relaciones subyacentes hará que entiendas la razón de ser de las técnicas; no sólo podrás dominarlas con las manos, sino jugar con ellas a voluntad con tu mente.

Por muy poco probable que parezca el que ocurra en la realidad, un carpintero definitivamente se vería beneficiado por el aprendizaje de geometría y trigonometría. Entender las diferencias estructurales en las maderas de distintos árboles. Quizás entender la química de la madera, y el estudiar si algún proceso químico en particular tiene la capacidad de dar propiedades distintas a las maderas que serán usadas en la construcción de algún mueble o herramienta. Por la unión de técnicas y ciencia, y la aplicación de esta última, sería el equivalente a un ingeniero de producción maderera ;)

Pero de nada serviría el mezclar distintos conocimientos teóricos y pragmáticos si tan solo son usados para usufructo. Estos conocimientos pueden ser usados para generar más conocimientos! Esa es la manera en que evoluciona la ciencia y la tecnología a lo largo de la historia de la humanidad. Sin embargo, en ese punto el proceso ya no es más estructurado, sino completamente un arte, caótico, generando un rocío de ideas a partir de las más intensas tormentas del pensamiento. Para esto sólo un ingrediente adicional es requerido: Creatividad.

El ingeniero carpintero, ya luego de manejar a su antojo las técnicas y la teoría detrás del desarrollar un mueble, perfectamente puede comenzar a hacer experimentos y a dejar que la creatividad genere, a partir del caos, los más sublimes resultados. Ya no es más un simple martillador de clavos, o un científico de la madera. Ahora es un artista. Ahora es un ebanista.

Creo firmemente que la evolución técnica - ciencia - arte puede ser esbozada, tal como en la parábola del carpintero, para diferentes áreas del conocimiento, y el desarrollo de software y las TI no son una excepción. El conocer las técnicas, entender la ciencia y las razones detrás de ellas, así como una gran dosis de creatividad, podrán llevarnos al nivel donde podamos considerarnos como verdaderos artistas del software.

jueves, 12 de julio de 2007

Filosofía: Madre de todas las cosas.

Los profesionales en áreas técnicas, especialmente en Tecnologías de Información, tenemos una fuerte tendencia a querer pretender que el proceso de cultivar frutos y vegetales es ir directo al campo a cosechar y comenzar a comerlos o comercializarlos. Es bien conocido en esta área del conocimiento el síndrome del profesional que no espera terminar de escuchar un requerimiento (o una forma primitiva de algo parecido) para comenzar a codificar una solución.

Menos específico que el ejemplo anterior, está el hecho de que queremos ser expertos en las herramientas y en las técnicas sin remitirnos primero a los por qué, a las preguntas y necesidades que promovieron la existencia de esas herramientas y técnicas. Pareciera que se convierte en condición suficiente el saber que para alguien fue una buena idea el construir tal o cual herramienta como para decidir comenzar a probarla, o peor aún, a usarla en un proyecto ya en progreso.

Yo soy un firme creyente de que el saber y entender los por qué de las cosas te permite tener un nivel que no vas a lograr por mucho que conozcas los más rebuscados detalles técnicos de una herramienta o una técnica. Generalmente, los por qué nos llevan al trasfondo filosófico que generalmente podemos encontrar de cualquier ciencia o arte.

Es bien importante tener esto claro, porque es muy normal que mientras nos encontramos abarrotados de cosas por hacer, en un proyecto lleno de dolores de cabeza, de tiempos ajustados y de presiones de clientes y superiores, nos limitamos al cumplimiento cuasi mecánico de aquello que nos piden, buscando no la mejor, y ni siquiera una buena solución, sino con la primera que nos topamos, para salir del paso. Allí, casi ni analizamos lo que vamos a hacer sino que lo que hacemos se convierte en movimientos anaeróbicos que pueden conducirnos a meter más dolores de cabeza, más actividades por hacer en menos tiempo, y por consiguiente, más presión por parte de clientes y superiores.

Mucha gente desdeña de la filosofía por considerarla difícil de entender, además de inutil. Nada más lejos de la verdad según lo veo yo, pero es una cuestión de utilizar lo que necesitas en el momento indicado. No se trata de que todos seamos expertos filósofos, como quizás no podríamos serlo en todos los aspectos de nuestra vida. Pero si hay un área en la que te muevas más que en otra, esa área se convierte en fuerte candidata para que conozcas la filosofía detrás de ella, para que entiendas los por qués.

Entender la filosofía sobre la que se basa una ciencia o área del conocimiento te permite colocarte en el punto de vista indicado. Entender el por qué es importante un código bien documentado marca la diferencia entre sentarte con calma a ahorrarte horas de sufrimiento en meses futuros y sentirte frustrado a hacer una cosa inútil que tu jefe y el cliente quieren que tu hagas y que no va a servirle a nadie. El primer consumidor de la documentación de un código es el mismo desarrollador que la escribe, y de no ser así, va a serlo alguien de su mismo equipo de desarrollo. Desde este punto de vista, no documentar un código, especialmente si sabemos que lo que implementamos no ha sido fácil de hacerlo, es lanzar un boomerang que nos lastimará en el futuro o nos convierte en pésimos compañeros de equipo.

Detrás de casi todas las decisiones, incluso las más ininteligibles, hay un por qué, una filosofía. Conocer esos por qués es un arma para seguir avanzando en la aventura de vivir, sea en TI o en algún otro área del conocimiento. Esta también es la razón por la que se hace importante el conocer la historia, sea la de tu país, la universal, la de tu empresa, la de la ciencia o arte que dominas, o la del proyecto en el que estás atascado.

Asi que, cuando vean una persona que pregunta el por qué cuando le informan de una decisión extraña, no es simplemente un preguntón impertinente, es alguien en busca de poder y conocimiento para su futuro :).