Tags: leanagile SG07

El ejemplo mas interesante de estos trabajos, es el realizado con el Marco de Evaluación de Sistemas de Manejo incorporando Indicadores de Sustentabilidad (MESMIS). Este es un esfuerzo por crear una metodología de evaluación de prácticas de sustentabilidad para los recursos naturales, que permita indicar qué tan abastecidas o no son las prácticas de explotación de los recursos naturales de un lugar determinado. Este trabajo ha sido reconocido a nivel mundial y es producto de varios investigadores mexicanos agrupados en el Grupo Interdisciplinario de Tecnología Rural Aplicada (GIRA). El trabajo de Luis en este equipo ha sido, introducir un elemento dinámico y sistémico con la finalidad enriquecer a MESMIS logrando extenderlo mas allá de un marco de evaluación hacia una herramienta de educación para la sustentabilidad rural.

El MESMIS interactivo cuenta con 4 capítulos de los cuales 2 son simuladores de sustentabilidad. La idea es lograr que las personas participen de una forma activa a través de un drama en tres actos que les muestre los problemas reales en la toma de decisiones de sustentabilidad combinando simulaciones de software, elementos teatrales y de juegos de rol.

En el primer acto se muestra una cuenca donde todo era bosque, luego diez familias llegan y desmontan 100 hectáreas con siembra. Al cabo de décadas con el crecimiento de la comunidad y los diversos apoyos gubernamentales para el campo, la mayoría de ellos implementados sin tener en cuenta los principios de sustentabilidad. El gobierno en respuesta, crea una área protegida y reduce la superficie para las familias, por lo que los campesinos ahora tendrán que recurrir a uso de fertilizantes para poder sobrevivir con el terreno reducido. En el software, los usuarios van viendo simulaciones a través de series de tiempo, dinámicas, puntos de equilibrios y diversos umbrales para ver de que forma este sistema simulado reacciona ante estas estrategias de explotación.

En el segundo acto, aparecen nuevos personajes, los pescadores del lago al final de la cuenca y los dueños comunitarios de una villa eco turista. En esta etapa, se aprende que el uso de fertilizantes para lograr mayor productividad afecta de forma muy clara la ecología del lago, que además es mucho mas difícil restaurar que un sistema terrestre. Mostrando el escenario de la cuenca, los participantes pronto descubren que es imposible encontrar una combinación del manejo de recursos que deje satisfechos a todos los actores. El drama de la utilización de los recursos naturales que tanto nos esta afectado de forma global se manifiesta.

La resolución se obtiene en el tercer acto, donde los participantes aprenden que los diferentes actores deben de ayudar a crear un sistema equilibrado. En el caso particular de la cuenca, la solución del problema proviene de apoyos que las comunidades del lago y la villa eco turista proveen a los productores del campo cuenca arriba, para utilizar combinaciones de árboles que permiten reducir el fertilizantes.

Una de las historias mas inspiradoras es la del programador que ayudó a realizarla, un voluntario llamado Max Pimm; matemático inglés, residente en Barcelona desde hace 5 años, quien se entera del proyecto MESMIS y viaja a México para trabajar como voluntario con el grupo de investigadores de GIRA. Posteriormente se entera del trabajo de Luis con la propuesta de generar modelos interactivos de MESMIS . Inspirado por el potencial del proyecto trabajó por 3 meses en los cuales logró generar todo el sistema. Según sus propias palabras, lo mas importante fue la posibilidad de ver su conocimiento aplicado en un trabajo participativo con gran significado.

Actualmente, el equipo con nuevos voluntarios trabaja en el futuro de MESMIS Interactivo. Las próxima versiones, incorporarán desde el diseño del sistema a todos los actores sociales en una plataforma donde se puedan modelar los problemas en un territorio especifico y la gente pueda explorar las consecuencias y que puedan entender sus decisiones sobre sus ambientes a traves de simulaciones interconectadas en red. Se prevee usen tecnología de vanguardia en la simulación de agentes autónomos y motores de inferencia para las reglas del sistema.

De mi parte un agradecimiento sincero a Luis García Barrios por su trabajo y ser fuente de inspiración para quien escribe. Para ustedes, amigos lectores, la invitación a conocer, en sus entornos locales, qué trabajos de investigación se están haciendo, para que además de que haya voluntarios que cruzan de otro continente a colaborar, existan también voluntarios mexicanos aportando en tan valiosos esfuerzos.

