Este es buenísimo. Su gran virtud es pasar desapercibido, pero que existe... existe.
José Descolgado Misterioso (rol indefinido):
En las reuniones de avance en torno a un proyecto de desarrollo puede aparecer un personaje que nadie conoce. Pero como en esas reuniones suelen participar personas de distintas organizaciones (por lo general, de la empresa cliente y de un par de consultoras), todos creen que pertenece a una organización distinta de la suya: los clientes creen que es un consultor, y los consultores creen que es un cliente o que lo mandaron de otra consultora.
Lo cierto es que a este señor sólo se lo ve en las reuniones. Escucha atentamente lo que dicen los demás, asintiendo con la cabeza ante cada opinión, pero rara vez hace algún comentario. Toma notas, aunque nadie sabe para qué. Cuando llega el momento de asignar responsabilidades o fijar objetivos a cumplir, a Descolgado Misterioso le suena el celular y –pidiendo disculpas– se retira de la reunión. Algunos creen que no tiene nada que ver con el proyecto, y que va a las reuniones solamente por el café y las masas. O bien que va con la idea de reunir material para una tira cómica estilo “Dilbert”. Para descubrir qué hace realmente, hay que tratar de averiguar qué escribe en sus notas, para lo cual puede usarse una cámara de seguridad convenientemente ubicada a espaldas de este señor.
Frases características: “Ahá”, “Sí, sin duda alguna”.
Participación en el proyecto: Consumidor de café, masas y oxígeno.
30 sept 2007
13 sept 2007
Día del programador
(¡¡¡Gracias Diego M por este aporte!!!)
El día doscientos cincuenta y seis de cada año se celebra el “Día del Programador”.
La razón de que se celebre este día en particular proviene de que 256 es la cantidad de valores diferentes representables en un byte de datos (lo que equivale a 8 bits).
El día número 256 de los años comunes es el 13 de septiembre, y en los años bisiestos resulta ser el 12 de septiembre.
La Evolución de un Programador:
14 años.
10 PRINT “HELLO WORLD”20 END
17 años.
program Hello(input, output)
begin
writeln(’Hello World’)
end
Al comenzar en la universidad.
(defun hello
(print
(cons ‘Hello (list ‘World))))
Al terminar en la universidad.
#include
void main(void)
{
char *message[] = {”Hello “, “World”};
int i;
for(i = 0; i < 2; ++i) printf(”%s”, message[i]); printf(”\n”);
}
En su primer trabajo como programador.
10 PRINT “HELLO WORLD”
20 END
Tras su ascenso a jefe de departamento.
mail -s “Hello, world.” pepe @ b12
Pepe, puedes escribirme un programa queimprima “Hello, world.”?
Lo necesito para mañana. Gracias.
^D
Siendo jefe de área.
% zmail pepe
Hazme un programa que escriba “Hello, world.” para esta tarde.
Ascendido a Gerente.
% letter
letter: Command not found.
% mail
To: ^X ^F ^C
% help mail
help: Command not found.
% mierda]
]: Event unrecognized
% logout
Frases de Programadores:
1. ¡Qué raro!
2. ¡Antes funcionaba!
3. Hay sólo unas cositas que arreglar.
4. ¿Cómo ha pasado esto?
5. ¡Tiene que ser un fallo de hardware!
6. ¡Ustedes deben haber hecho algo mal!
7. Pero, ¡si no he cambiado nada en esta subrutina!
8. Si, va a estar para ese día.
9. ¡Tenemos que encontrar alguna versión antigua!
10. Además de que no funciona, ¿qué te parece?
11. ¡Es solo un asunto estético!
12. ¡Casi terminé!
13. Como no, solo me falta incorporar los últimos cambios.
14. ¡Vamos con retraso!
15. Tengo algunos problemas con el espacio de memoria.
16. Tengo problemas con demoras.
17. En este momento estamos depurando la función.
18. ¡No se puede probar todo!
19. ¡Esto no puede haber afectado a aquello!
20. ¡Estaba convencido de que lo había arreglado!
21. Está incluido, sólo que no está probado.
22. ¡En realidad funciona bien, aunque no lo parezca!
23. Lo importante es que compile.
FELIZ DIA PROGRAMADORES!!!
El día doscientos cincuenta y seis de cada año se celebra el “Día del Programador”.
La razón de que se celebre este día en particular proviene de que 256 es la cantidad de valores diferentes representables en un byte de datos (lo que equivale a 8 bits).
El día número 256 de los años comunes es el 13 de septiembre, y en los años bisiestos resulta ser el 12 de septiembre.
La Evolución de un Programador:
14 años.
10 PRINT “HELLO WORLD”20 END
17 años.
program Hello(input, output)
begin
writeln(’Hello World’)
end
Al comenzar en la universidad.
(defun hello
(cons ‘Hello (list ‘World))))
Al terminar en la universidad.
#include
void main(void)
{
char *message[] = {”Hello “, “World”};
int i;
for(i = 0; i < 2; ++i) printf(”%s”, message[i]); printf(”\n”);
}
En su primer trabajo como programador.
10 PRINT “HELLO WORLD”
20 END
Tras su ascenso a jefe de departamento.
mail -s “Hello, world.” pepe @ b12
Pepe, puedes escribirme un programa queimprima “Hello, world.”?
Lo necesito para mañana. Gracias.
^D
Siendo jefe de área.
% zmail pepe
Hazme un programa que escriba “Hello, world.” para esta tarde.
Ascendido a Gerente.
% letter
letter: Command not found.
To: ^X ^F ^C
% help mail
help: Command not found.
% mierda]
]: Event unrecognized
% logout
Frases de Programadores:
1. ¡Qué raro!
2. ¡Antes funcionaba!
3. Hay sólo unas cositas que arreglar.
4. ¿Cómo ha pasado esto?
5. ¡Tiene que ser un fallo de hardware!
6. ¡Ustedes deben haber hecho algo mal!
7. Pero, ¡si no he cambiado nada en esta subrutina!
8. Si, va a estar para ese día.
9. ¡Tenemos que encontrar alguna versión antigua!
10. Además de que no funciona, ¿qué te parece?
11. ¡Es solo un asunto estético!
12. ¡Casi terminé!
13. Como no, solo me falta incorporar los últimos cambios.
14. ¡Vamos con retraso!
15. Tengo algunos problemas con el espacio de memoria.
16. Tengo problemas con demoras.
17. En este momento estamos depurando la función.
18. ¡No se puede probar todo!
19. ¡Esto no puede haber afectado a aquello!
20. ¡Estaba convencido de que lo había arreglado!
21. Está incluido, sólo que no está probado.
22. ¡En realidad funciona bien, aunque no lo parezca!
23. Lo importante es que compile.
FELIZ DIA PROGRAMADORES!!!
2 sept 2007
Otro integrante de la fauna de sistemas
Este es un personaje muy interesante, que todos los que trabajamos en sistemas algún día quisiéramos llegar a ser.
José Gardel Jugadoraso (consultor):
Puede ser distintas cosas: auditor de seguridad, analista funcional, testeador de stress, pero en cualquiera de sus formas, este personaje aparece como el portador único de La Verdad. Maneja sus horarios a su antojo, no se suma a las discusiones fútiles, y en las reuniones, escucha aparentando interés en lo que dicen los demás, para emitir su opinión recién cuando se la piden. En ese momento, su opinión es escuchada con respecto y admiración por todos. Puede sumarse al proyecto en las primeras etapas, en cuyo caso su rol es el de Moisés (llevando a su pueblo los mandamientos revelados directamente por El Señor), o bien puede sumarse cuando el proyecto está en vías de naufragar, en cuyo caso su participación es equivalente a la de Jesús (por ser el salvador que viene a rescatar a sus fieles de la condenación eterna). Si el proyecto fracasa, seguramente será por que los demás miembros del equipo no siguieron sus enseñanzas, o bien por que no escucharon sus advertencias.
Frases características: “Yo les dejo el teléfono del hotel donde voy a estar en Bahamas, y cualquier problema que surja durante la implementación, me llaman”, “¿Mi número de celular? Mmmno, sabés lo que pasa, es que justo estoy cambiando de compañía, si te doy el que tengo ahora igual no me vas a poder llamar…”
Participación en el proyecto: Profeta/Mesías (según el momento en que se sume al proyecto).
José Gardel Jugadoraso (consultor):
Puede ser distintas cosas: auditor de seguridad, analista funcional, testeador de stress, pero en cualquiera de sus formas, este personaje aparece como el portador único de La Verdad. Maneja sus horarios a su antojo, no se suma a las discusiones fútiles, y en las reuniones, escucha aparentando interés en lo que dicen los demás, para emitir su opinión recién cuando se la piden. En ese momento, su opinión es escuchada con respecto y admiración por todos. Puede sumarse al proyecto en las primeras etapas, en cuyo caso su rol es el de Moisés (llevando a su pueblo los mandamientos revelados directamente por El Señor), o bien puede sumarse cuando el proyecto está en vías de naufragar, en cuyo caso su participación es equivalente a la de Jesús (por ser el salvador que viene a rescatar a sus fieles de la condenación eterna). Si el proyecto fracasa, seguramente será por que los demás miembros del equipo no siguieron sus enseñanzas, o bien por que no escucharon sus advertencias.
Frases características: “Yo les dejo el teléfono del hotel donde voy a estar en Bahamas, y cualquier problema que surja durante la implementación, me llaman”, “¿Mi número de celular? Mmmno, sabés lo que pasa, es que justo estoy cambiando de compañía, si te doy el que tengo ahora igual no me vas a poder llamar…”
Participación en el proyecto: Profeta/Mesías (según el momento en que se sume al proyecto).
9 jul 2007
25 may 2007
La fauna de sistemas
Los libros de ingeniería de software nos enseñan que durante el desarrollo de un producto de software intervienen, del lado del cliente, roles tales como el “product owner”, los “stakeholders”, los “sponsors”, los “key users”, entre otros personajes que tienen responsabilidades bien claras y definidas dentro del proceso de desarrollo.
El problema con esta categorización de individuos es que, cuando un desarrollador deja el ambiente académico y empieza a enfrentarse con la realidad, se encuentra con que muchas veces es difícil identificar claramente a esos roles entre las personas con las que debe interactuar del lado del cliente. Es por eso que decidí hacer un aporte a la comunidad desarrolladora y catalogar a estas personas de una forma más práctica, es decir, evitando definir roles y responsabilidades para ellas y, en cambio, describiendo su conducta y señalando el papel que juegan en el proyecto. Para ilustrar este catálogo inventé una serie de personajes con nombres ficticios (aunque descriptivos) que cualquier desarrollador podrá identificar fácilmente cuando le toque poner a funcionar un software de su creación.
José Quieroapretarunateclayquemeaparezcanlosdatos (dueño de la empresa):
Es tratado con gran respeto por todas las personas involucradas en el proyecto, aunque nadie da importancia a sus opiniones, sugerencias o exigencias. Algunos pueden tomar nota de lo que dice, o incluso argumentar sus opiniones, pero lo hacen sólo por cortesía. El proveedor del software debe mostrarle el mismo respeto que le demuestran lo demás, y demostrarle (aunque sea falsamente) que toma muy en serio sus aportes al proyecto; al fin y al cabo, por más que no entienda nada de nada, tiene la autoridad suficiente como para cancelar cualquier proyecto, sin importar cuánto le cueste a la empresa su decisión.
Frases características: “¿No se podrá agrandar la letra en los listados? por que yo así no veo nada”, “Cuando llevábamos la contabilidad a mano era todo mucho más fácil”.
Participación en el proyecto: espectador.
José Dios (gerente de sistemas):
Es importante llevarse bien con Dios, si es que se quiere sobrevivir como proveedor de software. Hay que intentar, por todos los medios posibles, tenerlo como aliado y no como enemigo. Como su apellido lo indica, él decide los destinos de todos aquellos que participan en el proyecto, y puede bajarle el pulgar a cualquiera, en cualquier momento. Puede aparentar que le interesa el beneficio que el sistema puede generar para la empresa, pero lo único que le interesa es el beneficio que puede tener para su carrera profesional.
Frases características: “¿Cómo estamos con los plazos?”, “¡Qué buena que está la consultora nueva que mandaron de Accenture!”.
Participación en el proyecto: dictador.
María Nohayorganosexualmasculinoquemevengabien (jefa administrativa):
Necesita constantemente demostrar su poder, y para ello hará todo lo posible por lograr que el proyecto fracase. Aprovecha las reuniones de avance para hablar de todos los defectos que tiene (o cree que tiene) el nuevo software a implementar, comparándolo con el software que usa actualmente y destacando todas sus supuestas ventajas. Para vencerla se requiere quebrar, con astucia y estrategia, esa fachada dura que intenta mostrar ante los demás, poniendo en evidencia sus inseguridades. Por ejemplo, una forma de hacerlo consiste en preguntarle, delante de todos, qué hizo el último sábado por la noche. Otra estrategia consiste en tratar de enemistarla con Dios, para que todas sus opiniones sean rápidamente desmerecidas.
Frases características: “Si no puedo ver los estados de cuenta a una fecha, el programa a mí no me sirve”, “Ese no es mi problema, no sé cómo lo van a resolver, pero más vale que lo resuelvan”.
Participación en el proyecto: lastre.
José Hiperactivo Fanático (empleado administrativo):
Le fascina todo lo nuevo, mostrando un entusiasmo excesivo por cualquier pantallita de colores, cualquier animación, cualquier detalle audiovisual que haga más simpática a la aplicación, sin importar que funcione o no. Es importante dejarlo contento, ya que será el que más esté en contacto con el nuevo software y tendrá la responsabilidad de reportar los errores o las necesidades de mejoras. Por suerte, dejarlo contento es fácil: basta con colocar botones en la interfaz de usuario que cambien de imagen aleatoriamente cuando se les pasa el mouse por encima; con esto, Hiperactivo Fanático tendrá algo que hacer durante toda la jornada y olvidará su responsabilidad para reportar acerca del funcionamiento del sistema.
Frases características: “El nuevo programa anda en Windows Vista, ¿no? Por que yo en mi máquina tengo Windows Vista”, “¿Se puede hacer que el relojito dé vueltas mientras está trayendo los datos?”.
Participación en el proyecto: colaborador algunas veces, y molestador otras veces.
María Latengomásclaraquetodos (empleada administrativa):
Conoce los circuitos administrativos tan bien que si la echan, la empresa se va a los caños. Es muy respetada por todos, incluso por Dios, pues es consciente de la criticidad de sus conocimientos. Es fundamental escuchar cuidadosamente cada uno de sus comentarios y sugerencias, pues son clave para el éxito del proyecto. Es profundamente odiada por Nohayorganosexualmasculinoquemevengabien, por que sabe que no la puede sacar de su puesto, y le envidia el respeto que todos le tienen.
Frases características: “Entre nos... este listado ni lo hagan por que jamás se va a usar”, “No se preocupen, yo lo convenzo a Dios para que les apruebe el presupuesto”.
Participación en el proyecto: colaboradora indispensable.
Esta lista no está para nada completa. Hay muchos otros personajes destacables en la fauna de sistemas, los cuales iré describiendo en futuros posts.
El problema con esta categorización de individuos es que, cuando un desarrollador deja el ambiente académico y empieza a enfrentarse con la realidad, se encuentra con que muchas veces es difícil identificar claramente a esos roles entre las personas con las que debe interactuar del lado del cliente. Es por eso que decidí hacer un aporte a la comunidad desarrolladora y catalogar a estas personas de una forma más práctica, es decir, evitando definir roles y responsabilidades para ellas y, en cambio, describiendo su conducta y señalando el papel que juegan en el proyecto. Para ilustrar este catálogo inventé una serie de personajes con nombres ficticios (aunque descriptivos) que cualquier desarrollador podrá identificar fácilmente cuando le toque poner a funcionar un software de su creación.
José Quieroapretarunateclayquemeaparezcanlosdatos (dueño de la empresa):
Es tratado con gran respeto por todas las personas involucradas en el proyecto, aunque nadie da importancia a sus opiniones, sugerencias o exigencias. Algunos pueden tomar nota de lo que dice, o incluso argumentar sus opiniones, pero lo hacen sólo por cortesía. El proveedor del software debe mostrarle el mismo respeto que le demuestran lo demás, y demostrarle (aunque sea falsamente) que toma muy en serio sus aportes al proyecto; al fin y al cabo, por más que no entienda nada de nada, tiene la autoridad suficiente como para cancelar cualquier proyecto, sin importar cuánto le cueste a la empresa su decisión.
Frases características: “¿No se podrá agrandar la letra en los listados? por que yo así no veo nada”, “Cuando llevábamos la contabilidad a mano era todo mucho más fácil”.
Participación en el proyecto: espectador.
José Dios (gerente de sistemas):
Es importante llevarse bien con Dios, si es que se quiere sobrevivir como proveedor de software. Hay que intentar, por todos los medios posibles, tenerlo como aliado y no como enemigo. Como su apellido lo indica, él decide los destinos de todos aquellos que participan en el proyecto, y puede bajarle el pulgar a cualquiera, en cualquier momento. Puede aparentar que le interesa el beneficio que el sistema puede generar para la empresa, pero lo único que le interesa es el beneficio que puede tener para su carrera profesional.
Frases características: “¿Cómo estamos con los plazos?”, “¡Qué buena que está la consultora nueva que mandaron de Accenture!”.
Participación en el proyecto: dictador.
María Nohayorganosexualmasculinoquemevengabien (jefa administrativa):
Necesita constantemente demostrar su poder, y para ello hará todo lo posible por lograr que el proyecto fracase. Aprovecha las reuniones de avance para hablar de todos los defectos que tiene (o cree que tiene) el nuevo software a implementar, comparándolo con el software que usa actualmente y destacando todas sus supuestas ventajas. Para vencerla se requiere quebrar, con astucia y estrategia, esa fachada dura que intenta mostrar ante los demás, poniendo en evidencia sus inseguridades. Por ejemplo, una forma de hacerlo consiste en preguntarle, delante de todos, qué hizo el último sábado por la noche. Otra estrategia consiste en tratar de enemistarla con Dios, para que todas sus opiniones sean rápidamente desmerecidas.
Frases características: “Si no puedo ver los estados de cuenta a una fecha, el programa a mí no me sirve”, “Ese no es mi problema, no sé cómo lo van a resolver, pero más vale que lo resuelvan”.
Participación en el proyecto: lastre.
José Hiperactivo Fanático (empleado administrativo):
Le fascina todo lo nuevo, mostrando un entusiasmo excesivo por cualquier pantallita de colores, cualquier animación, cualquier detalle audiovisual que haga más simpática a la aplicación, sin importar que funcione o no. Es importante dejarlo contento, ya que será el que más esté en contacto con el nuevo software y tendrá la responsabilidad de reportar los errores o las necesidades de mejoras. Por suerte, dejarlo contento es fácil: basta con colocar botones en la interfaz de usuario que cambien de imagen aleatoriamente cuando se les pasa el mouse por encima; con esto, Hiperactivo Fanático tendrá algo que hacer durante toda la jornada y olvidará su responsabilidad para reportar acerca del funcionamiento del sistema.
Frases características: “El nuevo programa anda en Windows Vista, ¿no? Por que yo en mi máquina tengo Windows Vista”, “¿Se puede hacer que el relojito dé vueltas mientras está trayendo los datos?”.
Participación en el proyecto: colaborador algunas veces, y molestador otras veces.
María Latengomásclaraquetodos (empleada administrativa):
Conoce los circuitos administrativos tan bien que si la echan, la empresa se va a los caños. Es muy respetada por todos, incluso por Dios, pues es consciente de la criticidad de sus conocimientos. Es fundamental escuchar cuidadosamente cada uno de sus comentarios y sugerencias, pues son clave para el éxito del proyecto. Es profundamente odiada por Nohayorganosexualmasculinoquemevengabien, por que sabe que no la puede sacar de su puesto, y le envidia el respeto que todos le tienen.
Frases características: “Entre nos... este listado ni lo hagan por que jamás se va a usar”, “No se preocupen, yo lo convenzo a Dios para que les apruebe el presupuesto”.
Participación en el proyecto: colaboradora indispensable.
Esta lista no está para nada completa. Hay muchos otros personajes destacables en la fauna de sistemas, los cuales iré describiendo en futuros posts.
13 may 2007
¿De qué se reía El Zorro?
Durante mi niñez había varios personajes del cine y la TV a quienes yo idolatraba. Meteoro, Han Solo, Maxwell Smart, son algunos de ellos. Cada uno de ellos tenía ciertas cualidades que lo hacían digno de admiración. El Zorro (el de la serie de Walt Disney, que era interpretado por Guy Williams) también estaba entre mis ídolos, gracias a una cualidad que lo hacía sobresalir del resto: la sonrisa que mostraba durante las peleas con espada.
Cuando era chico no lo hacía, pero en la actualidad, cuando vuelvo a ver El Zorro, no puedo evitar preguntarme de qué se reía. La respuesta más inmediata que se me ocurre es que se reía por que disfrutaba mucho espadear, entonces aunque se encontrara ante enemigos que lo superaban por mucho en número, él mantenía su sonrisa por que estos enemigos le daban la oportunidad de hacer algo que le resultaba gratificante.
Reflexionando un poco sobre el tema, se me ocurre otra explicación más compleja para esa sonrisa: la usaba como estrategia, con un doble propósito: desmoralizar a sus enemigos y darles confianza a sus amigos.
Quizás la verdadera explicación es que se acordaba de algún chiste que le contaban antes de filmar cada escena de acción, pero yo me quedo con la idea de la estrategia, y además trato de aplicar esa estrategia en mis luchas cotidianas, aunque no me enfrente a diario en duelos de espadas con los lanceros fieles a la corona española.
El Zorro podría haber elegido mostrar a sus adversarios un gesto fiero, como un perro que muestra sus dientes para que el enemigo sepa los filosos que son. Pero en vez de eso les mostraba una expresión risueña, haciéndoles saber que la pelea le resultaba entretenida y que estaba seguro de que la ganaría.
En mis luchas cotidianas me enfrento a enemigos mucho más mundanos, que a veces ni siquiera están corporizados en personas. Estos enemigos son, por ejemplo, los obstáculos que encuentro en mi trabajo y que intentan hacerme fracasar en la búsqueda de mis objetivos. Cuando uno de estos enemigos se me pone delante, en lugar de angustiarme y poner cara de preocupación, me río de ellos, con lo cual ya tengo la mitad de la pelea ganada.
Nunca leí nada sobre técnicas de motivación para equipos de trabajo, pero ésta, si no lo es, debería ser una. Si los miembros de un equipo de trabajo ven que su líder pone cara de enojo, preocupación, cansancio o fastidio ante cada inconveniente que se le pone delante, seguramente se desmoralizarán y perderán la motivación para lograr los objetivos comunes al equipo. En cambio, si ven que su líder se ríe y hasta disfruta cuando debe enfrentarse a los problemas, esta actitud les inspirará confianza y seguridad para colaborar en el logro de los objetivos comunes.
El sargento García era un completo inútil, pero cuando por alguna razón se enfrentaba junto al Zorro con un enemigo común a ambos, sacaba a relucir habilidades que resultaban decisivas en la tarea de lograr la victoria.
Moraleja: un buen líder le sonríe a las dificultades, y así logra que aún sus colaboradores más inútiles aporten algo positivo para la resolución de los problemas que debe enfrentar el equipo.
3 abr 2007
Programación ZEN
En el sitio http://www.softwarereality.com/ salió un artículo titulado “How to Choose a Cool Name for a Software Process” (cómo elegir un nombre “cool” para un proceso de software). Vale la pena leerlo, pero para quienes no tengan ganas, hago una síntesis: si usted está inventando su propio proceso de desarrollo y quiere que aparezca mencionado en libros y artículos, lo más importante es encontrarle un nombre “cool”.
Siguiendo ese consejo, yo inventé una metodología, y –siguiendo la filosofía de este blog– la bauticé simplemente “Programación ZEN”. A continuación, una breve descripción de las características de esta revolucionaria metodología.
ZEN (zero engineering necessity) es una metodología que realza los principios espirituales del desarrollo de software, contribuyendo a lograr la comunión de almas entre clientes y desarrolladores. Se basa en cinco valores principales:
* Crecimiento espiritual
* Armonía con el universo
* Auto-conocimiento
* Amor al prójimo
* Fe (en uno mismo y en los demás miembros del equipo)
Un proyecto de desarrollo ZEN se organiza en iteraciones, cuya duración es totalmente variable, y depende únicamente de la necesidad que sientan los usuarios o clientes de pedir nuevos requerimientos, o bien de implementar requerimientos pedidos con anterioridad.
La programación ZEN establece un conjunto de prácticas que deben cumplirse en su totalidad (esta metodología no puede implementarse parcialmente) y son las siguientes:
* Reunión de descubrimiento: al principio de cada iteración, el equipo de desarrollo se reúne con los usuarios en una habitación sin ventanas, iluminada sólo por una vela. Todos se sientan en el suelo en posición de loto. Sólo hablan los usuarios; los miembros del equipo de desarrollo sólo emiten sonidos suaves como de un mantra, y pueden permanecer con los ojos cerrados. Para poder tomar la palabra, cada interesado debe hacer sonar una campana y expresar sus ideas, intereses o sueños con respecto al sistema. Al concluir, debe decir: “Sabrá el desarrollador ver la realidad del sistema más allá de la imperfección de mis expresiones”. Esta frase indica que otro puede hacer sonar la campana y hablar. La reunión dura hasta que la vela se consuma en su totalidad, sin importar que los usuarios hayan o no alcanzado a decir todo lo que querían, o bien se hayan quedado callados mucho rato antes de consumirse la vela. Al concluir la reunión, los miembros del equipo de desarrollo habrán logrado ver en el corazón de los usuarios la perfecta funcionalidad que debe tener el sistema a desarrollar. No se utilizan documentos de ninguna índole para registrar los requerimientos; éstos quedan grabados en la mente colectiva del equipo de desarrollo.
* Meditación grupal: el equipo de desarrollo lleva a cabo una hora de meditación grupal al principio de cada jornada de trabajo, para liberar a sus almas de todo el bagaje de energías externas absorbidas desde la jornada anterior. Luego de la meditación grupal, el equipo estará conectado formando una mente colectiva, y deberá trabajar el resto de la jornada en forma totalmente aislada de las influencias del mundo exterior.
* Programación colectiva: la programación ZEN recomienda que todos los programadores trabajen en conjunto, desarrollando un mismo requerimiento. Cada programador escribe una línea de código mientras los demás observan, y cede la máquina al siguiente, quien también escribe una línea de código y pasa el turno al siguiente, hasta volver a empezar la ronda o terminar el desarrollo del requerimiento. Si el programador al que le toca el turno no sabe qué escribir, significa que se desconectó de la mente colectiva del equipo. Entonces debe cubrirse la cabeza con el manto de la clarividencia, ceder el turno al siguiente y retirarse de la ronda, limitándose a observar lo que los otros programan hasta tanto sienta que se reconectó con el equipo. Es importante que no haya comunicación verbal entre los programadores, para fomentar el mantenimiento de la mente colectiva.
* No-automatización: toda línea de código debe escribirse como si fuera única, como si nunca antes se hubiera escrito, aunque ya se hayan escrito mil veces líneas de código idénticas. En la programación ZEN están prohibidas las herramientas automáticas, tales como los generadores de código. Las herramientas certificadas para programación ZEN impiden por todos los medios posibles el copy/paste. La única forma de agregar líneas de código a un programa es escribiéndolas caracter por caracter.
* Desarrollo sin fin: un proyecto nunca comienza y nunca termina. El sistema esa una entidad en constante cambio. Su puesta en funcionamiento puede realizarse en cualquier momento, cuando el usuario sienta la necesidad de comenzar a utilizar una nueva versión del software, puesto que la programación ZEN da la seguridad de que el sistema es perfecto en cualquier etapa de su evolución.
* Zero-testing (ZT): las prácticas antes mencionadas y la fe del equipo de desarrollo aseguran que el software desarrollado carece completamente de errores, y por lo tanto se hace innecesaria toda actividad de testeo. El usuario, cuando utiliza por primera vez el sistema implementado, puede caer en la oscuridad del error y creer que el sistema no hace lo que él pidió. Es deber del Maestro Zen –uno de los roles dentro del equipo de desarrollo– iluminar con humildad al usuario para hacerle ver que, aún cuando el sistema no haga lo que pidió, sí hace lo que deseaba en su corazón. Al comprender esto, el usuario se conecta con su ser superior y acepta con alegría cualquier efecto que el uso del sistema tenga sobre su trabajo cotidiano. Aún cuando ese efecto le signifique tener que quedarse horas extras terminando su trabajo a mano, el usuario entenderá que ése era su destino, y que el software implementado simplemente cumplió la función de hacer que se cumpla.
Siguiendo ese consejo, yo inventé una metodología, y –siguiendo la filosofía de este blog– la bauticé simplemente “Programación ZEN”. A continuación, una breve descripción de las características de esta revolucionaria metodología.
ZEN (zero engineering necessity) es una metodología que realza los principios espirituales del desarrollo de software, contribuyendo a lograr la comunión de almas entre clientes y desarrolladores. Se basa en cinco valores principales:
* Crecimiento espiritual
* Armonía con el universo
* Auto-conocimiento
* Amor al prójimo
* Fe (en uno mismo y en los demás miembros del equipo)
Un proyecto de desarrollo ZEN se organiza en iteraciones, cuya duración es totalmente variable, y depende únicamente de la necesidad que sientan los usuarios o clientes de pedir nuevos requerimientos, o bien de implementar requerimientos pedidos con anterioridad.
La programación ZEN establece un conjunto de prácticas que deben cumplirse en su totalidad (esta metodología no puede implementarse parcialmente) y son las siguientes:
* Reunión de descubrimiento: al principio de cada iteración, el equipo de desarrollo se reúne con los usuarios en una habitación sin ventanas, iluminada sólo por una vela. Todos se sientan en el suelo en posición de loto. Sólo hablan los usuarios; los miembros del equipo de desarrollo sólo emiten sonidos suaves como de un mantra, y pueden permanecer con los ojos cerrados. Para poder tomar la palabra, cada interesado debe hacer sonar una campana y expresar sus ideas, intereses o sueños con respecto al sistema. Al concluir, debe decir: “Sabrá el desarrollador ver la realidad del sistema más allá de la imperfección de mis expresiones”. Esta frase indica que otro puede hacer sonar la campana y hablar. La reunión dura hasta que la vela se consuma en su totalidad, sin importar que los usuarios hayan o no alcanzado a decir todo lo que querían, o bien se hayan quedado callados mucho rato antes de consumirse la vela. Al concluir la reunión, los miembros del equipo de desarrollo habrán logrado ver en el corazón de los usuarios la perfecta funcionalidad que debe tener el sistema a desarrollar. No se utilizan documentos de ninguna índole para registrar los requerimientos; éstos quedan grabados en la mente colectiva del equipo de desarrollo.
* Meditación grupal: el equipo de desarrollo lleva a cabo una hora de meditación grupal al principio de cada jornada de trabajo, para liberar a sus almas de todo el bagaje de energías externas absorbidas desde la jornada anterior. Luego de la meditación grupal, el equipo estará conectado formando una mente colectiva, y deberá trabajar el resto de la jornada en forma totalmente aislada de las influencias del mundo exterior.
* Programación colectiva: la programación ZEN recomienda que todos los programadores trabajen en conjunto, desarrollando un mismo requerimiento. Cada programador escribe una línea de código mientras los demás observan, y cede la máquina al siguiente, quien también escribe una línea de código y pasa el turno al siguiente, hasta volver a empezar la ronda o terminar el desarrollo del requerimiento. Si el programador al que le toca el turno no sabe qué escribir, significa que se desconectó de la mente colectiva del equipo. Entonces debe cubrirse la cabeza con el manto de la clarividencia, ceder el turno al siguiente y retirarse de la ronda, limitándose a observar lo que los otros programan hasta tanto sienta que se reconectó con el equipo. Es importante que no haya comunicación verbal entre los programadores, para fomentar el mantenimiento de la mente colectiva.
* No-automatización: toda línea de código debe escribirse como si fuera única, como si nunca antes se hubiera escrito, aunque ya se hayan escrito mil veces líneas de código idénticas. En la programación ZEN están prohibidas las herramientas automáticas, tales como los generadores de código. Las herramientas certificadas para programación ZEN impiden por todos los medios posibles el copy/paste. La única forma de agregar líneas de código a un programa es escribiéndolas caracter por caracter.
* Desarrollo sin fin: un proyecto nunca comienza y nunca termina. El sistema esa una entidad en constante cambio. Su puesta en funcionamiento puede realizarse en cualquier momento, cuando el usuario sienta la necesidad de comenzar a utilizar una nueva versión del software, puesto que la programación ZEN da la seguridad de que el sistema es perfecto en cualquier etapa de su evolución.
* Zero-testing (ZT): las prácticas antes mencionadas y la fe del equipo de desarrollo aseguran que el software desarrollado carece completamente de errores, y por lo tanto se hace innecesaria toda actividad de testeo. El usuario, cuando utiliza por primera vez el sistema implementado, puede caer en la oscuridad del error y creer que el sistema no hace lo que él pidió. Es deber del Maestro Zen –uno de los roles dentro del equipo de desarrollo– iluminar con humildad al usuario para hacerle ver que, aún cuando el sistema no haga lo que pidió, sí hace lo que deseaba en su corazón. Al comprender esto, el usuario se conecta con su ser superior y acepta con alegría cualquier efecto que el uso del sistema tenga sobre su trabajo cotidiano. Aún cuando ese efecto le signifique tener que quedarse horas extras terminando su trabajo a mano, el usuario entenderá que ése era su destino, y que el software implementado simplemente cumplió la función de hacer que se cumpla.