La autopista del desarrollo

De la misma manera en que necesitamos imágenes o alegorías para comprender los sistemas o alguna de sus partes necesitamos una buena imagen de cómo es el proceso de desarrollo. Un concepto más fácil de atrapar y de entender que un paper de buenas prácticas o un libro acerca de alguna nueva metodología. Me tomo muy en serio las frases graciosas al estilo

"Codifica siempre como si la persona que finalmente mantendrá tu código fuera un psicópata violento que sabe dónde vives." (Martin Golding)

porque son más fuertes que un aburrido sermón de media hora sobra por qué tenemos que ser prolijos y claros y etc. etc. etc..

Para el desarrollo de software, la clásica es "la fábrica". El equipo de desarrollo es una "fabrica de software". Entonces entran los requerimientos, vienen los analistas que hacen algo con ellos, se lo pasan a los programadores que hacen otra cosa, que se la pasan a los testers que la prueban y a los de soporte o como-se-llamen que la instalan y el cliente que la usa. Una línea de montaje. Si bien no está tan mal, no me gusta del todo.

Me gusta la idea del desarrollo de software como un viaje en auto. Lo leí por primera vez en "Extreme Programming Explained" de Kent Beck (que recomiendo sobremanera), y siempre me ha quedado dando vueltas en la cabeza. El libro está lleno de imágenes poderosas y es por eso que los conceptos centrales son inolvidables, más allá de que uno esté de acuerdo o no con ellos.

La idea es: todo el equipo de desarrollo está viajando junto con el cliente desde los requerimientos hasta la implementación. Algunos en su propio auto, otros van de a dos o tres, unos van más rápido y otros más lento, pero tenemos que llegar todos.

Primero está el deseo de ir a algún lado. Requerimientos.

Después pensamos "¿podemos ir?". Yo quiero ir a Madrid el mes que viene, me gusta mucho Madrid. Pero desgraciadamente no lo veo muy posible, por lo menos para el mes que viene. Tenemos entonces el estudio de factibilidad.

Después pensamos qué necesito para llegar. No alcanza con decir "salimos mañana". Necesito un auto, dinero, combustible, tal vez un mapa, tengo que hacer la valija, cosas comunes para cualquier viaje. Quiero saber cuándo salimos y cuándo llegamos, y también cuánto me va a costar la gracia. Así que planeamos.

Entonces nos ponemos a pensar en la ruta. Un poco de eso lo hicimos en la etapa anterior, pero ahora agarramos el mapa y nos ponemos a ver en detalle por dónde vamos a ir, si nos conviene tal o cual camino, cómo nos distribuimos en los autos, etc. Diseñamos.

Y llega el día de la partida. Alguno se queda dormido, y llega justo para salir. Otro tuvo un contratiempo y nos alcanza a mitad de camino. Otro decidió que no, que mejor me quedo en casa. Los demás estamos ahí con las valijas en la mano, y los motores en marcha. Miro la valija de mi muy presentable compañera de viaje (¿ven que la planeamiento y el diseño son importantes?). Está muy preparada y me empiezo a dar cuenta de todo lo que me falta. Mejor no pensar en eso. De alguna manera voy a llegar... a algún lado.

Y empieza el viaje y empiezan los problemas. Porque hay un atasco por allá, así que hay que decidirse, ¿nos abrimos o aguantamos? ¿y si cortamos por ese descampado, no iremos más rápido? Que no que mejor vamos por acá, sigamos la ruta, que es lo más seguro.

Que pinchamos, suerte que tenemos rueda de repuesto... te dije que necesitábamos una rueda de repuesto, me dijiste que la conseguías, ¿cómo que había que abaratar? ¿cómo que para mañana? Al final gastamos más y tenemos que esperar.

Que tengo hambre, calor, frío, sueño. Yo así no sigo. No importa, conductores hay por todos lados. Sí, pero ninguno va a querer viajar así. Que vas a ver que alguno que recién aprende se muere de ganas de manejar. Bueno...

Obviamente las cosas no son como las planeamos y diseñamos. Pero no lo hicimos mal, simplemente las cosas nunca son como las planeamos. Por suerte planeamos pensando en eso, ¿no? Ah, ¿no? Ups...

Y el viaje sigue. Algunos manejan mejor y otros peor. Pensemos un poco en eso. Hay distintos tipos de conductores. Están los que respetan a rajatabla todas las normas y carteles. Son capaces de desbarrancarse por hacerle caso a un cartel que estaba dado vuelta. Están los temerarios que zigzaguean entre los vehículos a toda velocidad. Expertos conductores, siempre les sale bien. Está el que habla por celular, escucha música a todo lo que da, mira el paisaje y cada tanto le presta un ojo a la ruta. Está el que va atento a todo, esperando lo inesperado.

Que cada uno valore positiva o negativamente a cada tipo de conductor según su propio criterio. Yo sigo presentando mi opinión, abierto al debate:

