Programar debería ser algo sencillo.

6 octubre 2008

 

No pongo en duda los avances realizados en el desarrollo de software, pero a veces me pregunto si  no se tomó el camino más complejo para evolucionar.

 

Programar en COBOL, era algo muy sencillo. Tenías un lenguaje con unas 200 o  250 sentencias, de las que habitualmente usabas 50 o 60. Y con eso,  se podía construir todo.

 

Hoy,  si hablamos de las plataformas de desarrollo actuales, posiblemente estemos hablando de que para resolver un problema utilizaremos varios lenguajes, con distintos estilos, con los que dispondremos de un catálogo con  miles de funciones. Es cierto que podemos hacer muchas más cosas, pero a costa de añadir una complejidad mucho mayor.

 

Y en medio de todo esto, algo de aire fresco, aparecen dos herramientas , Scratch y Popfly Game Creator. Las dos sirven para lo mismo, crear juegos y animaciones multimedia digamos que uno es un juguete para niños (Scratch) y el otro para jóvenes (Popfly).

 

 

 

 

De una forma fácil e intuitiva (mas en Scratch que en Popfly), y sin saberlo, ¡se está programando!

 

Detrás de Scratch está el Instituto Tecnológico de Massachusets (MIT), detrás de Popfly, Microsoft.

 

Quizás no sean más que juguetes, pero quizás sean, las bases de las futuras herramientas de desarrollo que se utilizarán profesionalmente.

 

Si es así, yo apuesto por este camino. Vivimos en un mundo, en el que se usan el burro y el jet como medios de transporte. Igual sucede en las tecnologías de la información, junto con las últimas novedades conviven sistemas basados en tecnología de hace 40 o 50 años, y todo de una forma más o menos armónica.

 

Si Scratch o Popfly, son un adelanto de lo que serán las herramientas de desarrollo del futuro, esto permitirá que quienes ahora guían un burro, o conducen una bici,… Puedan en un futuro muy cercano guiar un nuevo medio de transporte con las ventajas de un jet y la simplicidad de una bici


Metodologías, frameworks y estándares para el desarrollo de software. ¿Cómo lo he visto y cómo lo veo?

12 septiembre 2008

Mi primer contacto profesional con una metodología estándar, en este asunto de desarrollar software, sería allá por el 96 o 97. Nuestro cliente planeaba usar Métrica, la metodología de desarrollo de software de la administración española. Y nosotros nos adelantamos, utilizándola en todos nuestros trabajos. Yo creo que con ello abrimos cierto escalón de calidad entre nosotros y el resto de proveedores de nuestro cliente con los que competíamos, y eso nos hizo crecer de manera importante.

Este hecho, creo que me influyó decisivamente, y me hizo tener una visión, al menos durante unos años, bastante ortodoxa en el desarrollo de software.
Desde entonces, he tenido tiempo de conocer y trabajar con otras metodologías. He tenido tiempo creer en determinados planteamientos, y más tarde de abandonarlos y creer en los contrarios. Así que sirva mi experiencia personal, para contar un ejemplo de cómo se ha movido el mercado en estas cuestiones en la última década.

Como decía allá por el 97, comencé con métrica v2, el nivel de detalle de esta metodología permitía casi, poner el manual encima de la mesa y comenzar con el análisis de los sistemas. Fue necesario un esfuerzo importante en el primer proyecto, pero después solo había que seguir el manual punto a punto. Creo que lo mejor de métrica, además de que ofrecía un perfecto guión para todo el análisis era, que sus resultados eran comprensibles prácticamente para cualquiera, sin necesidad de ser técnico.
De este periodo de métrica, me quedo con dos cosas, por una parte, el orden y la calidad que aportaba el método, y por otra, con un comentario que uno de los clientes nos hizo y que ahora detallaré. Habíamos desarrollado un análisis que superaba el millar de páginas, durante la implantación del sistema, el cliente se quejó del funcionamiento de un módulo, y yo le dije “el módulo funciona según se recoge en el capítulo tal del análisis”. Nuestro cliente cogió uno de los volúmenes en los que habíamos encuadernado nuestro trabajo y mientras lo levantaba mostrándomelo, me dijo “¿tú crees que yo tengo tiempo para leerme esto?”
En aquel momento me resultó insultante, más adelante me pareció una estupenda lección que, como ahora hago, he citado en más de una ocasión.