Para mí todo comenzo con una llamada de Eduardo quien me comento que una amiga bloguera suya, Berenice estaba en un albergue ayudando como voluntaria y necesitaban resolver un problema de sincronización de hojas de calculo que tenian en los dos principales albergues de Villahermosa. Al llegar allí, me encontré con una pequeña red improvisada y el problema era que no podian obtener un censo fidedigno de los albergados por que habian muchos duplicados al capturar en hojas de cálculo y era claro que se necesitaba una base de datos. Al hablar con Margarita, la coordinadora del albergue, me menciono que en en la televisora local TVT en un edificio contiguo, había otro grupo de voluntarios ya había logrado reposicionar una aplicación en PHP originalmente diseñada para un congreso, como una improvisada base de datos para recibir la información de todos los demás albergues enviaban por fax, USBs y diversos medios. Nos recomendó hablar con ellos para ver si ya habia algo que se pudiera aprovechar para ayudarlos con su problema.

Al llegar a TVT nos encontramos con un grupo de voluntarios capturando en la aplicación que Isaac habia logrado reprogramar, para que la televisora registrara a todas las personas y se pudiera procesar las llamadas de la gente preguntando por sus familiares. Desafortunadamente, como todo era improvisado, la red LAN de TVT no tenia acceso a internet y eso retrazo la consulta en internet de la página. Aparecieron entonces otro grupo de voluntarios encabezados por la gente de compañias de sistemas de la ciudad que ofrecieron un servidor para respaldar periódicamente el sitio completo de php y la BD de mysql a otro servidor en internet y poder dar lo que era el servicio de información mas valioso en ese momento para los tabasqueños, poder ubicar a sus familiares y amigos.

La necesidad de los albergues en si no se podia cubrir con la aplicación de PHP, por que los albergues requerian de información diferente a la que TVT estaba registrando, asi que la solución que se encontró para ellos, fue hacer uso de un servicio de Web 2.0 llamado Zoho Creator, que en esencia es un constructor de formas de captura basado en Web sin necesidad de programar. Con esto se pudo crear en cuestion de minutos un sistema de captura distribuida basada en internet que podía ser utilizado en línea en cualquier lugar con conexión a internet, que a diferencia de la telefonía fija y celular, fue el único servicio estable durante la crisis. Eduardo escribió un correo a los creadores del Zoho Creator por si necesitábamos ayuda en algo que no cubriera el servicio y Charles se comunicó con nosotros por gtalk desde la india para ponerse a nuestra disposición. La oportunidad de ayudar para el equipo de Zoho Creator llegó, por que necesitábamos subir archivos CSV que nos llegaban masivamente a Zoho y usando la forma oficial de subirlos, un API de WebServices basado en REST iba a requerir programar un poco. Se ofrecieron un par de voluntarios, pero unos minutos de chat con Charles lograron que nos mandara un pequeño programa de JavaSE para hacer justamente eso. Las maravillas del internet buena voluntad del otro lado del mundo.

Por otro lado, no podemos dejar de mencionar, la valiosa ayuda de algunos grandes amigos principalmente basados en el DF que acudieron con consejo, tiempo y algo de programación a soportar estos desarrollos, me viene a la mente la contribución de Alexandro Colorado con un desarrollo para replicar bases de datos, Suly al proveernos infraestructura de chats por scripts de gtalk, Vicente con su código para mashups con google maps y decenas de voluntarios virtuales que nos acompañaron sin parar durante esos dias de crisis a traves del grupo de google de ayuda@tabasco.

Con la aplicación de php, replicada en servidores públicos de internet, la aplicacion de Zoho Creator en línea, las necesidades de información y administración de los albergados resueltas, otros voluntarios como Romeo se dieron a la tarea de programar Mashups para que se pudieran localizar en google maps las ubicaciones físicas de los albergues en la aplicacion de búsqueda de personas. Los datos de localización geográfica para el aplicativo fueron proporcionados por gente del gobierno, que por su parte, algo así como una semana después, liberó aplicaciones que sustituyeron los esfuerzo de los voluntarios en los albergues.

