Jugar en serio.

Desde hace un tiempo vengo jugando con la idea de “desarrollar productos”.

En mi universo de fantasía, mi cabeza bulle con innumerables ideas para SaaS (Software as a Service).

Todos los días (de mi universo de fantasía) se me ocurre una idea, y son todas geniales.

Las voy anotando. Cada tanto elijo una y la desarrollo hasta llegar al MVP (Minimum Viable Product). La implemento (así de fácil y divertido, con una sola palabra, una única acción) como servicio gratuito.

La promociono (otra acción puntual, única, instantánea) utilizando “círculos concéntricos”: empiezo con un grupo reducido de usuarios y, a través de prueba y error voy depurando, limando asperezas, agregando detalles. Una vez agotadas las correcciones (porque se agotan) paso a un círculo de promoción más amplio y vuelvo a empezar.

El desarrollo es incremental, constante, continuo. La base de usuarios se expande. Se genera el feedback suficiente para determinar funcionalidades por las que un subconjunto de ellos estaría dispuesto a pagar (subconjunto que existe y cuyo tamaño es directamente proporcional a la cantidad de funcionalidades, por supuesto). 

Cada usuario paga poco, muy poco. Digamos siempre menos de “10” (dólares, pesos, yenes… no sé, no importa), pero por mes. La cosa “pega” y alcanza un cierto nivel de tráfico, y complemento ingresos con publicidad.

Y ya es hora de dejar este producto estable, tomar otra idea y volver a empezar. La mayoría de los proyectos no llegarán a tanto, pero algunos pegarán, aunque sea mínimamente. Entre todos van dejando un nivel de ingreso que se vuelve razonable en un futuro a mediano plazo.

Me gusta esa sensación de vuelta a lejanas épocas en las que me sentaba en la Atari 800XL y programaba cualquier cosa que se me viniese a la cabeza por el gusto de hacerlo y nada más, plus reconocimiento social (¡los usuarios me adoran!) y monetario.

Eventualmente la pego con algo y vendo algún desarrollo por 7 u 8 cifras. Hago donaciones a proyectos filantrópicos y con el resto me dedico a recorrer el mundo en mi avión privado (con barra). Están invitados.

… y después suena el despertador y tengo que levantarme a trabajar.

Y mientras trabajo pienso que no parece tan fantástico. Parece realizable, incluso fácil.

Por suerte soy bastante escéptico, sobre todo con mis propias fantasías. Otro thread (el pesimista) levanta una interrupción y dice que si fuese tan fácil y divertido todo el mundo lo estaría haciendo (y con éxito). Muchos lo hacen y les va bien (se despierta el primer thread –el optimista-). Son el emergente (responde el pesimista), la punta de un iceberg de proyectos hundidos por los pocos recursos (tiempo, dinero), las malas ideas, las malas ejecuciones, la mala suerte… la puta vida de mierda (y siguen discutiendo en un abrazo mortal).

¿Una fantasía irrealizable o un modelo sustentable? Sólo hay una forma de saber.

Así que me decidí a jugar en serio. Agarré la idea menos prometedora y más divertida y me comprometí a llevarla a través de todo el recorrido, desde el MVP hasta la primera versión hasta la base de usuarios y de ahí hasta donde se pueda.

¿Por qué “la menos”? Para bajar expectativas. Para no desilusionarme ante la falta de éxito inmediato. Y para cometer todos los errores posibles con una idea que ni es original ni vale tanto ni es taaan difícil de implementar, porque (en la vida real) ideas no me sobran y cuando tenga otra (en realidad… no tenía ninguna otra), espero que mejor, no quiero quemarla en un proceso de aprendizaje desde 0.

No es el proyecto en sí lo que importa sino el camino recorrido, los errores cometidos, la experiencia de hacer por uno mismo todo aquello que antes hacían otros miembros de un equipo u organización: la definición, las pruebas, la promoción, el seguimiento, el jiu jitsu comercial y otro montón de cosas que ni siquiera sé que hay que hacer.

En eso estuve estos meses. Algunos de “ustedes” (supongo que somos más o menos  los mismos lectores de siempre) saben de qué la va. La mayoría no y por ahora vamos a dejarlo así, porque estamos en la etapa de los “pequeños círculos concéntricos”.

“Sabía” que la construcción de un sistema es apenas una parte de la cosa. Ahora sé que lo que “sabía” y lo que “sé” va entre comillas.

Una cosa es saber que hay que definir un MVP y que eso es “difícil”, a tratar de hacerlo y darse cuenta de que es MUY difícil.