Al manejar hay que confiar en ciertas reglas básicas. Cada uno debería seguirlas y confiar en que los demás las siguen también. No puedo frenar siempre por las dudas, aunque el semáforo está en verde. Tengo que creer que el que lo tiene en rojo va a frenar. Sin embargo hay que estar atento en los cruces. Hago señales, que todo el mundo sepa qué es lo que voy a hacer. Sin embargo, alguien más puede estar distraído, así que me aseguro de que me hayan visto. Y así con todo.

En un equipo de desarrollo, el que no sigue las reglas se vuelve peligroso, para él y para los demás. Todos cometemos errores, e incluso todos violamos alguna norma de vez en cuando, a sabiendas. Pero es una cuestión de grados. No es lo mismo el que deja código medio enrevesado dentro de un módulo, sabiendo que no está muy bien, pero que por lo menos está encerrado ahí, que el que para resolver un problema te pone 20 variables globales y hace un nudo que madre de dios. Y no es lo mismo hacerlo y avisar que hacerlo y ocultarlo. Hay cuestiones en un integrante de un equipo de trabajo que lo vuelven extremadamente peligroso, por ejemplo:

• No respetar los acuerdos sin avisar. Vamos a hacer esto de esta manera, ¿ok? Éste es el momento de estar en desacuerdo, o de plantear problemas. Luego, hay que hacerlo así, o avisar que no podemos, pero no hacerlo de otra manera, o no hacerlo en lo absoluto.
• No utilizar el mismo lenguaje que el resto. Claro, si uno quiere decir "A" pero dijo "a" es parecido, pero no es lo mismo, y los malentendidos son terribles. No hay que tener vergüenza de usar el dedo. Cuando no sabemos el nombre de algo, lo apuntamos con el dedo y decimos "esto", pero no lo cambiamos por otro nombre.
• El individualismo llevado al extremo. Yo hago las cosas a mi manera ¿ok? Y lo que a mí me importa es que mi trabajo esté a tiempo y forma, me pongo las anteojeras (como la de los caballos, ésas para no ver a los costados) y le doy para adelante. No está tan mal, salvo que se combine con el primer punto ("digo a todo que sí y después hago lo que quiero"). Hay que defender lo que uno cree, estamos de acuerdo, pero si los demás no lo ven a nuestro modo, hay que adaptarse, con quejas, malhumor, lo que sea, pero adaptarse. Y si no nos podemos adaptar, hay que irse. Seguramente hay otras personas que harán las cosas a mi manera o que se adapten a mí, es cuestión de encontrarlas. Pero si me quedo me vuelvo peligroso.
• Encubrir los problemas, por cualquier motivo.

No se me ocurren más por ahora. Acepto sugerencias. Pero notemos que son cuestiones que no hacen a la idoneidad. Hasta el más principiante desarrollador puede evitar esas actitudes. Son temas que giran alrededor de lo más importante en un equipo de desarrollo: la comunicación. Digo lo que voy a hacer, hago lo que dije que iba a hacer. Las reglas básicas del desarrollo de software tienen que ver con facilitar la buena comunicación entre los miembros del equipo, o por lo menos con no bloquearla.

Cuando la comunicación es buena, surge algo que es maravilloso en un equipo: la confianza. No confianza en que "todo va a salir bien" ni en que "fulano podrá resolverlo". Confianza en saber qué es lo que está pasando, y en saber, o enterarme a tiempo, cómo es que van a reaccionar los demás. Confianza en que no me va a caer un piano en la cabeza (a menos que pase por donde dice "no pasar"). Si X es un apurado que quiere resolver todo de cualquier manera, pero lo dice, y sobre todo acepta cuando se le dice que no lo haga, está ok. Muchas veces es necesario resolver las cosas de cualquier manera. Si a Y no le interesa demasiado el proyecto, y sólo quiere que suene la hora para irse, pero lo dice, perfecto. Sé qué es lo que puedo esperar de él. Y tiene algo invalorable, la sinceridad. Si Z no puede con este problema, pero avisa a tiempo, vemos qué es lo que hacemos.

Tenemos que convivir con los temerarios y con los que van a contramano. Y encima tenemos que vivir con nuestros propios errores, miserias, días malos y demás. Como en un viaje, desgraciadamente no alcanza con manejar bien y estar atento, porque siempre puede venir un loco a 200 por hora, y eso es inevitable. Pero podemos prever y controlar los daños. Siempre hay uno que puede introducir un virus mirando pornografía en el trabajo. Pero si tenemos antivirus sería más raro que eso suceda. Hasta el administrador más avezado puede borrar una carpeta sin querer. Pero si él es el único que tiene permisos para hacerlo, y aparte hay backups periódicos, sería raro perder mucha información. Puede haber alguno al que lo único que le importa es decir que él llegó a tiempo, o que los retrasos no son su culpa, y ocultar el hecho de que para llegar antes entorpeció a todos los demás. Pero si el proyecto está bien armado cada uno trabaja sin poder molestar demasiado al resto (por más que quiera). Y así con todo.

La conclusión es que la imagen de manejar y el viaje es muy buena, y nos brinda directivas de conducta para cuando no sabemos qué hacer. Yo la uso, veo las cosas de esa manera, y funciona. Prueben.