Al paso de los días, nos llegaron rumores de que el Gobierno estaba haciendo las mismas aplicaciones oficiales en Java EE y con todas las funcionalidades corporativas comunes: Integración a LDAP, servidores de aplicaciones, bases de datos de a deveras. Pero el testimonio de los albergues con los que permanecimos en contacto fue mas o menos en concenso que lo que ofrecía el gobierno era demasiado complejo y difícil de usar. Una satisfacción mas para los voluntarios, libres del aparato burocrático, del miedo a correr riesgos, a la competencia de la “secretaria de enfrente”, estos jóvenes pudieron prestar un servicio inigualable en el momento justo que era requerido. Que orgullo ver que lo que tanto disfrutamos hacer pueda ser de utilidad. Muchas Gracias Eduardo, Berenice, Isaac, Romeo y todos los demas voluntarios por tener los ánimos y la voluntad de demostrar que la tecnología también puede ayudar a disminuir el sufrimiento, un verdadero ejemplo de como alcanzar el tecnonirvana…

Les debia a mis amigos este articulo de la labor en tabasco. Disculpas por el retrazo.

Mientras los reporteros peleaban con la señorita de los taxis que les decia que no importara que fueran de televisa simplemente no habia taxis, por que no podrian pasar, me acerque aun federal de caminos y le pregunte que si como llegaba a villahermosa. “Con lo que puedas mano, sal a la carretera y trepate a lo que pase…”. Viniendo de una autoridad, procedi a hacerle caso. Afuera, haciendo gala de la impresionante tranquilidad del tabasqueño, un par de taxistas lavaban sus coches como si fuera un dia normal. Les pedi consejo y me dijeron. “Mira.. picale..ese cambio de Halliburton vino por alguien al aeropuerto, trepate antes de que se llene…”

Al subir al camion, me contre a algunas personas un poco frustradas por que habian cancelado sus vuelos fuera de tabasco y ahora tenian que regresar a enfrentarse de lo que ya creian que lograrian evitar, el desastre en villahermosa. Al subir, pegado a mi radio escuchando los llamados de auxilio de personas que no encuentran a sus familiares desaparecidos. Lo primero con lo que me tope fue con una pareja con un bebe en brazos. Me contaron que venian huyendo de los albergues, por que a pesar de que se les atendia, no eran condiciones para tener a su bebe, un niño de 8 dias de nacido completamente cubierto de salpullido. Su esperanza era poder llegar con unos familiares que vivian en una rancheria en una loma camino a macuspana.

Despues de esperar cerca de 40 minutos a que el de Halliburton, que resulto ser que se queria ir de villahermosa se convenciera que no se podia ir, el camion, ahora con mas de 30 personas arriba empezo su marcha a villahermosa. Empezamos a recorrer el trayecto de tan solo 11 kilometros a villaermosa, un camino que he recorrido cientos de veces, la ultima hace tan solo 5 dias. No podia saber lo que me esperaba.

La desolacion era total, afortunadamente un bordo construido despues de la ultima inundacion esta realizando su cometido. Logra mantener gran parte de la carretera seca, pero con escurrimientos de cuando en cuando que hace que solo camiones y camionetas muy grandes puedan pasar. Los camiones y autos varados a la orilla de la carretera, mas la inundacion de los carriles hacia afuera de villahermosa, hacen que este recorrido de 10 minutos sea de 1 hora. Gente huyendo de villahermosa con todas sus pertenencias en una bolsa de basura mojada, llena de lodo y aun no llegaba a villahermosa.
Al llegar al la glorieta de Tabscoob, donde inicia la colonia Las Gaviotas, la verdadera magnitud de la inundacion cobra vida. Una señora a mitad de la calle, en evidente estado de shock, buscando algo perdido en medio de agua sucia. No supe que perdio, pero lo que halla sido estoy seguro no lo recuperara este dia. Personas, extrañamente, ancianos en su mayoria, apostados en segundos pisos y techos de las casas. Saludandonos, observandonos, preguntandose por que somos el unico camion que entra cuando todos intentan salir. Las gaviotas tienen en esta zona al menos 2 metros de agua. Ya nadie busca rescatarlos, eso seguro lo intentaron hacer ayer, estos son los que eligieron no salir. Cruzar el puente del griljava se vuelte una travesia de una hora. Nos volteamos a ver todos en el camion. Nadie habla. Los reporteros toman fotos, los camarogramos una que otra toma. Pero nadie dice nada.