Más tarde en el año 2000, en otra compañía y en otro negocio, tras decidir que los futuros sistemas irían hacia un entorno web, hubo que definir y decidir cómo se trabajaría. El análisis y la programación estructurada ya no nos servía. Después de estudiar cual debía ser el camino, elegimos RUP (Rational Unified Process) como framework para nuestros desarrollos. Realmente, mirándolo con la distancia que da el tiempo, el principal motivo de la elección fue que era lo que todo el mundo estaba haciendo: todo el mercado no podía equivocarse. Elegimos un proveedor para hacer un importante desarrollo, nuestro planteamiento fue, nosotros haremos un análisis utilizando las “antiguas” técnicas de programación estructurada y nuestro proveedor debía “traducirlo” a orientación a objetos utilizando RUP y Rational Rose. Ellos eran expertos y nosotros no. De la etapa de RUP, también me llevé varios aprendizajes:

RUP no solo era un framework para el desarrollo de software, se había convertido también en una “buzzword” (termino que utilizan los anglosajones para aquellas palabras rimbombantes que se ponen de moda y están en boca de todo el mundo), y como tal todo el mundo se proclamó defensor, conocedor y experto de RUP. Yo no tenía intención de aprender RUP, pero como el proyecto fue mal, no me quedó más remedio. Fue entonces, después de días y días de estudio de UML y RUP, cuando me di cuenta de que todo el mundo hablaba de RUP pero pocos sabían de lo que hablaban y muy pocos estaban capacitados para trabajar con esta metodología, en mi opinión, tremendamente compleja, pesada y difusa. Primera enseñanza, cuidado con los expertos, si realmente no lo son, sus efectos pueden ser nocivos, y segunda enseñanza, en ocasiones la marcha atrás no es posible. Cuando esto ocurre, caben dos posibilidades seguir hablando de las excelencias de la decisión que se tomó, o bien, admitir que la decisión no fue la mejor. La situación no es buena con cualquiera de ellas, por que lo esencial es que la decisión fue equivocada. Pero esta es otra historia, yo estaba hablando de metodologías.

La cuestión en aquel punto es que necesitaba reorientar los análisis y puesto que había aparecido la versión 3 de métrica, que soportaba orientación a objetos, esta fue la elección. Al menos, métrica centraba más las cosas, y era más sencillo implementar el análisis que con RUP.

Y así seguí hasta 2005, pensando que RUP continuaba siendo el estándar, aunque a mí me resultaba tremendamente pesado y complejo. En verano de 2005 comenzó una temporada en que tuve tiempo para reflexionar sobre todo esto (acababa de ser despedido). Me venía a la cabeza aquel comentario que antes citaba, realizado 6 años atrás y referido a un tocho de análisis de más de mil páginas. “¿Tu crees que tengo tiempo para leerme esto”?. Por otra parte pensaba en lo poco explicativos que resultaban para los usuarios los diagramas de casos de uso (de utilización extensiva en RUP), y me pregunté, por que narices los informáticos obligábamos a nuestros clientes a que utilizasen nuestras técnicas de diagramación, en lugar de ser nosotros quienes utilizásemos las suyas. Hablé con unos cuantos compañeros y amigos (Gente de empresariales, económicas, ingenieros, MBA’s) y les pregunté que tipo de técnicas os han enseñado para definir procesos de negocio. La respuesta fue unánime: ninguna. Así que me dije a mi mismo, debes salvar al mundo de los sistemas de información (entiéndase el tono jocoso) y crear una metodología basada en las necesidades de los clientes y no al revés.

Comencé a esbozar algunas ideas al respecto, hasta que di con la palabra clave: “Ágil”, es sabido que las cosas no existen, hasta que no das en en Google con la palabra adecuada, y una vez que la encontré me enteré de que hacía no mucho, que se estaban iniciando con fuerza lo que se venían a llamar “Metodologías ágiles” de desarrollo de software, mas o menos en línea con las ideas que yo tenía. Mi primer sentimiento, fue de rabia, ya estaba inventado lo que yo iba buscando. El segundo fue de todo lo contrario, me sentí satisfecho por evolucionar hacia una tendencia relativamente nueva, luego mis ideas y mis planteamientos eran buenos.

No obstante, en ese momento, no quise aprender nada más sobre “métodos ágiles”, pensé que si leía más al respecto, me condicionaría y no me permitiría ser creativo.

Entre notas y notas sobre el tema, iba haciendo algunos cursos dirigidos a emprendedores, un compañero de curso me dijo sobre mi idea. Lo que dices, suena muy bien, pero, ¿alguien te lo comprará? Tras resistirme durante unos días a reconocerlo, finalmente me di cuenta de que la respuesta era muy simple: NO, así que…, abandoné la idea.