Una cosa es saber que un proyecto compite con otros y con la necesidad de ingresos, y otra la tentación constante de dejarlo “hasta acá, total para prueba ya está bien” y volver a terreno seguro.

Una cosa es saber que es difícil atraer usuarios y otra estar sentado delante de la pantalla, con el sistema “a disposición de la humanidad toda” y… “¿y ahora qué?” La humanidad está ocupada en sus propias cosas.

Una cosa es saber que hay que hacer networking y otra no tener nada importante para escribir o no tener ganas de sentarse y escribirlo o tomarse el esfuerzo y que no suceda nada (que por otro lado es lo más probable) y juntar los pedazos para probar otra vez.

Y en cada paso hay errores y torpezas y un millón de piedras puntiagudas para pisar.

Termino con lo que quería empezar (se suponía que iba a escribir un solo párrafo de introducción a esto que sigue, pero bueno…): un punteo de lo nuevo que, más que aprender, “sentí en carne propia” durante estos meses.

• “No sabes nada, Jon Snow”.
  
• Uno define un producto en documentos y palabras y bocetos de pantallas y eso está más o menos bien… pero hasta cierto punto. Los documentos iniciales quedan rápidamente en el olvido. No vale la pena dedicarles mucho tiempo ni bajar mucho al detalle: el objetivo principal de la aplicación, un boceto así nomás de “la pantalla importante” y listo. El objetivo no es elaborar el documento sino la idea.
  
• Personalmente, no funciono muy bien con el micromanagement del tiempo. Me entusiasmo por momentos, me desinflo por momentos. Es mejor respetar eso, pero manteniendo un balance: Hay que hacer algo todas las semanas, aunque sea forzado, y no dejar nada colgado mucho tiempo. 
  
• Sí me funciona bien el establecer una meta a corto plazo: “lo próximo que hay que hacer es…”
  
• Un dashboard es imprescindible. No puedo dejar de recomendar Trello.
  
• Medir las horas es imprescindible. No puedo dejar de recomendar Toggl.
  
• Definir y respetar hasta dónde llega el desarrollo para la primera implementación. A rajatabla. Y cumplirlo. A medida que voy armando la pantalla se me ocurren 10.000 formas mejores de hacerlo, sólo por contraposición con los problemas que veo en el armado actual… Pero esas otras formas también van a tener problemas y llevar a otras soluciones y… así no terminamos más. Se define la primera implementación, se hace y después vemos.
  
• Después de un par de meses de desarrollo, la idea original puede parecer una mala idea. ¿No debería empezar de nuevo? No. Así como hay que probar que es una buena idea, también hay que probar que es una mala idea antes de dejarla por el camino. Y para eso hay que implementarla.
  
• Otra vez (y van tres): respetar el MVP a rajatabla. Escribir en el backlog es muy terapéutico para descargar tensiones. 
  
• Pero ojo, el backlog puede convertirse en una bolsa de gatos muy rápidamente. Hay que mantener el orden, priorizar, jerarquizar, descartar, agrupar, dedicarle un poco de tiempo cada vez, pero constantemente. Es un embole, sí.
  
• Con el primer usuario cambia absolutamente todo. Lo que parecía usable es obvio que no, las buenas ideas resultaron malas y la sensación general es, otra vez, la de que esto no va a ningún lado (un pensamiento recurrente). Hay que perseverar, corregir y mejorar sin torcer el rumbo, resistir la tentación de “barajar y dar de vuelta”.
  
• Después de la primera implementación se acabaron las ideas, hay que seguir a los usuarios: se arregla o mejora lo que se usa, se implementa lo que nos reclaman. Primero hay que hacer que funcione, pero después todo se trata de que se entienda y se use, y eso es mucho más difícil.
  
• Y si nadie lo usa y nadie reclama… insistir con el autobombo y la promoción.
  
• Y si nadie lo usa y nadie reclama (después de un tiempo)… bueno, ahí quedó.
  
• … pero meter un feature que nadie quiere de vez en cuando sólo porque es divertido mantiene el entusiasmo.
  
• En resumen: POCO de todo para la primera versión: pocos documentos, poca funcionalidad, poco código, poca complejidad, poco riesgo, poco tiempo perdido.
  
• Salvo paciencia. MUCHA paciencia.

Paradigmas.

Los desarrolladores somos –¿hipótesis?- ante todo humanos, luego usuarios, luego desarrolladores.