Cruzando el puente hacia Ruiz Cortinez nos damos cuenta por que es tan lento el avance. Hay una corriente que cruza la avenida, ideada para sobrevivir a inundaciones tiene un metro de agua. Nos encontramos camionetas con familias que intentan salir y otros entrar. Caos. No hay un solo policia. Me recuerda tanto a un viernes de quincena con lluvia en el DF, todos quieren pasar primero. El chofer del camion se baja y empieza a poner orden. Baja a una señora histerica de su camioneta Lobo, que habia conseguido lo aparentemente imposible, atascar su camioneta en medio de un camellon de Ruiz Cortines. Otra media hora para bajarse a cargar la camioneta, y lograr pasarla para que no estorbara. Llevamos 50 metros de villahermosa recorridos.

Al avanzar sobre Ruiz Cortines entiendo por que el gobernador decia que habiamos perdido la “Batalla del Grijalva”. Una verdadera zona de guerra. Coches nuevos flotando en plena avenida. Gente con la mirada perdida, que no se sabe si van o vienen. A un lado, un camion volteado. Seguramente no sabian que la avenida tenia mas de un metro de desnivel, intento rebasar y acabo volteandose. Solo me acuerdo de cosas asi en Mad Max. Despues de una hora logramos alcanzar el puente de mina. Esta atascado de gente, que de alguna manera logro llegar ahi y ahora estan atrapados en esos 30 metros secos dentro de un mar de agua, llena de basura, y quien sabe que objetos que flotan.

Cosas de la vida, otro gran problema es un par de animales de dos patas que haciendo gala de por que eran dueños de un Hummer, tratando de aventar la lamina para pasar, con las ventanas abiertas, lentes oscuros y musica de regueton. Como si estuvieran paseando por la carretera costera de cualquier destino vacacional. Ojala hallan logrado pasar. No los queremos aqui.

En el parque museo de la venta, los camarografos y fotografos se bajan. Algunas tomas de agradecimiento y nos quedamos pocos. Otra media hora de trafico para llegar a nuestro destino final. Las oficinas de halliburton. Y esto fue nada mas para llegar a la casa.

A continuación comparto cinco estrategias que pueden ayudarles a asegurar que su organización contemple el factor humano en su adopción de SOA y aumentar así las probabilidades de éxito:

1.- Liderazgo y Consenso: Los informáticos, cuando somos lideres tendemos a ser tiranos. SOA requiere de un liderazgo fundamentalmente diferente. El lider de una estrategia de SOA requiere de poder crear un ambiente donde las decisiones se toman por consenso. La uníca manera de que una organización cambie es que todos sean escuchados, sus preocupaciones sean atendidas y se logren acuerdos donde nadie salga perdiendo. El mayor reto de SOA es pasar de una organización competitiva a una organización cooperativa. El establecer metricas que promuevan la cooperación y no la competencia entre areas, el reconocimiento a la labor de equipo y un sistema efectivo de toma decisiones consensuado es un primer paso ineludible en el viaje hacia SOA.

2.- Establecer un Lenguaje Comun: El concepto de SOA no tiene estandares, cada proveedor da su version particular de SOA en el cual magicamente su producto cumple con todas las expectativas. Esto es increiblemente dañino para una organización, ya que dentro de la misma empresa, dependiendo del proveedor favorito de cada grupo de sistemas, se entendera SOA como cosas fundamentalmente distintas. Antes de iniciar un proyecto de adopción de SOA debemos definir y divulgar lo que significa SOA para nuestra organización, y los beneficios particulares que buscamos. Lograr que todos hablen el mismo idioma es indispensable para una toma de decisiones en consenso.

3.- Diseñar nuestra propia receta: Cada vez que leo un whitepaper que explica como un producto es indispensable para tener exito en SOA siento un vuelco en el estomago. No existen recetas secretas para SOA. Cada organización tiene retos de negocio, cultura e historia distintas, se tiene que aceptar que ningun proveedor va a poder darle un SOA “llave en mano” por que no hay otra organización igual a la suya en este sentido. La metodología de Factores Críticos de Exito (Rockhart) está más vigente que nunca al ser una estrategia basada en consenso y en la recopilación de la inteligencia colectiva para planear de forma adecuada. El definir a través de una sesión formal de factores críticos de éxito, que contemple contextos humanos, organizacionales, tecnológicos, y administrativos es una buena manera de garantizar que se cubren todos los aspectos de una estrategia de cambio hacia SOA.