Sería principios de 2006, y ahí se inició un paréntesis en mi relación con las metodologías de desarrollo de software, que duraría hasta verano de 2007, cuando comienzo un periodo como consultor y he de trabajar con la metodología utilizada por una gran empresa para la que trabajaba.
En aquel momento, su metodología me parece un refrito de UML con algunas técnicas de modelado de procesos, donde habían quitado protagonismo al modelo de casos de uso. Pero, hace muy poco que he leido algo sobre UML 2.0 y también sobre el estándar de OMT para la definición de procesos de negocio (BPM) y pensándolo, quizás se hubiesen basado en ello al definir esta metodología.
El caso es que me seguía pareciendo compleja, no me parecía que se hubiese evolucionado y pensaba que no aportaba gran cosa respecto a RUP.

Así que, me interesé de nuevo por lo que había en el mercado, y descubrí Microsoft Solutions Framework (MSF) en su version 3.0 (que no era novedad, pero sí para mi). Me pareció excelente, potenciaba el trabajo en equipo y la creatividad, promovía que cada etapa fuese dirigida por quien más capacidad tuviese para ello, había oido hablar y algo había leido también sobre “empowerment” y equipos de alto rendimiento (perdón por los palabros), pero no tan en detalle como MSF lo proponía y por supuesto no aplicado al desarrollo de software. Así que estuve durante un tiempo interesándome por el tema. Leí también sobre eXtreme Programming, que basa sus técnicas en el desarrollo entre pares y la velocidad de proporcionar al cliente prototipos tan rápido como sea posible. Y también sobre Scrum, excelente para plantear la estrategia de los proyectos a corto plazo. XP no es demasiado de mi agrado, si lo es sin embargo Scrum, al igual que las nueva versión de MSF para entornos “Ágiles” (la versión para CMMI me resulta pesada).

Paralelamente a esto, un día curioseando en una librería, hojee “Lean Thinking”. El “Lean Thinking” basado en el sistema de producción de Toyota, tiene como máxima el evitar desperdiciar tiempo y recursos, haciendo solo aquello que realmente sea necesario (¿Software en producción que nunca ha sido utilizado? ¿Le suena a alguien?), así que lo incorporé a mi pensamiento actual.

Por otra parte también tuve la oportunidad de aprender algo sobre Six Sigma, un método orientado inicialmente a garantizar la calidad en procesos industriales. Aunque 6 Sigma me resulta demasiado pesado, me quedo con su método para definir objetivos, centrado en las necesidades del cliente (“la voz del cliente”) y la percepción que el mercado tiene de nuestros productos y de los de nuestra competencia. A partir de aquí obtendremos objetivos mensurables que llama CTQ’s (Critical to quality)

Sinceramente, creo que pretender continuar con metodologías “pesadas” es un error, y comprendo que en grandes empresas prescindir de ellas es complicado. Pero creo que es el camino a seguir, sirva el ejemplo de los padres de UML y Rational, moviéndose hacia lo “ágil”

Así pues, si tuviera que elegir escogería algo así como el Framework”de Microsoft, tomando planteamientos e ideas de Scrum, Lean y Six Sigma. Pero sobre todo me quedo, como decía en un post anterior, con el “Think” que Thomas J. Watson llevó primero a NCR y después a IBM. Cada problema, cada proyecto, cada empresa son diferentes y no hay ningún guión escrito para ellos, esto no significa que los procedimientos y métodos no nos ayuden, todo lo contrario, pero debemos tener siempre presente que lo realmente importante es la resolución del problema, y no la metodología, que solo será un medio para conseguir el objetivo.


Genial, fácil, simple: Scratch

2 septiembre 2008

Si buscais un entorno de programación simple e intuitivo, Scratch es lo que andabais buscando. Solo tiene un problema, esta pensado para los niños, habrá que esperar que alguien haga algo así para uso profesional.

En lo que yo conozco, las herramientas de programación, como mucho contaban con editores que añadían algun color en el código del programa para identificar ciertas estructuras y facilitar de esa forma la lectura.

El MIT ha hecho algo tan simple y fácil como sustituir los comandos escritos de un lenguaje de programación por formas y colores, con los que solo hace falta pinchar y arrastrar. El objetivo de los programas realizados con Scratch, de acuerdo con el público al que va dirigido, son animaciones y juegos.

Para que os hagais una idea, un niño de nueve años  sin ningún conocimiento previo de programación, en cinco minutos ha realizado su primer programa, que puede subir a la web de Scratch pulsando solo un botón. Y lo mejor de todo, durante todo el tiempo lo único que ha hecho ha sido jugar.

Espero que en el futuro podamos decir: Me voy a la oficina a jugar con Scratch