Como humanos –entre otras cosas-, tendemos a sobrevalorar la propia experiencia. Por ejemplo, si el sistema que desarrollamos nos es fácil de utilizar solemos atribuirle esta característica obviando el hecho de que hemos aprendido a utilizarlo “desde atrás” (es decir, desde el código, el diseño o los requerimientos) y no “desde adelante” (desde la pantalla, los manuales o la capacitación). Para cuando nos enfrentamos a la pantalla de inicio ya sabemos casi de memoria todo lo que sigue. Abstraerse de este conocimiento es –por más que me juren y recontrajuren- imposible, y es por eso que nuestras pruebas y experiencias personales son bastante objetables como medida de lo que sucederá en el mundo real. Esto se aplica, con variaciones, tanto a desarrolladores como a analistas, testers, líderes de proyecto y a cualquiera implicado en el desarrollo de software (excepto, claro está, al cliente y al usuario).

Además de humanos –si es que damos por válida la hipótesis-, somos usuarios de sistemas de un determinado negocio: entornos de desarrollo, clientes de bases de datos, herramientas de diseño y documentación de requisitos, entre muchos otros, conforman el software de soporte al negocio del desarrollo de software. Negocio en el que estamos inmersos y que, como todos, tiene su paradigma establecido y materializado en la forma de determinados estándares: flujos de trabajo, herramientas visuales, disposición física de los objetos en una oficina… todo lo que nos rodea se deriva de éste en alguna medida.

La importancia de estos elementos –paradigma y estándares- que sobre el papel parecen un conjunto arbitrario de caprichos funcionales -¿por qué Ctrl+U y Ctrl+Shift+U? ¿Por qué un árbol y no una serie de listas encadenadas?- radica en que condicionan toda nuestra visión de la realidad (¡vaya si estamos condicionados por los paradigmas de nuestro negocio!). Los sistemas -si pretenden ser exitosos- deberán respetar –o revolucionar, pero esto es más difícil-, sobre todo en la interacción con sus usuarios, los paradigmas del negocio para el que fueron diseñados.

Como desarrolladores que somos –de eso sí estamos seguros- nos sería imposible, si estuviésemos librados a nuestro criterio, no aplicar el paradigma y los estándares propios del negocio al que pertenecemos –el desarrollo de software- a los sistemas que desarrollamos.

El problema es que, como establecimos más arriba, otros negocios o actividades tienen estándares y paradigmas diferentes. Internalizarlos es prácticamente imposible (deberíamos ser, por ejemplo, tan usuarios de distintos sistemas de gestión como lo somos de distintos entornos de desarrollo, tanto como lo es un empleado administrativo que ha transitado por diferentes empresas y puestos). Sólo podemos pretender, a lo más, conocerlos. Y para ello se requiere de una experiencia… “presencial”. Es la experiencia que trata de transmitir el analista funcional, el área comercial o quienquiera que tenga contacto directo con el cliente.

Pero un modelo mental es algo realmente difícil de describir, los estándares que se deriven de éste serán en su gran mayoría reglas y prácticas comunes y no estarán explicitadas en ningún lado. Es, en definitiva, difícil de transmitir. Por todo esto, cuantos más intermediarios haya entre aquellos que conocen a los clientes y usuarios y los desarrolladores, más probabilidades habrá de que nos apartemos del paradigma y los estándares a los que ellos están acostumbrados.

Frases: Comentarios (en el código).

// sometimes I believe compiler ignores all my comments

Visto en Incognitosis… no se pierdan la fuente original: ¿Cuál es el mejor comentario en código fuente que has encontrado? en stackoverflow.

Siguiendo el rastro del WTF.

Una tarea que se perfila como rutinaria puede transformarse inesperadamente en análisis forense funcional.

La asignación -más que rutinaria, aburrida-, era migrar un reporte del sistema viejo al nuevo. Usualmente se resuelve con un par de adaptaciones y listo, pero…

Mi primer descubrimiento en la tarea comenzó consistió en el procedimiento almacenado más enrevesado que vi en mi vida: una sola instrucción SELECT de más de 300 líneas, con tres niveles de subconsultas y un par de UNION’s en cada uno de ellos. Un bonito WTF.

Por supuesto que una maraña de código de ese calibre no es puntual ni tiene un sólo padre. Es el producto más paradigmático (entre muchos otros) de una larga cadena de producción de basura útil. Una cadena de errores que puede recorrerse hacia atrás desde la codificación hasta la gestión del proyecto.

La codificación, ilegible, traicionera y escurridiza, es el producto de “construir un rascacielos con ladrillos”. Es decir, se pretende resolver  todo el problema con una sola herramienta (¿qué necesidad había de hacer todo en una sola consulta?) en vez de separarlo en partes y aplicar a cada una la más adecuada.