3.- El negocio antes que la arquitectura: El principal motivo de fracaso en los proyectos de TI es muy claro: el beneficio esperado por el negocio nunca llega. Mas que centrarnos en si contamos con una arquitectura con todas las “capacidades”, debemos de centrarnos en un enfoque donde primero entregamos el resultado que las personas de negocio esperan y despues nos preocupamos por la arquitectura tecnica. Sé que va en contra de todo lo que los “profesionales” de sistemas les decimos, pero la realidad es que si entregamos primero el resultado de negocio sera mas facil que nos den tiempo y dinero para hacer la arquitectura soñada. En SOA esto quiere decir, primero analizamos los dos o tres procesos mas importantes para el negocio y hacemos lo minimo indispensable para entregar mejoras en ellos. Nada mas.

4 .- La disciplina en el diseño: Existe una multitud de “conectores” y “componentes” que prometen facilitar todo. Sin embargo SOA es antes que nada una disciplina de diseño. Como toda disciplina son los humanos quienes la practican, no el producto de software. Un buen equipo de SOA entiende a todos los niveles que preservar el estilo de diseño es indispensable para obtener los beneficios. Se acabaron los “hacks” y mejoras propietarias. Todo diseño debe de obedecer los principios de diseño de SOA, los arquitectos y desarrolladores deben de practicar esta disciplina. Un comite guia puede ser de gran ayuda para asegurar que esta disciplina se aprenda y se regule.

5.- El valor de aprender: La cultura de hacerlo bien y a la primera no aplica enteramente para SOA. Somos humanos, estamos aprendiendo globalmente como cambiar hacia SOA. Habra cosas que nos parecerán buena idea en un principio y con el paso del tiempo mostraran que no lo son. Debemos estar abiertos a rediseñar o refactorizar. Es mejor aceptar de antemano que tendremos que variar el diseño y trabajemos de acuerdo a esto. Con SOA necesitamos iterar y protegernos de los cambios, pero mas que nada necesitamos promover la experimentación y el consenso. Nada peor para paralizar SOA que desarrolladores temerosos a “exponerse” con sus compañeros por que no se imaginaron todo bien a la primera. SOA fue pensado para el cambio, aprovechemoslo.

Al final, lo que es indispensable considerar en la implementación de SOA en una organización es como lograr el cambio que se requiere para que los beneficios de esta arquitectura den resultado y no nos vaya a pasar que dentro de 10 años tengamos que cambiar a otra bala de plata, porque simplemente hicimos lo mismo que toda la vida, pero ahora con estándares de SOA. Buena suerte.

Y muy sorprendentemente para mi, hasta la fecha… nadie ha levantado la mano. Si todas éstas prácticas que en México son la quintaesencia de la Administración de Proyectos, para las cuáles invertimos miles y miles de pesos en herramientas y cursos de CMM, PMI, MoProSoft y cuántos acrónimos más, cual mantras nos esten vendiendo; no funcionan. Me pregunto entonces ¿Por qué lo seguimos haciendo?.

Al parecer nuestras organizaciones y nosotros mismos pensamos que cuando algo no sale bien en nuestros equipos, lo que necesitamos es una capa más de “control”; un “proceso” más definido y detallado que “obligue” a los programadores, rebeldes, negligentes o apáticos, a tener “conformidad” con el proceso mágico que resolverá todos nuestros problemas. Anhelamos recetas secretas, en realidad, lo que necesitamos es tan solo un sólido conjunto de principios y sentido comun.

¿Como liberar a nuestros proyectos de balas de plata que no funcionan? Afortunados somos de tener Lean Software Development (LSD) a nuestro alcance; es libre, es gratis y simplemente funciona. Desarrollado con mucho éxito por los Poppiendick a partir de las sólidas experiencias de 3M y Toyota, LSD se basa en aplicar al desarrollo de software, los principios Lean que han hecho tan exitoso a Toyota y otras empresas. Se le considera parte de los Metodos Agiles, pero desde mi punto de vista estan por encima de ellos, LSD nos obliga a pensar, a cuestionarnos y a encontrar nuestras propias respuestas.

Los principios de LSD ameritan pasar meses y meses estudiándolos, reflexionando muy profundamente en ellos hasta que se conviertan en un acto reflejo en cada proyecto que emprendamos, pero afortunadamente no necesitamos hacer eso para obtener beneficios, tan solo tenemos que conocerles:

