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 :).

miércoles, 11 de julio de 2007

Y así zarpamos

Dicen que la necesidad es la madre de todos los inventos, y yo estoy de acuerdo con tal dicho.

La lejanía y el cambiar de ambiente te ponen en la necesidad de expresarte de distintas maneras, así como el comunicarte con interlocutores en una lengua que es extranjera para ellos y para ti te acerca más al expresarte en tu idioma materno.

El conocer y convivir en una cultura distinta no puede sino hacerte cuestionar tu propia cultura, y ese cuestionamiento te permite ver tus fortalezas y tus debilidades de una mejor manera. La presión, por su parte, coloca al carbon en la necesidad de convertirse en diamante, y si bien algunas personas no reaccionan en su momento mejor que otras a la presión, definitivamente la existencia de alguna presión tiene un mejor efecto que no tener presión alguna.

El desarrollo de software es una actividad compleja y riesgosa, más de lo que se podrían imaginar muchas personas que simplemente asumen que algo invisible no puede ser tan difícil de hacer. Si lo ves como un arte, piensa en el hecho de que ningún cantautor tiene detrás a los fans (quienes pagan sus álbumes o las entradas a sus conciertos) exigiéndole que tenga N número de canciones en X cantidad de días. Si lo ves como una técnica o una ingeniería, tan solo imagínate que tan difícil puede ser construir una casa si cada vez que se echa una base el cliente final decide que ya no la quiere de 3 hab. y 2 baños, sino con 4 hab. y 3 baños.

Mucho se ha dicho y escrito del software, y aún así sigue vigente la Crisis del Software. Aun se siguen cancelando proyectos, aun conseguimos a profesionales del área deseando cambiarse en cuanto puedan del ramo. ¿Qué es lo que no estamos haciendo bien? Necesitamos sentarnos a estudiar un poco más el trasfondo detrás de esto.

Me encuentro en este momento en India, la potencia en cuanto al desarrollo de software se refiere. Las más grandes empresas de desarrollo están aquí, y se habla de niveles de calidad casi insuperables. No, no son extraterrestres, y por lo que he visto no están muy distantes de nosotros, latinoamericanos. ¿Que es lo que marca la diferencia?

La intención de este blog, que estreno en este momento, es abrir una tribuna donde disertar sobre detalles ya sean generales, ya un poco más específicos, pero que se sitúen alrededor del desarrollo de software, de la filosofía que debe privar mientras estamos tratando de conseguir la verdadera escalera que nos saque de la ya archiconocida Crisis del Software.

Bienvenidos a mi blog. Saludos desde esta parte del mundo, mientras pronto espero volver a mi amado país.