No tiene sentido buscar un culpable, obviamente no lo hay. Si bien el código nació medio enrevesado fueron las sucesivas modificaciones las que lo volvieron caótico. Un buen ejemplo de la parábola de la rana hervida: pequeñas modificaciones, todas ellas muy inocentes tomadas en forma individual, generan un bonito quilombo desastre.

Lo que nos lleva a la metodología. Una refactorización a tiempo hubiese cortado este problema de raíz. Es claro, por la estructura de la consulta (bloques SELECT conectados por UNION’s que agregan casos no contemplados, subconsultas que vinieron a reemplazar referencias a tablas, cálculos repetidos que producen pequeños ajustes sobre el  resultado sin alterar la estructura, reutilización de campos para agregar datos “sin tocar nada”, etc.), que su creador sabía mucho más al final del proceso que al principio. La refactorización no sólo es imprescindible para mantener el código legible a través de las sucesivas modificaciones, es la actividad con la que se solidifica el aprendizaje, el momento en que lo aprendido se transforma en código. Aquel primer autor partió tiempo atrás y todo el conocimiento acumulado, por lo menos en lo relativo a esta experiencia en particular, se ha perdido irremediablemente (snif).

Esto es triste, sobre todo combinado con el hecho de que luego de un tiempo este código se ha convertido en la única documentación existente sobre la funcionalidad.

Lo que nos lleva al segundo error metodológico: ¿cómo transmitió el sector de análisis las especificaciones del reporte? No lo sabemos. El sólo hecho de que no lo sepamos hace de esa transmisión un acto fallido. ¿Fue verbalmente? ¿Se elaboró un documento? En todo caso, la falta de un soporte o repositorio confiable hizo humo (o leyenda) ese trabajo de análisis.

El que crea que el conocimiento puede preservarse “solo” en la cabeza de los integrantes del equipo puede acompañarme en la experiencia de consultar a las personas directa o indirectamente involucradas con una funcionalidad en particular. Lo que se obtiene son varios pedazos -ligeramente diferentes y que no encajan del todo- de la misma fotografía. Los detalles… “mirá el reporte en el sistema viejo”, con lo que volvemos a nuestro querido e ilegible procedimiento almacenado.

Entonces el problema es no de una o unas personas sino de todo el equipo. Nadie trabajó aislado. El analista hizo su trabajo, el programador hizo su trabajo. ¿Entonces? Lo que ha fallado es la interacción entreambos. La falta de visión a futuro (o la indiferencia con respecto a él), o un exceso de individualismo (“sólo hago mi trabajo”).

Los problemas de equipo son, por definición, de liderazgo. Cuando las partes no coordinan bien entre sí es necesaria la intervención de un elemento superior que modifique esa interacción: por caso, el líder. Por complicidad, desconocimiento o falta de soluciones (es irrelevante) eso no ha ocurrido.

Esta basura útil, este “cowboy code” incrustado en medio de un “pure chaos environment” funciona. Y bastante bien, por cierto. Entonces, en la mirada miope o distraída de líder, el equipo debe haber superado con creces el desafío, que quedó cerrado y archivado definitivamente.

El siguiente eslabón de la cadena es organizacional. La vara (ya sea para medir o aleccionar) más común en las organizaciones es el costo/beneficio. El costo de no haber documentado el análisis y refactorizado el código ha pasado desapercibido, lo que ha devenido en una medición inflada del resultado final, generando un pernicioso condicionamiento positivo respecto del apuro y la desprolijidad. Tal vez una medición más precisa del costo a futuro de esas desprolijidades hubiese motivado una corrección más temprana.

Esta última observación excede el ámbito de la gestión de un proyecto. Está más relacionada con la estructura de costo de la organización, del sistema que utilice para medirlo y de cómo se utilizan esas mediciones. El costo de este retrabajo, originado en aquél otro proyecto que salió “tan bien” y fue “tan rentable” pesará sobre este nuevo proyecto.

En fin, hemos comenzado hablando de procedimientos almacenados y prolijidad del código para terminar en cálculo y gestión de costos a nivel organizacional. Hemos recorrido, a través de un divertido ejemplo la cadena que une el error con la pérdida (en el mejor de los casos) o el fallo con la catástrofe (en el peor).

Requerimientos de la gestión y soluciones sistémicas.

A la hora de satisfacer las necesidades de información de la gestión de un proyecto informático podemos aplicar esfuerzo adicional (una serie de acciones para recabar esa información intercaladas en el trabajo diario) pero difícilmente logremos mantenerlo durante mucho tiempo.