1. Eliminar el derroche: Es decir, evitar todo aquello que no agregue valor al proyecto. ¿Qué es aquello que no agrega valor al proyecto? Sencillo, todo lo que el cliente no pidió, pero en lo que invertimos tiempo, muchas veces facturado. Cosas como documentación sin sentido, tan solo por que lo dice el “libro”; construir el “framework”; esa “generalización del algoritmo”, por si piden cambios en el futuro; documentos de requerimientos perfectamente formateados, pero que sabemos que no es lo que construiremos al final por que siempre cambian. Eliminar todo eso es lo mejor que podemos hacer por nuestros proyectos y nuestros clientes. Aprendamos a ver estas cosas como un despilfarro.

2. Ampliar el Aprendizaje: Se trata de aceptar que nunca se sabrá exactamente lo que se tiene que construir al principio del proyecto, asi que cualquier tiempo que ocupemos tratando de hacer que el cliente nos “firme” el requerimiento rompe con el principio anterior. Ampliar el aprendizaje significa aceptar que el proceso de desarrollo es un proceso de aprendizaje, por lo tanto tenemos que repetirlo muchas veces para aprender. Solución. Muchas iteraciones cortas, tan cortas como haga sentido.

3. Retrasar los compromisos: Cada vez que aceptamos trabajar en un proyecto que tiene fecha de entrega pero no tiene requerimientos fijos es como si decidiéramos casarnos con alguien que conocimos hoy mismo. No lo hacemos en la vida real… verdad, ¿Por qué hacerlo en nuestro trabajo? Las iteraciones cortas ayudan a comprometernos con tan solo lo que podemos estimar bien.

4. Liberar Rápido: ¿Todos hacemos desarrollo por iteraciones verdad? Bueno tener iteraciones no es lo mismo que liberar rápido, liberar rápido significa que si te piden un sistema que facture, liberes “a producción” la factura lo antes posible, aunque no se haya terminado el resto del sistema. Algunas compañías como Google, Yahoo y en general todo el mundo lo ha entendio. Libera funcionalidades, no sistemas.

5. Facultar al equipo: ¿Qué es lo mejor que puede hacer un líder de proyecto? No estorbar. Tenemos que confiar en que las personas pueden ponerse de acuerdo, trabajar en equipo y en esencia auto-dirigirse. Si, cometerán errores, pero si liberan rápido, y tienen iteraciones cortas sus errores no nos costarán caro y sobre todo, se ampliará el aprendizaje. Si no pueden resolverlos por ellos mismos, entonces tal vez, debemos considerar seriamente si tenemos el equipo correcto. El trabajo en equipo ES el desarrollo de software.

6. Construir Integridad Intriseca: En Japón, las mismas máquinas que producen las piezas para manufactura, prueban las piezas que producen, las miden y desechan las que no cumplen con los requisitos mínimos. Sin inspección, sin control de calidad separado de la producción. Sin una cultura donde el programador es el reponsable de la calidad y no un QA de otro departamento, nuestros equipos nunca podrán alcanzar madurez.

7. Pensar en el todo: “O todos coludos o todos rabones decían nuestros abuelos”. Al parecer antes se entendía mucho mejor de cómo hacer que una organización o una familia funcionara como un equipo. Abandonemos el modelo de programador estrella, lo único que producimos son Divas o Gangsters. En un equipo todos ganan y todos pierden, asi que olvidemonos de las mediciones de desempeño individuales, los que salgan bien se buscaran un trabajo donde les paguen mas y los que no salgan tan bien, haran lo mismo. Creemos equipos que compartan logros y fracasos y reduciremos la rotacion de personal.

Por que hablo con tanta seguridad, sencillo, yo mismo he pasado de creer en cosas que no funcionan y sufrir en mi trabajo, a experimentar los frutos de LSD en mi propia practica. Finalmente, busquen en internet a Mary Poppiendick y agradeceran como yo, todo el material gratuito que tiene a nuestra disposición para ayudarnos a empezar. Regalar sus libros a nuestros directores de sistemas probablemente serán los pesos mejor invertidos en mucho tiempo en nuestras carreras. Saludos y suerte!

Hace un par de años, Gerardo Horvilleur, mejor conocido como “El Mago”, se preguntaba si parte del problema no sería la creciente complejidad de los entornos de desarrollo de software.