Sobre todo cuando por “esfuerzo adicional” entendemos hacer una parada en el desarrollo, revolver dolorosamente viejos papeles desordenados (a veces ni eso) y rellenar agujeros de memoria para terminar garabateando con desgano un par de números más o menos dibujados en forma de informe de avance.

Una solución sistémica para esas necesidades requiere una visión más amplia y más esfuerzo inicial pero logra que la información surja naturalmente del flujo de trabajo e incluso que lo acompañe de forma tal que en lo sucesivo el esfuerzo sea menor.

Estuve jugando mucho con esa idea, enfocándola primero hacia el tema de los errores en Parches y soluciones y relacionándola después con el conocimiento que aportan a la organización (plasmado en circuitos administrativos estables), en Implementando y manteniendo soluciones. 

Hoy encontré en Ideas + Ingeniería del Software (aunque llego con un poco de atraso) un artículo sobre trazabilidad que tiene mucho que ver con esto y del que me ha quedado especialmente la frase final:

“¿Moraleja? Si tienes que forzar a tu equipo a algo, la culpa no es del que no te hace caso, sino tuya. Las herramientas adecuadas para las tareas adecuadas.”

Hay que tener en cuenta que no es necesario inventar nada, la solución y las herramientas ya están ahí afuera (aunque habrá que hacer algún ajuste, eso seguro).

Al fin y al cabo son necesidades comunes a todos los equipos de desarrollo –a la gestión de cualquier proyecto-, por lo que en la práctica han surgido muchas alternativas y varias de ellas han sido formalizadas en metodologías. ¿Por qué no utilizar esa experiencia?

Medir la calidad de los requerimientos.

Los requerimientos cambian. Todo cambia.

La revolución de las metodologías ágiles no ha hecho más que establecer el factor cambio como inherente al desarrollo e integrarlo en el proceso (a través de ciclos cortos de desarrollo, reuniones periódicas, programación de a pares, programación orientada al test y un sinnúmero de otras técnicas) en vez de combatirlo (con planeamientos detallados, seguimientos rigurosos, requisitos enciclopédicos, etcétera).

Sin embargo, “eXtreme Programming es un arma peligrosa”:

[…] Se suele utilizar XP menos para desarrollar que para defender lo indefendible y justificar lo injustificable por la supuesta búsqueda de "agilidad" […]

Hablando de requerimientos, tengo la sensación de que muchas veces se esconden gruesos errores bajo una alfombra maloliente etiquetada “cambios en el negocio”. ¿Cuándo hubo un cambio en el negocio y cuándo un error al elaborar los requerimientos?

No estoy hablando aquí de errores de interpretación de un término o de la existencia de ciertas áreas grises en las definiciones, porque errores de ese tipo se van corrigiendo en la medida en que avanzan las iteraciones y el equipo toma conocimiento del negocio.

Estoy apuntando a cuando se producen repetidamente (casi diría sistemáticamente) errores de procedimiento o metodológicos al efectuar los relevamientos o al producir y comunicar los requerimientos. Es decir, errores que afectan a todos y cada uno de ellos porque son fallas de los procedimientos, de la metodología o de las personas involucradas en su producción.

Me mencionaron alguna vez el caso de una empresa en la que los requerimientos llegaban en forma de gráficos perpetrados en un lenguaje pseudo-uml que ningún programador entendía. Finalmente, lo único útil del documento era el nombre del analista. Se fijaban quién era, lo llamaban y (si estaba disponible) le preguntaban qué había que hacer. Pero el problema era que esta charla informal no tenía ningún soporte ni revisión dentro del circuito de desarrollo, y usualmente los requerimientos se… digamos…. “modificaban” durante su transmisión. ¡Un fin de semana largo y su consecuente amnesia podía redefinir sustancialmente el proyecto!

Nótese que en presencia de este tipo de problemas las sucesivas iteraciones pueden alejarnos más y más de lo que el cliente quiere, porque el canal de comunicación entre él y el equipo de desarrollo está roto o tiene demasiado ruido. En nuestro ejemplo, ruido en la forma de dibujos incomprensibles pasados como requerimientos. Más valdría, por ejemplo, formalizar esas “charlas” como una instancia de elaboración de un documento simple y que todo el mundo entienda, tal vez directamente en idioma coloquial y con algunos dibujos hechos a mano.

Si tenemos contacto asiduo con el cliente (deberíamos), los problemas se notarán más temprano que tarde. Él mismo indicará claramente (muy) que no está recibiendo lo que pidió. Pero imaginemos que no sabemos nada del origen de esta discordancia. Puede venir por el lado de los requerimientos, pero no lo sabemos.

De alguna manera hay que medir, al menos aproximadamente, la calidad del proceso de relevamiento y la de los requerimientos mismos. Esto implica analizar, para alguna muestra relevante:

• el ajuste con respecto a la solución finalmente implementada. ¿Estamos contactando a las personas correctas en el cliente?

• el ajuste respecto a lo que el cliente o sus representantes expresaron. ¿Los clientes son bien interpretados?  

• el grado de claridad o precisión que le asignan los desarrolladores (que son finalmente los consumidores de esos requerimientos). ¿Los requerimientos están bien redactados o presentados?

• el grado de ajuste de la herramienta de soporte o metodología utilizada. ¿Es fácil producir un soporte estable para cada requerimiento? ¿Ese soporte los altera de alguna manera? Recordemos que por más ágiles que seamos, deberemos almacenar por lo menos los requerimientos en curso sin que sean modificados (involuntaria y/o inadvertidamente) de manera que alguien pueda consultarlos con seguridad ante alguna duda.

• La calidad del análisis efectuado sobre cada uno. ¿Se detectaron interacciones con otras partes del sistema? ¿Se evaluó bien la coherencia del requerimiento?

El problema está en encontrar indicadores para estas mediciones, ya que me parecen bastante… sutiles.

Por ejemplo, es “normal” que algunas interacciones entre nuevos requerimientos y otras partes del sistema no sean detectadas, ya que el análisis análisis previo es breve y a grandes rasgos. Pero otras interacciones son obvias y que sean pasadas por alto es significativo.

Por otro lado si somos muy ágiles y prima la comunicación informal, medir algunas cuestiones implica “muy poco indirectamente” medir el desempeño. Necesariamente habrá que preguntar “¿Se entiende cuando ZZZ explica lo que hay que hacer?” y esto generaría una recelo excesivo.

Es todo cuestión de encontrar las preguntas… qué novedad.

Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

A veces me pongo extremista y veo al desarrollo de software solamente como un sistema de comunicación. Si lo vemos como una caja negra, se trata de de transmitir y traducir los requerimientos en una serie de instrucciones que un hardware pueda ejecutar, llevando a cabo la tarea que estos requerimientos representan. Por lo menos idealmente.

Si abrimos esa caja negra, encontraremos varios "puntos de retransmisión y traducción", que más o menos se corresponden con las etapas de relevamiento, análisis, diseño y codificación. Cada etapa nos acerca más desde el lenguaje del emisor (el cliente) al lenguaje del receptor (ese equipo de hardware).

En resumen, los requerimientos son el mensaje, el cliente es el emisor y el hardware que finalmente debe ejecutar la secuencia de instrucciones acorde es el receptor. En el camino tenemos varios retransmisores, algunos humanos y otros no: analistas de negocio, analistas funcionales, programadores, entornos de desarrollo, compiladores, personal de soporte al cliente (al instalar), sistemas instaladores. El mensaje se transmite a través de varias formas y a través de varios medios: oralmente, por escrito, electrónicamente.

Bajo esta óptica, somos retransmisores al tiempo que traductores.

Como en todo sistema de comunicación, hay ruido de fondo y ruido generado por el propio sistema. Ambos tipos de ruido deforman inevitablemente el mensaje. La comunicación perfecta no existe, por tanto tampoco existe el software perfecto.

Siguiendo por este camino, en el que suelo entretenerme inventando y perfeccionando analogías, llego usualmente a la siguiente conclusión (bombos y platillos):

La calidad del software depende de es la fidelidad con la que el equipo transmite un mensaje, por ello todos los participantes de un equipo de desarrollo de software deben ser excelentes transmisores de información.

De nada sirve ser un experto programador, analista o visionario del negocio si no se puede transmitir fielmente esa información a través del proceso de desarrollo.

Transmitir implica básicamente dos tareas: recibir y enviar. Incluso un programador independiente que trabaja absolutamente solo debe ser un experto escuchando o leyendo al cliente (recibiendo) y programando (enviando).

Recibir es usualmente escuchar, leer. Transmitir es usualmente hablar, escribir.

El problema de escuchar y hablar es que, como se dice coloquialmente, a las palabras (y muchas veces a las personas que las pronuncian) se las lleva el viento.

¡Cuidado! Ahí vienen los pseudo-ágiles: que el exceso de documentación, que la comunicación informal, que los cambios continuos y un largo etcétera.

¿Cuál es la diferencia entre pseudo-agilidad y verdadera agilidad?

En el desarrollo pseudo-ágil no se preserva nada. Llegamos al punto de encuentro con el cliente y estamos solos. ¿Qué pasó? No tenemos idea.