Si tienes más de 35 años, aceptarás que la forma de empezar a programar actual –no importa si profesas la religión de .Net, Java o algún culto menor– no se compara en nada con las “micros”, gloriosas maquinas como las Commodore, Apple o Tandys que llenaron nuestra adolescencia de disfrutes computacionales. Recordarás el ansia de esperar el siguiente Compute Gazzete o Ahoy! en el Sanborns para copiar los programas de BASIC, sazonados con alguna otra rutina de ensamblador de 6510 en glorioso código hexadecimal. Este tipo de cosas te iniciaron en la programación y gracias a ellas decidiste que querías hacerlo por el resto de tus días.

Los chavos de hoy en día no tienen estas maravillosas opciones. No conozco mucho el caso de .Net, pero en el de Java al menos, creo que bajar Glassfish, Netbeans, y demás cosas “básicas” para programar, no llama tanto la atención de un adolescente como jugar el videojuego de moda y convertirse en consumidores, más que en creadores. Con las micros, si querías un juego, casi tenías que hacerlo. Ahí es donde mago cree que está el problema: los jóvenes ya no eligen estudiar programación, simplemente porque no es tan divertido y sencillo como lo era en esos tiempos.

Afortunadamente, Gerardo no se quedó con las manos cruzadas, y desarrolló Simple J, una novedosa apuesta a despertar la curiosidad de los chavos, creado con una intención muy noble de regresar la programación a su origen esencial: la diversión. SimpleJ recrea un entorno de desarrollo virtual en Java que permite crear juegos de video y compartirlos con el mundo. Simple J simula una computadora simplificada, para que sea más sencillo aprender a programar y evitar distracciones en detalles irrelevantes. La decisión de enfocarse en videojuegos me parece genial, es algo que los chavos conocen bien y les llama la atención. Sin darse cuenta, estarán aprendiendo a programar.

No se necesita ser un experto para comenzar con SimpleJ. En el sitio de SimpleJ (www.simplej.com) está disponible un tutorial enfocado a quienes no saben absolutamente nada de programación, y los guía durante los primero pasos de la programación. Se comienza con cosas sencillas, y va aumentando la complejidad poco a poco, como si el programador fuera “pasando de nivel”, de tal forma que hacer un juego se convierte en un juego en sí mismo.

Una parte muy importante de la escena de programación de hace 20 años, eran los grupos de usuarios donde los adolescentes nos presumíamos unos a otros lo que habíamos aprendido: scrolls de letras, música sintetizada, campos de estrellas que giraban, justo como en la “guerra de las galaxias”. Este componente es esencial en el desarrollo de buenos programadores, ya que normalmente vienen en múltiplos, y aprenden juntos, ya sea colaborando o compitiendo. SimpleJ promueve esto, a través de un applet que permite publicar los juegos desarrollados dentro de una página web para presumirlos al mundo. Así que pronto espero encontrar muchos blogs de chavos mostrándole al mundo sus creaciones. Adicionalmente, SimpleJ cuenta con una comunidad donde por medio de foros se pueden hacer preguntas, o ponerse de acuerdo con alguien más para hacer un videojuego. Mago personalmente contesta todas las dudas que puede, pero la comunidad es principalmente soportada por alumnos de todo tipo de instituciones académicas, desde universitarios del ITAM, hasta estudiantes del bachiller Juan de Dios Bátiz del IPN. Éstas son escuelas visionarias, que han entendido el potencial de esta herramienta en el proceso educativo. Espero que pronto se unan muchas más instituciones académicas a este esfuerzo.

Finalmente, una de las partes más importantes de este desarrollo –además de que es 100% mexicano–, es su modelo de negocios. SimpleJ es software libre, licenciado con GPL y completamente abierto. Mago ha decidido concentrar sus esfuerzos para hacer sustentable este proyecto a través de la venta de un libro que tiene disponible para aprender a programar juegos de video con SimpleJ.

Si tienen algún hijo o familiar adolescente y con intereses tecnológicos, no dejen pasar la oportunidad de pasar un buen rato con ellos recordando viejos tiempos y ayudando a que la industria de software en México tenga los mejores programadores. Una felicitación desde aquí al talento y entusiasmo de Gerardo (mago@simplej.com), sin duda un ejemplo a seguir en el software libre mexicano.

Publicación original en Software Guru edición de Enero-Febrero del 2006