En el desarrollo ágil se preserva solamente lo indispensable: el mensaje, los requerimientos. Es absolutamente minimalista: hay que preservar sólo el mensaje, pero hay que hacerlo como si fuera la vida misma, y verificar continuamente que no haya sido malinterpretado por nadie. Como recalqué muchas veces: tal es así que en XP las historias del usuario las escribe el mismo usuario, y éste es parte del equipo. Creo que solamente por una cuestión legal las cadenas para retenerlo cerca del equipo (que seguramente figuraban en los primeros bocetos) fueron finalmente suprimidas.

Aclarado que tenemos que preservar al menos el mensaje original, los requerimientos, el tema es cómo.

Me agarra el viejazo cuando me vuelvo tradicionalista, pero todavía nadie me convence de lo contrario: el texto es el rey. Es la herramienta más sencilla para el conjunto de actividades que se realizan alrededor de los requerimientos: recibirlos, discutirlos, modificarlos, transmitirlos, catalogarlos, archivarlos, buscarlos.

Pensemos en otros soportes posibles. Omito los puntos "catalogar" y "archivar" ya que con las herramientas disponibles serán sencillos para cualquier soporte.

Los gráficos son más difíciles de producir y modificar, aunque usualmente mejores para discutir y transmitir. La búsqueda no es sencilla, justamente porque contienen poco texto.

En cuanto a imagen y sonido, grabar la descripción de los requerimientos parece una buena idea, pero no me parece un soporte fácil para recibir o discutir, mucho menos de modificar. No me imagino en una reunión diciendo "poné de vuelta esa parte... no... un poco antes... ahí, ¿no debería decir...?" La transmisión es más complicada y la búsqueda sólo puede realizarse bajando el contenido a texto.

Recordemos que hablamos de requerimientos que cambiarán continuamente. A mayor complejidad mayor resistencia al cambio. Y cambio en los requerimientos es moneda corriente.

Así que si me preguntan a mí, texto.

Resumen: habilidades a valorar en un integrante de un equipo de desarrollo (¿o mejor dicho, de un equipo, a secas?): leer y escribir (porque si no a las palabras -o al integrante- se las lleva el viento). ¿Alguna vez los evaluaron en eso en una entrevista de trabajo?

BTW: Menudo título, ya sé, pero estoy cansado de aparecer en cualquier lado por hacer bromitas con los títulos de los post. No lo hagan.

Documentación

Primero lo primero: ¿de qué documentación estoy hablando? Tenemos diferentes tipos de documentos que cubren absolutamente todo lo que puede ser documentado: qué, quién, cómo, cuándo y por qué.

Quiero enfocarme en la documentación interna del equipo desarrollo, aquella que dice cómo se deben hacer las cosas. Documentación que debería responder, por ejemplo, a este tipo de preguntas: ¿cómo me conecto a una base de datos? ¿cómo hago una consulta? ¿cómo armo una pantalla? ¿cómo le presento los mensajes al usuario?

Si se pretende cierta unicidad entre diferentes módulos de un sistema o entre diferentes desarrollos de una misma empresa implementados por diferentes personas es indispensable un marco de trabajo, un framework propio que se montará sobre la herramienta de desarrollo que estemos utilizando. Este framework constará no sólo de herramientas de código (clases, interfaces y demás) sino de prácticas comunes para organizar proyectos, carpetas, nomeclatura, etc.

Ahora, una cosa es que este framework exista y otra el grado en que es efectivamente utilizado por los desarrolladores. Y esto dependerá en buena medida de la documentación que exista acerca del mismo. Por ejemplo, cuando un nuevo integrante se incorpora al equipo es indispensable poder entregarle un manual que detalle los estándares de estilo utilizados, las herramientas que puede y debe utilizar para llevar a cabo las tareas comunes, los estándares visuales de la interfaz del usuario. Una vez estudiados e internalizados estos documentos podrá comenzar a trabajar....

No, mentira.

Conozco (de oídas) de empresas en las que esta documentación existe. Incluso me han contado de casos en los que es frecuentemente actualizada (por ejemplo para cumplir con alguna norma o estándar certificado). Actualizados o no, los usos más frecuentes de este tipo de papeles son la elevación de monitores de plasma (¿vieron que en algunos modelos los soportes son demasiado bajos y no son ajustables?), la recolección de polvo, la decoración de bibliotecas y estanterías (quedan muy feas cuando están vacías) y otros por el estilo.

Cuando un nuevo integrante se suma al equipo, es usualmente depositado frente a una computadora y una pila de CD's de instalación. Ése es su primer día. A fin de evitar que quede atrapado en los brazos de morfeo se le entregará la documentación de la que hablaba en el párrafo anterior, si es que existe (usualmente con efectos opuestos a los que se prentendían). Si no existe y la gente no está muy ocupada, charlará un largo rato. Si la gente está ocupada... Consejo: no está de más llevar una revista el primer día. Con suerte podrá abrir el proyecto antes de irse a casa.

El segundo día lo verá enfrentado a un mar de código y (con suerte) una tarea entre manos. Si la documentación existe y ha sido leída, e incluso retenida, probablemente sea encontrada tan irrelevante como la tarea a desarrollar.

Pero las cosas funcionan, uno se desarrolla, aprende... el secreto está en la documentación. La verdadera documentación.

En algún momento, por obligación, lástima o caridad, alguien se acercará al nuevo integrante y le dará una visión general de lo que está viendo. Con eso podrá investigar un poco más en el código. Después de comer (charlando sobre la estructura del proyecto) se baja un poco más a detalle, siempre de palabra, "después lo ves en el código"... y así.

¿Qué pasa cuando no hay nadie que pueda llevar a cabo esa capacitación informal? Lo mismo, pero es mucho más lento. El nuevo integrante empezará a mirar primero la estructura general y bajará al detalle de a poco. O tal vez empiece buscando el lugar donde tiene que realizar su pequeña asignación y siga las ramificaciones desde ahí... las técnicas son tan variadas como las personas.

Pero... ¿de qué se trata este artículo? ¿documentación interna? ¿establecimos que no sirve? ¿listo?

Arriesgo una teoría. Lo que muchas veces sucede (recalco: por lo menos en mi personalísima experiencia) es que la documentación es requerida por alguien ajeno al equipo de desarrollo: el líder de proyecto, el gerente de sistemas, una norma, una metodología de trabajo (que nos dice "es necesario tal y tal y tal otro documento"), etc. En estos casos la documentación está obviamente orientada a cumplir con ese objetivo o requerimiento en el momento en que debe ser cumplido. Servirá para eso y nada más. Cuando intentamos utilizarla para otra cosa (por ejemplo para instruir "al nuevo") fracasa como fracasarían nuestros sistemas de facturación si intentáramos hacer que controlen los motores de un barco.

Si necesitamos tener documentación interna de referencia, tendremos que pensar en esa situación y crearla con ese único objetivo en mente. Recalco **necesitamos**. Como todos los sistemas, y la documentación ES un sistema, si no hay una necesidad real, jamás será utilizada. Si el equipo es estable y las incorporaciones esporádicas, será mucho más fácil capacitar al nuevo de palabra, y es lo que sucederá. Si el código es claro, de manera que en cada capa de la aplicación el código existente sirve de referencia para lo nuevo, tampoco habrá nada más que consultar, y así. Ahora, si en el equipo hay alta rotación habrá que bajar esa charla informal de la que hablábamos a papeles, o darla todos los días (cualquiera prefererirá lo primero). Si estamos trabajando en mantenimiento con mucho código heredado, enmarañado y confuso, será mejor que cada vez que descubramos alguna estructura o subsistema lo anotemos prolijamente en un documento aparte, porque volver a leerlo desde el código no será fácil.

Les aseguro que así es más fácil, e incluso entretenido documentar.

Ensayo una lista de "buenas prácticas informales":

• La primera fuente de documentación interna es el código. La respuesta más frecuente a "¿cómo se hace tal cosa?" es "fijáte en tal lado y seguí la idea". Tratemos de documentar con el código o en el código.
• Si hay que documentar tareas comunes, pocas palabras y muchos ejemplos extraídos de algún sistema.
• Si hay que documentar estructuras de capas o flujo de ejecución a través de diferentes módulos, lo más sencillo de entender son los gráficos, con referencias a la ubicación en el proyecto del código correspondiente. Son molestos de hacer y mantener, es cierto. Pero relatar el proceso de impresión de un reporte desde la toma de parámetros hasta el deslpiegue del documento es mucho más difícil.
• Ubicar la documentación donde se la necesita. Es muy común tener una enorme bolsa llamada "documentos" donde hay que revolver para encontrar algo. Si tengo un documento que explica el acceso a datos, ¿por qué no adjuntarlo al proyecto junto con el código de la capa de acceso a datos?
• Tratar de que sea una tarea constante, no esporádica, que cualquiera pueda corregirla.
• Versionar, todo.

Proyecto de software típico.

Me acordé de esta secuencia, y estuve un buen rato buscándola por internet. No hay mucho mas que decir.