Broken Culture

Los norteamericanos tienen una capacidad increíble para estandarizar cualquier realidad y encajarla en un set de historias prefabricadas, por más compleja que sea. Si, todo el mundo estandariza y encaja realidades en historias… es sólo que ellos lo hacen especialmente bien.

Mis feeds de “desarrollo” en inglés están llenos de telenovelas: los programadores somos la mucama inteligente, buena y fea; los managers, la malvada bomba sexy; la empresa (el capitalismo), el millonario que parece malo por estar atrapado sus redes pero que en el fondo es bueno. El final es cantado: la mucama inteligente se gana el corazón del millonario a fuerza de honestidad, bondad y trabajo duro, y en la última escena es la que está más buena de todas. La mala cae envuelta en sus propias telarañas y termina desenmascarada como la chupasangre inútil que es, desterrada en quién sabe dónde.

Tim Chevalier toma la decisión de abandonar la telenovela-sistemas y da sus razones. Después Michael O. Church sintetiza esas razones en una pregunta: “Can tech fix its broken culture?”, y responde “si” pero con más palabras. ¿Y cómo? Como dicta la trama: resistiendo los ataques del management-malvada-bomba-sexy y demostrando valía con honestidad, inteligencia y trabajo duro (y muy poca paga) hasta que el capitalismo-sociedad-millonario se de cuenta y expulse a los managers-malvada-bomba-sexy del juego.

La afirmación que más fuerte me suena en el post Michael no es “podemos reparar la cultura de sistemas”, sino otra mucho más desesperada y sutil: “hay una historia con un final feliz en el que los buenos que resisten son recompensados”.

En algún momento (allá lejos y hace tiempo) en el que hubiese coincidido (y hasta se podría buscar prueba de eso en este blog), un tiempo en el que lo “Agil” prometía ser la movida que desenmascararía las malvadas maquinaciones del management, demostrando de una vez y para siempre que los “techies” somos el verdadero corazón de las empresas.

Pero ahora, un par de años después, “Agil/Scrum” es más o menos lo mismo que “CMMI”. Todos los puntos de aquel manifiesto que hubiesen podido cambiar algo fueron ignorados o licuados; sólo quedaron las reuniones. ¿Y los tests y la integración continua y la nube y los frameworks y el open source…? ¿No son avances? Sí son avances… también las pantallas planas, los multi core, el wifi y los celulares… Pero el escenario es el mismo en el que se escribió The Mythical Man-Month (en 1975). Sólo cambió el decorado.

El argumento es “la mucama con esfuerzo llega al millonario”. En sistemas se dice “los techies programando van a dominar la industria”. El problema en la trama es “que la mala tiene al millonario engañado”. En sistemas, “que los managers son explotadores parásitos de la empresa”. Pero en ambos casos la industria/la empresa/el capitalismo siempre recompensa el valor generado. En última instancia verá quiénes generan el valor cuando los managers, a fuerza de incompetencia, caigan en su inevitable desgracia y se desencadene el final feliz.

En pocas palabras: hay que salir y mostrarle al mundo que los técnicos son los que generan valor. Siguiendo esa línea, si fuésemos adolescentes sobreexplotados de McDonalds deberíamos unirnos para revelarle al mundo que somos los que hacemos las hamburguesas.

Es una telenovela simplificadora que justifica lo que hacemos ante nosotros mismos mientras estamos dentro. Nos convence de quedarnos y nos explica por qué se van los que se van, separándonos de ellos para que no se nos ocurra tomarlos de ejemplo. “Cualquier parecido con la vida real”, lejos de ser casual, ha sido elaborado, refinado y corregido a lo largo de los siglos (si, siglos: Cenicienta) para identificarnos con la mucama-pobre-heroína de la trama mientras hacemos girar la rueda del molino, caminando en círculos hacia ninguna parte.

Como las telenovelas, es un discurso que no tiene ni pretende ser real ni tener sentido, sólo coherente y útil hacia dentro. Si uno rompe “la cuarta pared” y abandona el set ya no ve ni buenos ni malos ni lindos ni feos ni historia ni nada: sólo un montón de actores representando un guión más o menos delirante que no escriben ni escribieron.

Bueno, y “Can tech fix its broken culture?”

La “cultura de las empresas de tecnología” no está rota. La “cultura de las empresas” surge y prospera en tanto las hace funcionar, sobrevivir y prosperar… a las empresas, no a las personas. No está ahí para conseguir la felicidad ni el bien común de nadie… pero tampoco para impedirlos.

Personalmente creo que no hay nada que demostrar ni a quien demostrarle nada; nadie mirando, sólo nosotros mismos. No hay héroes buenos-pero-feos enfrentados a managers-malos-que-parasitan-las-empresas, ni millonarios naive a los que hay que llevar por la buena senda para bien de todos. Ni siquiera hay un “somos” ni un “son”: no hay una historia común encaminada hacia un final feliz, o hacia ningún otro lado. Lo que hay es un momento y un espacio y ciertas reglas más o menos fijas… A algunos les conviene el status quo, a otros no. Para los que no, a veces se puede y vale la pena dar la pelea por el cambio, a veces no.

De lo que estoy más seguro es de que no se toman buenas decisiones mirando telenovelas.

Todo lo demás.

Todavía le falta algo (dos “cositas”, en realidad) para llegar al “MVP corregido” (el “minimum viable product” redefinido después de haber subido lo que yo creía que era el minimum). Nadie me hizo llegar nada al respecto. El uso es la intersección entre la promoción y la necesidad, y uno sólo puede controlar el primer término. Sin necesidad, la gente juega un poco y listo. Si gusta se agenda el link para después. Está muy bien, pero no es “uso”.

¿Qué hubo entre esos dos MVP’s, además de esas “dos cosas”? ¿En qué cosas ni siquiera había pensado?

Le pongo Analytics y listo.

… no. Analytics está muy bien tal cual sale de la caja, pero se queda muy corto. Permite ver el impacto de un post, de facebook, de tweeter, del mail, pero nada más. ¿Y el uso? ¿Se usa el upload de esquemas? ¿El login con google? ¿El preview de datos? ¿La ayuda?

El event tracking no es difícil de implementar. Lo difícil es determinar qué trackear (qué acciones) cuando uno ya tiene todo desarrollado. Lo que no se trackea no se ve. Trackear un par de eventos y dejar por error dos o tres afuera implica tener una visión muy sesgada del uso. Si lo hubiese pensado desde el principio, agregándolo a medida que se desarrolla la funcionalidad, afinándolo desde el momento 0…

No, no es “demasiado para un MVP”. Saber hacia dónde dirigir el segundo paso es tan importante como dar el primero. Pero hay un argumento determinante por el cual no se puede dejar para después: recolectar un volumen de datos relevante lleva –con suerte- semanas.

Try-catch-mail alcanza, y por las dudas logueo todo.

Me mando un mail con la excepción y ya está bien para empezar, con eso ya sé dónde buscar en el log. No, tampoco. Cortísimo.

Ok, hubo un error. ¿Quién? ¿Haciendo qué? ¿Qué datos de entrada? ¿Qué valores de salida? Los errores que pueden corregirse mirando un stack trace se agotan rápidamente. Después… las cosas se vuelven más complicadas. El “log viewer” de la consola de GAE es por lo menos “rústico”. Excederse por más y generar 1Gb de log por día está bien cuando podemos comprimir, descargar el archivo y procesarlo tranquilamente, pero no es el caso. Una posibilidad es recolectar parámetros de entrada y valores de salida de todas las funciones pero loguearlos sólo cuando hay un error. O afinar el log para cada operación, o guardar los errores aparte, en la base… Lo que sea, pero no es tan simple como un try-catch-all.

Cada error es un usuario–casi-perdido, y usuarios no sobran.

Malditos celulares.

¿Para qué miércoles quiero dar soporte a celulares en un data generation tool? Si, que se pueda ver… pero no importa si no es usable, no es una aplicación que tenga sentido en un smartphone. Y en la primera versión ni eso, que se vea como se ve. Total foundation ya ayuda bastante sin que hagamos nada.

Error. La aplicación no se usa en un smartphone… pero el 50% (50% medido, no es un decir) de los usuarios entra por primera vez desde uno. ¿Por qué? Y… si promociono por twitter y facebook… ¿qué esperaba? No esperaba nada - señal de que estoy viejo.

No tiene que ser usable, pero es indispensable que sea “probable”, “jugable” o al menos “agendable”. Como mínimo –muy mínimo- que puedan decir “ok, avisáme después.

Lo ideal sería que se pueda jugar un poco, abrir una cuenta y grabar. Bueno… más trabajo (y esto no está incluido en “las dos cosas”).

Consola de administración.

Paráaaaa… ¿un backoffice para un data generation tool? Si.

Estoy usando objectify. Muy lindo, muy rápido el desarrollo de todo, pero… el acceso a datos desde la consola es incluso más rústico que el log. Lo que objectify graba ya es bastante difícil de leer… Si un error “rompe” la cuenta de un usuario (se graba algo y luego le da error cada vez que entra) estamos al horno: corregir esa especie de “assembler de datos” es demasiado peligroso o directamente imposible (ni lo intenté).

Guste o no hay que hacer una página de administración donde podamos ver la data en forma prolija y modificarla si es necesario. Y no podemos empezar a hacerla sobre el hecho de que ya hay alguien que no puede entrar a su cuenta. Y también va a tener sus errores.

Y todo lo demás.

Y, finalmente, las “dos cosas” de las que hablaba al principio. Esas son las únicas dos funcionalidades propias de la aplicación de toda esta lista. Pero no voy a decir cuáles son. Talvez ni hagan falta.

Una buena

Son cosas simples (aunque no “tan simples”) si se las tiene en cuenta desde el principio. Bueno, para esto era, ¿no?

Into the void.

Siguiendo con lo del post anterior, el desarrollo de “mi producto de prueba” entra oficialmente en la etapa de autobombo. Voy a tratar de no ponerme monotemático, así que el siguiente link es lo único que voy a poner explícitamente al respecto por ahora:

“Pasen y vean, qué lindas chucherías” (el que no entienda la referencia que busque la frase, vale la pena).

De alguna manera subestimé (para variar) el efecto psicológico del “lanzamiento”.

No había tenido que dar la cara hasta ahora. En mis trabajos anteriores picaba código que luego se testeaba e iba a producción donde fallaba miserablemente. Así fue siempre, igual que ahora. Pero la responsabilidad era compartida. La verdad sea dicha: las consecuencias inmediatas (llamados a media noche, apuros, gritos e insultos) solían recaer más en las áreas de soporte, testing y calidad (cuando había) que en mi escurridiza persona. No se puede hacer bugfixing con 20 monos desesperados gritándote alrededor y otros 20 por teléfono / skype / email / twitter / señales de humo avisándote de que el sitio no anda. Así que mientras yo arreglaba la cosa otros atajaban los sopapos.

Personalmente, esa división de tareas siempre me pareció (y me sigue pareciendo) bien. Pero ahora no hay con quién dividir el trabajo y, lo que es peor, nadie se desespera. Ojalá hubiese alguien tan necesitado de esta humilde herramienta (que feo suena eso) como para llegar al extremo del reclamo. Lo que sucede es algo peor: la nada misma. El vacío, fardos rodando, grillos a la luz de la luna.

Si te fuiste a dormir, tu sitio puede estar en llamas escupiendo 500 para todos lados que no te vas a enterar. ¿Los usuarios? Si te he visto no me acuerdo. Un amigo, un conocido o un familiar manda un mail con un “che, no anda” y con suerte te enterás a la mañana siguiente. Cada uno de esos desconocidos arrastrados a pulso, sangre, sudor y lágrimas (qué exagerado) ahora están viendo (si es que no se fueron ya) la aplicación retorcerse lastimosamente en medio de un infarto de javascript, con el pulgar en el Alt y el índice a punto de dar el Tab definitivo. Por lo menos en el corto plazo.

Por eso, si va a explotar (y al principio va a explotar), mejor que sea entre amigos dispuestos a dar una mano, avisar: probar de vuelta más adelate. Pero eventualmente hay que sacar la red y seguir haciendo piruetas. No es para tanto… si pinchó es que anduvo por un rato, ¿no?

The Gervais Principle

Para aquellos a los que les gusta (o no pueden para de mirar) The Office y se ríen (o lloran) con Dilbert y están dispuestos a leer largo duro y parejo, y a pelearse con un inglés un poquito más difícil que la media:

The Gervais Principle, Or The Office According to “The Office”

Para tentarlos y de paso tenerlos a mano para cuando se necesite, dos botones de muestra:

Ojo que es más serio que lo que parece. Lo encontré leyendo el blog de Erik Dietrich, también recomendable para agregar al feed.

PD para cuando lean un poco de eso: yo me considero claramente un looser, y -creo- es fácil distinguir a los sociopaths (antes de que alcancen el nivel al que sólo ellos pueden llegar, si no pierde la gracia)... lo divertido es ponerse a discutir quiénes son los clueless. Tengan en cuenta que no todos son tan "puros" como Michael.

La integración de la base de datos. Una cura definitiva para esta enfermedad crónica.

Una colaboración de Martín Gargiulo (*).

---

Es muy común que los equipos de desarrollo trabajen sobre un ambiente de base de datos compartido. ¿Quién no ha sufrido las consecuencias de los desfasajes entre *la* base de datos y el resto del proyecto? ¿Quién no ha sido víctima –o victimario– de algún improperio cuando, en pleno desarrollo, un cambio en alguna propiedad u objeto de la base deja al resto del código pataleando en el aire?

Nunca, desde mis tempranos inicios, a través de diferentes proyectos en varias compañías, tuvieron estas cuestiones la suficiente importancia como para quitarle el sueño a nadie. Siempre, esto es lo realmente grave, parecieron ser lo normal. Estaba ante una enfermedad crónica.

Desarrollar implica agregar código, depurar, refactorizar y repetir estas operaciones un número de veces hasta obtener una determinada pieza de software. A nadie se le ocurre, hoy en día, que no se disponga de un sistema de control de código fuente, que permita a cada integrante del equipo trabajar localmente y luego, una vez concluida la construcción de la pieza, incorporar sus cambios al repositorio común.

Cada desarrollador debe trabajar en su propio espacio. Siguiendo esta premisa, ¿por qué la base de datos, siendo parte esencial del producto, no se incluye en él? ¿Por qué no es natural que cada desarrollador trabaje sobre su propio ambiente de base de datos?

Surge un problema. Si cada programador opera sobre su propio ambiente, ¿cómo obtienen los demás integrantes del equipo las modificaciones al esquema realizadas localmente? Del mismo modo que lo hace con el resto del código de la aplicación: mediante el repositorio de código fuente.

Por ello es indispensable que los scripts de base de datos estén incluidos en el controlador de código fuente, al igual que todo el resto del código. Es a través de estos scripts que se deben formalizar los cambios en la base que completan la programación de una pieza de software.

La base de datos, a diferencia de una pieza de código común, contiene estado (para eso está). Por eso, además del código para la creación de sus objetos, se deben tener en cuenta scripts de inserción de datos básicos para la aplicación (tablas paramétricas, tablas maestras) y, eventualmente, algún pequeño set de datos de prueba.

…continuará…

---

(*) Andrés dice: por fin, y luego de dos años de arrastrarme, alguien ha escuchado mis ruegos, dignándose a brindar… ¡una colaboración! Y en buena hora, que en este lugar ya se empezó a juntar el polvo. Esperemos que sea la primera de una larga serie y dé comienzo a una maratón de talentosos desarrolladores ansiosos por ayudarme a mantener vivo este humilde espacio (esperar es gratis, dicen).

Frases: Lo que sobra.

[…] como verás, arquitectura y diseño es lo que sobra... sobra porque todos somos arquitectos y diseñadores y hacemos lo que se nos da la gana, no hay directivas.

“Un amigo”, hablando sobre esas cosas lindas que tienen los sistemas.

Frases: Liderazgo.

“Leadership is the art of trading imaginary things in the future for real things today”.

Dilbert es genial.

Visibilidad.

Gran Proyecto (con mayúscula), muy “visible” para la gerencia de Megaempresa, vital para la subsistencia de NoTanGranPeroGranConsultoraOSoftwareFactory, y por tanto muy “visible” también para la gerencia de ésta última.

Desde nuestro punto de vista (de sistemas) no es más que otra aplicación de formularios que le pegan una y otra vez a una base de datos, más un sinfín de reportes que vienen a sacar lo que los formularios pusieron.

Otra gran, torpe, enmarañada, traicionera, e incansable generadora de un aburrido caudal de incidentes de fácil solución técnica, y que serían de fácil solución a secas si no fuera por el hecho de que más o menos la mitad de ellos contradice lo que indica la otra mitad.

Así que una horda de programadores armada con papel secante intenta contener ese río, resuelve uno y otro y alterna entre “A” y “no A” en un proceso que arroja tanta agua como recoge.

Hay otro caudal que lo alimenta, un caudal de programadores, analistas, managers y demás sacos de carne “recursos” que van pasando, pasando y pasando a ritmo creciente. Si no fuera por este otro caudal que aporta toda la energía desperdiciada en aquél ida y vuelta inútil el proceso descrito sería el santo grial del movimiento continuo.

Los gerentes, como esto es importante, están en contacto con “el equipo”, los conocen, interactúan con ellos más que con el resto. Es a esto a lo que se le llama “visibilidad” y que consiste en que, de vez en cuando, se abre un espacio en esos cielos y asciende alguno, (probablemente aquél con más habilidad para el alpinismo que para la programación) dejando al proyecto, que es realmente importante, en manos del resto que ahí queda, papel secante en mano (mientras el alpinista saluda desde lo alto).

Así es que, gracias a la “visibilidad” del proyecto los otros reman, reman y reman hasta que, hartos y sin esperanza, abandonan en busca de algún horizonte en donde sus entrenados brazos sean mejor recibidos. Aquellos en los que el entrenamiento no hace efecto y que por lo tanto carecen de otras expectativas (que los hay), esperan pacientemente su turno para el ascenso.

Unos y otros son reemplazados velozmente, así que eso que llamamos “equipo” (y que no es más que un fotograma de una película interminable) apenas puede acumular una muy vaga idea del negocio que el sistema viene a sostener, ya que el escaso conocimiento penosamente adquirido por prueba y error se va tan rápido como se acumula. Del negocio se sabe que es grande y millonario y que no es una verdulería ni un almacén de ramos generales, pero eso no alcanza para dividir las aguas y tomar la mitad de correcciones que corresponde para parar la rueda.

En fin… cualquiera que trabaje en sistemas un tiempo es expuesto a una de las más generosas fuentes de fina ironía que esta vida puede dar: el trabajo y, sobre todo, el trabajo en sistemas y, sobre todo, el trabajo “corporativo”. Si este tiempo es más o menos largo el sistémico, si sobrevive y lo sigue siendo (o mejor dicho, para sobrevivir y seguir siéndolo) habrá desarrollado un fino sentido de la ironía y del humor, o un cinismo a toda prueba, o todo eso junto. Por suerte algunos explotan genialmente esos efectos colaterales esas habilidades, y así tenemos a Dilbert (adivinen de dónde sacó Scott Adams la inspiración para sus personajes), o a Sinergia Sin Control, o al mayor repositorio de esfuerzo sin sentido y desperdicio de inteligencia jamás creado, TDWTF.

Porque lo más irónico de todo es que funciona y que buena parte de nosotros hemos vivido o viviremos de ello, y que es lo que termina financiando los juguetes (lenguajes, metodologías, herramientas, patrones, arquitectura) con los que nos entretenemos mientras, distraídamente, hacemos girar la rueda. En fin…

…que al mundo nada le importa
yira…
yira…

Frases: Participación y compromiso.

¿Cuál es la diferencia entre participación y compromiso? Digamos que si el objetivo es preparar huevos con jamón la gallina participa, pero el cerdo está comprometido.

(me la recordó un reciente twit de @Yoriento)

Desafíos.

Un desafío es el deseo de alcanzar un objetivo ubicado un poco más allá (no demasiado, porque si no ya sería un sueño) de nuestras capacidades actuales. Implica mejora, autosuperación.

Para mí, lo motivador de mi trabajo es lo desafiante que puede llegar a ser. Frecuentemente se nos plantean proyectos parecidos a aquellos que enfrentamos en el pasado pero con algún matiz, algún punto oscuro, alguna particularidad especial que nunca hemos implementado. Estas particularidades representan nuevos problemas y son las que hacen al proyecto desafiante en esa medida justa que nos permite enfrentarlo con cierta confianza sin llegar al extremo de la sensación del salto al vacío.

Cuando no es así simplemente me aburro, y no tolero bien el aburrimiento. A mediados del 2009 di el salto y cambié de trabajo. En su momento actué guiado más por esos sentimientos –de aburrimiento- racionalizados que por razones objetivas. De alguna manera ese creciente aburrimiento ante los problemas y situaciones han alimentado este blog -inmejorable vía de escape- en la primera parte de este año (y a cuya ausencia se debe, en cierta medida, la poca producción bloggera de la segunda).

Finalmente el tiempo puso las cosas en perspectiva y el nuevo entorno me da un punto de comparación. Me llama la atención lo nimio, lo poco importantes que eran los problemas y situaciones que ponía como excusa del cambio. Ahora es claro que esa necesidad de cambio no estaba dada por el entorno sino que provenía de mí mismo, que su origen no era la gravedad o repetición de algún problema o situación sino el nulo desafío que éstos representaban para mí. Pareciera que “nulo desafío” implica que todo era “fácil”. Nada más lejos de lo que quiero decir, aquí vamos.

El punto central de toda esta cantinela es que uno no sólo “es parte de” sino que también construye la situación que lo rodea. Decir “no habrán nuevos desafíos” es, en realidad, una vuelta retórica por la que esquivamos la responsabilidad en la construcción de esa situación al ubicar a los desafíos en el entorno cuando en realidad están en nosotros.

Los desafíos no están allí, uno no los encuentra sino que los crea. Es decir que constantemente enfrentamos los desafíos que nos hemos creado, como Don Quijote contra los molinos de viento.

Un entorno de trabajo desafiante no es, por si queda alguna duda, algo objetivo. Lo que para unos es tierra fértil es desierto para otros, no por la dificultad o no de los problemas objetivos a resolver –finalmente el único problema objetivo lo constituyen los requerimientos de un cliente-, sino por la predisposición o no de cada uno a crear desafíos en ese entorno en un momento determinado.

Pareciera ser, entonces, que a nivel institucional hay poco que se pueda hacer para crear un entorno desafiante, dado que esta característica reside en cada persona y no en ese espacio creado grupalmente.

En alguna medida es así. No se pueden “crear” desafíos institucionalmente. Pongamos un ejemplo: se plantea “ser referencia en el uso de la tecnología X” como un “desafío en el que todos tenemos que estar comprometidos”. Esto es en realidad apenas un objetivo y una expresión de deseo que puede ser origen de un desafío motivador para algunos pero indiferente o incluso fuente de sentimientos negativos –inseguridad, presión, rechazo- para otros.

Lo que sí se puede hacer institucionalmente es ubicar a cada integrante en un puesto en donde los problemas objetivos –los requerimientos de sus clientes externos o internos- estén alineados con su predisposición a crear desafíos en torno de esos problemas y proporcionar los recursos, la libertad de acción o la guía que necesite cada uno para superarse. Esto será mucho más productivo que el vano intento de imponer desafíos a diestra y siniestra como si todos fuéramos iguales y nos interesaran las mismas cosas.

Pero esto implica un conocimiento muy personal de cada integrante del equipo por parte de la institución… mejor dicho por parte de las personas que definen los puestos en las instituciones y que –erróneamente o no- generalmente están muy alejados del resto de la empresa, si no física por lo menos profesionalmente.

La solución común, dado que a nivel institucional no puede haber un conocimiento personal profundo de cada uno, es dividir la responsabilidad entre persona e institución: la responsabilidad institucional es de abrir las puertas, proporcionar los caminos para que cada uno busque o cree ese lugar desafiante, y está en cada uno la responsabilidad y el esfuerzo de motorizar esa búsqueda. Motorizar es buscar, proponer, convencer, buscar alternativas, concretar.

Es tan común en sistemas la queja constante sobre las posibilidades de desarrollo profesional (“de encontrar nuevos desafíos”) como la inacción de quien las enuncia en cuanto a la creación o búsqueda de ese espacio fértil en desafíos profesionales.

De ser sincero el deseo, de existir esa búsqueda y de ser infructuosa, debería continuar por fuera (pero ya basta de quejarse), la posibilidad de que no haya intersección entre lo que una persona encuentre como desafiante y las necesidades de una institución en particular existe, y no hay más que hacer que seguir buscando.

La queja.

Soy quejoso por naturaleza. Siempre le encuentro el pelo al huevo y, a falta de errores o problemas más graves, hago de un charquito una inundación…

A veces exagero un poco. Cuando mis compañeros de trabajo están –razonablemente- ya un poco hartos de mis cancioncitas plañideras les recuerdo, como para equilibrar un poco la balanza, que si bien me quejo

a) estoy en general encargándome activamente o lidiando con el problema, así que eso me da cierto derecho a una breve descarga emocional –a veces no es tan breve como debería-, y

b) estoy constantemente pensando y tratando de proponer soluciones –a veces peores que el problema, pero bueno… prueba y error, y sin error no hay prueba- y que

c) soy el primero en ponerle el hombro a cualquier intento de mejora, incluso cuando no crea que vaya a funcionar –probemos, con un poco de suerte me equivoque-.

Sí, a veces exagero y soy demasiado duro con algún temita en una solución que, en general, funciona bien. Pero bueno, es parte mi forma de motivar –correcta o no, efectiva o no, ésa es- y de motivarme a concentrarse no en lo que salió bien sino en lo que salió mal, que es lo que merece más atención.

Lo que es seguro es que es menos probable –a veces se requiere de más de un golpe- que me vuelva a dar con la misma piedra… aunque luego encuentre otra con la que impactar.

Por otro lado, hay personas en las que la queja es sólo eso, una queja. Una enumeración interminable de problemas, errores y malas decisiones que no las mueve a la acción o al cambio en lo más mínimo.

Estas personas piensan en el pelo antes de hacer el huevo. Como el “pelo a futuro” desmotiva, se quedan en la inacción y la queja se vuelve constante –porque sin acción nada cambia-, autosuficiente e inmortal.

Si es la queja la que lleva a la inacción o si es la excusa para la inacción, es imposible de saber. Pero es en todo caso indiferente, si el resultado es el mismo y es la nada.

Pero ojo, porque el quejoso no es mentiroso y no necesariamente tiene malas intenciones. Normalmente los problemas sobre los que la queja se asienta son reales, la práctica de la observación pasiva lo ha vuelto experto en su detección.

Así que –para mí- tampoco es prudente hacer oídos sordos a su cantinela. Lo que debemos evitar –a veces harto difícil- es quedar atrapados girando en la órbita de su parálisis.

Una solución imperfecta es siempre mejor que nada. Incluso una solución equivocada es mejor que nada, es una posibilidad menos en el camino de la prueba y error. Hacemos sistemas, no estructuras de concreto, y siempre podemos volver atrás y buscar otra salida. El tiempo insumido, al que usualmente calificamos de “perdido”, no será tal hasta que nos demos por vencidos.

Lecciones aprendidas.

En este caso no por mí sino por Sriram Krishnan en Microsoft. Las resumo aquí copiando y pegando los títulos (el resaltado es mío), algunos frases poderosas sin lugar a dudas, de esas que es bueno tener pegadas en las paredes de la oficina:

• Ask for forgiveness, not for permission
• (Most) Screw ups are OK
• Look for the line at your door
• Code is king
• Lone wolf syndrome
• Try out stuff
• New team? Pick people over products
• Get out of your comfort zone
• Ask the uncomfortable questions
• Go say ‘Hi!’
• Praise in public, pull down pants in private
• Best things are taken, not given
• Don’t be an asshole

El desarrollo en la entrada original, imperdible.

Monkey Business.

Son casi humanos... somos casi monos, mejor dicho.

Visto en La Pastilla Roja

Me deja pensando, al trasladar la situación a nuestra vida laboral, en que –si bien entre otros factores- las reglas de juego tienen un peso fundamental para determinar si será la colaboración, la competición o la indiferencia la característica predominante en un entorno de trabajo.

En todo caso estoy bastante seguro de que las reglas pesan más que las características personales. Somos ante todo animales sociales –al punto en el que sólo sobrevivimos en sociedad-, mucho más influenciables por los que nos rodean que –en conjunto- ellos por nosotros.

¿Se pueden alcanzar altos niveles de calidad –esa esmeralda perdida- en el desarrollo de software sin colaboración, sin verdadero trabajo de equipo? Yo creo que sí, pero es mucho, muchísimo más difícil que en un ambiente colaborativo.

Los costos de un ambiente de “indiferencia” en el que cada uno “sólo hace lo suyo” se ven reflejados en complejas estructuras de control superpuestas que coordinan el trabajo: líderes de esto y gerentes de lo otro, supervisores de lo de más allá y más acá, capas y capas de jefes de jefes cuyo trabajo es apenas un poco más que distribuir información y controlar el correcto ensamblaje de subproductos que se construyen en la base de la pirámide aisladamente, sin visión de conjunto.

Se podría decir que parte del trabajo de esa jerarquía es, justamente, proporcionar una visión de conjunto. El problema es que, para el momento en el que el flujo de trabajo llega a ese nivel de revisión es un poco demasiado tarde para cambiar nada.

Para el momento de revisar la calidad –siguiendo las metodologías tradicionales- ésta está prácticamente determinada –sí, claro que podemos corregir desvíos funcionales… ya sabemos lo que sucede con la calidad del código durante esas correcciones-. Si el producto no cumple con las expectativas –de calidad, no sólo las de cumplimiento de requisitos funcionales- la única solución real es el retrabajo.

La solución propuesta generalmente es dividir el desarrollo en pequeñas etapas y revisar la calidad en cada una de ellas –siempre al final- con la esperanza de que la “suma de las calidades” sea provechosa –siempre al final-, y si así y todo las etapas presuponen productos demasiado amplios, las subdividimos… y luego ponemos a un responsable de cada división y de cada etapa, y ya estamos donde empezamos: jefes de jefes de jefes y poco trabajo real.

En un ambiente de colaboración las cosas son diferentes. La revisión es constante porque nadie es indiferente a lo que lo rodea. Cada corrección es mínima pero se dan constantemente. Es mucho más probable que la calidad final sea –para bien o para mal- toda la que el equipo pudo dar en un momento determinado. En esta situación el retrabajo cobra otro sentido: no es la corrección de lo que –en teoría- podría haberse hecho bien desde un principio sino la materialización del aprendizaje acumulado en el camino.

Pero son las reglas las que determinan si esa colaboración es posible. Si la ruta, -correcta o no, eso se verá al final- está predeterminada a través de un diseño milimétrico, el combustible de horas/hombre está calculado como para llegar con el tanque vacío y encima el vehículo no tiene ventanillas de poco sirve ponerse a pensar si hay o no un árbol en el camino, más vale rezar y esperar que cuando nos bajemos estemos en donde queríamos estar. ¿Parece difícil, no?

Reuniones técnicas…

…en las cuales el arquitecto explica a la audiencia la estructura del sistema en el que luego deben meter los dedos:

(gracias a Nicolás por apuntarlo)

La influencia de la orientación al producto o al cliente en el desarrollo de software - II: La elección de la tecnología.

Esto viene a seguir la serie inciada en el post anterior: I: Los muertos se dejan atrás, que es recomendable leer primero.

---

La elección de la tecnología.

Durante la vida del desarrollo de un producto de software es inusual, aunque cíclico y fundamental, el momento en donde surge la necesidad de determinar la tecnología a utilizar.

Es el tipo de decisiones que hay que tomar en el momento de la reingeniería. Momento que se suele demorar hasta lo inevitable, por lo que los intervalos entre éstas se miden en años, si no en lustros o décadas.

Las razones son variadas y pueden ser tan técnicas como la degradación del código y la obsolescencia del hardware o software de base, o funcionales, como exigencias del mercado demasiado difíciles de implementar en la tecnología actual o la aparición del fantasma de imagen a “viejo y obsoleto”.

Para una empresa orientada al producto una reingeniería es una gran revolución, y suele venir acompañada de grandes cambios y resistencias en el equipo de desarrollo. Integrantes aferrados a la tecnología y metodología en retirada verán sus posiciones de poder o confort atacadas por aquellos familiarizados con las nuevas. La decisión, entonces, afectará inevitablemente a las relaciones de poder establecidas durante años y a las que se generen durante los próximos.

No es, en resumen, el momento de hacer experimentos. El proceso debería comenzar con la investigación de las tecnologías establecidas (nadie recomienda jugarse por aquellas más novedosas) y seguir con pruebas de factibilidad, y prototipos, y más pruebas y…

En una consultora, por otro lado, se inician pequeños o medianos proyectos todo el tiempo, y cada uno es propicio para la experimentación con nuevas metodologías, frameworks, herramientas, patrones… Un error implicará un proyecto tormentoso o (muy inusualmente) fracasado, a lo sumo un par de víctimas fatales, pero nada demasiado terrible.

Lo que degenera en… un paisano ´e cada pueblo. Y sí. Tengo que reconocer que la sensación de tener asignada una “pequeña” tarea sobre un proyecto X, bajarlo del control de código fuente y abrirlo es como la que producen esas escenas en las películas de terror en las que la mano se acerca al picaporte de la puerta… y se acerca… y se acerca… y lo gira… y la puerta se abre y… y entonces uno respira aliviado o grita (“my eyes!”). Hay de todo. Lindo, feo, malo y bueno, y muchas veces hay de todo en el mismo proyecto, en diferentes secciones o funcionalidades.

Pero también es cierto que profesionalmente uno se mantiene al día. Y las herramientas decantan. A la hora de los grandes proyectos (con suerte) las decisiones son más medidas y basadas en experiencia acumulada en proyectos reales (aunque más pequeños) y no sólo en meras pruebas o prototipos.

Al trabajar durante largo tiempo sobre el mismo producto y con la misma tecnología, los desarrolladores tienen la oportunidad de hacerse expertos en ella, con todas las ventajas (mejores resultados, menores tiempos de desarrollo, proyectos “tranquilos”, estimaciones precisas) y desventajas (obsolescencia, encasillamiento, monotonía, pocos desafíos) que esto puede conllevar (que no necesariamente se darán unas u otras).

En contrapunto, una consultora es caldo de cultivo de experimentadores casi compulsivos (el que mucho abarca poco aprieta, dicen), y proyectos cual criatura de Frankenstein, rejuntes de diferentes frameworks y tecnologías cosidos y emparchados de manera grosera…

…o cosidos prolijamente, pero en todo caso grandes contenedores de soluciones redundantes. Es por haber trabajado largo tiempo con un conjunto reducido de frameworks, patrones y tecnologías que conozco a fondo sus posibilidades y desconfío de las herramientas complementarias y complejas que vienen a solucionar problemas extremadamente simples.

Si el peligro al desarrollar un producto es la obsolescencia o el fracaso en la implementación de una reingeniería (y una dolorosa “vuelta atrás”, o un ciclo corto hasta la próxima), el peligro de la experimentación excesiva al trabajar en proyectos relativamente cortos es el desperdicio de experiencia (descubrir siempre nuevos problemas en vez de solucionar los conocidos) y una dispersión de tecnologías que desemboca en un stock de proyectos que nadie puede entender completamente (a menos que sea un experto en Silverlight, .Net, Servicios, jQuery, NHibernet, Active Record, MVC y la mar en coche) y que por tanto sólo pueden ser parchados una y otra vez.

Como siempre, la solución es huir del riesgo, de los extremos. El faro es la simplicidad, y nos alejamos de ella tanto cuando forzamos a una tecnología (tal vez ya obsoleta) a hacer cosas que no existían cuando fue pensada o cuando nos pasamos de rosca innovando y metemos en la misma bolsa (a nivel proyecto u organización) más herramientas de las que podemos nombrar en cinco minutos.

La influencia de la orientación al producto o al cliente en el desarrollo de software - I: Los muertos se dejan atrás.

Arbitrariamente (como toda clasificación) y a muy grandes rasgos, podemos dividir el mar de equipos de desarrollo de software en dos corrientes principales: enfocados al producto y enfocados al cliente.

Los equipos enfocados al producto son responsables del desarrollo de uno o varios sistemas, siempre orientados a un mercado específico (si bien puede ser definido en forma más o menos amplia): sistemas contables, para la gestión de hospitales, comercios minoristas, logística o para el control de determinados dispositivos. El producto (o la familia de productos, entiéndase de aquí en más) requiere mantenimiento y constantemente se prueban e implementan nuevas funcionalidades y cambios para justificar los lanzamientos y generar ventas.

Del otro lado tenemos desarrollos enfocados hacia el cliente: profesionales independientes y equipos de desarrollo en consultoras y software factories de todo tipo y color que luchan por armar, mantener y ampliar una cartera de clientes a los que usualmente intentan vender de todo, si es software mejor. Algunas están también especializadas en un mercado en particular, pero vale la clasificación en tanto no vendan el mismo producto a varios clientes.

Y después hay grises, pero creo que la clasificación abarca a una amplia mayoría.

Hasta ahora he sido desarrollador de productos (aunque más de uno fue acaparado por algún cliente importante). Tenía formada una imagen bastante pobre acerca de la calidad de los productos y del trabajo en consultoras (sobre todo en las grandes, pero es una experiencia que por ahora no tengo), y crucé la línea cargado con no pocos prejuicios y temores. Pero bueno, hay que alejarse de las zonas de confort, dicen.

Han pasado ya casi cuatro meses desde el salto, puedo decir que por lo menos una de las consultoras (por suerte) no es como me la esperaba. Realmente las cosas no son ni mejores ni peores, simplemente distintas, y a esto iba, a hacer un contrapunto.

Los muertos se dejan atrás (aunque hay zombies indestructible).

La huella de toda consultora es un reguero de cadáveres más o menos malolientes: proyectos cuya calidad interna deja mucho que desear, si bien hacia afuera suelen verse bastante bien (que al cliente hay que cuidarlo). El aprendizaje se da de proyecto en proyecto y los primeros en implementar determinadas herramientas o tecnologías son víctimas fatales de la inexperiencia.

En cambio, cuando trabajamos en versiones incrementales del mismo producto, siempre sobre la base de código de la versión anterior, poco a poco la experiencia se materializa en todo el proyecto a través de revisiones y refactorizaciones. El equipo (si no es testarudo) no tarda en darse cuenta de que si se mueven las lápidas y se dejan las tumbas los muertos se convierten en fantasmas que nos acecharán eternamente. La única forma de sacárselos de encima es buscar el cadáver y darle cristiana sepultura.

A cierta distancia de la línea de entrega de un proyecto que se presentará, aprobará (y si te he visto no me acuerdo), es inútil refactorizar y solucionar definitivamente determinadas cuestiones. Llega un momento en el que el sistema “es así” y punto, y aunque (por lo menos para mí) es difícil de aceptar, hay que dar media vuelta y seguir adelante.

Cuando se trabaja sobre un producto toda refactorización es provechosa y bienvenida. Incluso en las reingenierías el código “del sistema viejo” es referencia para determinar detalles de implementación, por lo que cuanto más legible mejor. Así que es sencillo cuándo determinar cuándo es conveniente hacer una refactorización o resolver un problema de fondo: siempre.

En una consultora determinar a ojo cuándo se ha llegado ese punto de no retorno es muy difícil, y los errores en este sentido son frecuentes. Muchas veces las inevitables horas fuera de presupuesto que insumen las correcciones entre presentación y aprobación superan aquellas que hubiesen sido necesarias para la refactorización, y otras veces se van horas de refactorización en funcionalidades con pocos errores y cuya prolija implementación nunca será vuelta a ver.

En todo caso, y en esto he confirmado mis prejuicios, aunque la consultora en sí no pueda desprenderse de algunos muertos devenidos en zombies, la realidad es que desde el punto de vista de un desarrollador en particular es poco probable que una vez abandonado el proyecto se lo vea volver en la misma dirección.

Suficiente, creo, para una primera entrega. Seguimos en la próxima.

Huerfanitos.

Permítaseme un poco de humor gris tirando a negro.

En todo emprendimiento que venga pariendo software desde algún tiempo podremos encontrar desarrollos en diferentes estadíos de su camino hacia la obsolesencia: los hay desde embrionarios hasta mantenidos con vida artificialmente, pasando por recién nacidos encantadores que prácticamente no hacen nada por sí mismos, infantes con terribles rabietas que reclaman noches en vela, adolescentes indomables pero llenos de energía y posibilidades, adultos productivos e independientes y ancianos, venerables fuentes de sabiduría o mañosos insoportables cuyos achaques reclaman constante atención.

Y los hay huerfanitos, de todas las edades. Ya sea debido a que sus progrenitores hayan pasado a mejor vida o huido en estampida cual vil Frankenstein o desentendido de su cuidado o sido asesinados (o ajusticiados merecidamente), son usualmente víctimas de la indiferencia de los miembros del equipo de desarrollo.

Proliferan –me imagino, no me van a pedir rigor científico justo ahora-, más en consultoras que en empresas dedicadas a un producto o que en software factories. Supongo que porque las segundas cuidan mucho a su único hijo (o a lo sumo a sus pocos hijos) y las últimas son padres espartanos e inmisericordes que no tienen reparos en arrojar al abismo a sus vástagos más débiles, en el mejor de los casos, o madres de alquiler que paren a pedido y si te he visto no me acuerdo.

Pero si definimos como consultora a un emprendimiento que no sólo desarrolla un producto sino que también se hace cargo de su mantenimiento correctivo y mejoras funcionales (que cobra religiosamente), nos encontramos con que en este tipo de organizaciones no es tan sencillo dejar atrás las consecuencias de viejos errores… institucionalmente hablando, claro, porque sus integrantes intentarán hacerlo a toda costa (o serán eventualmente obligados a ello), y de ahí la proliferación de estos huerfanitos.

No es mi intención ser cruel inútilmente, hablo desde la experiencia: son peligrosos, créanme. Carentes y muchas veces necesitados de atención, se nos pueden pegar como garrapatas. Es así como, a través de una inocente tarea de instalación, un pequeño fix o una mejora estética nos encontramos siendo referentes, tutores, encargados, o directamente padres sustitutos de alguna de estas criaturitas de las que conocemos poco y nada.

El entorno no propicia el despegue. Si les toca transitar esta situación verán con horror como, aliviados al ver que a otro se le ha adjudicado el trasto, sus otrora solidarios compañeros de equipos evitan el tema (“y sí, alguien tenía que hacerse cargo”) o intentan naturalizarlo (“che, vos estabas con aquello de… ¿no?”), si no es que literalmente huyen despavoridos. Y no tardarán en aparecer problemas de los cuales, obviamente, nadie sabe nada y nadie nada quiere saber, salvo que tenemos que hacernos cargo.

¿Solución? Es aquí donde con un poco de demagogia podría decir que la única definitiva es adoptarlo, encauzarlo, educarlo, corregirlo, domarlo si es necesario para resolver el problema de una buena vez por todas… pero también es una posibilidad buscar a algún desprevenido, dejarle la canastita cerca, tocarle el hombro, voltear y caminar rápidamente sin mirar atrás, silbando bajito con aires distraídos.

Cuando los resultados no reflejan la experiencia o el aprendizaje.

Hay veces que llama poderosamente la atención la brecha (otras veces el abismo) entre la calidad de un equipo y la del proyecto sobre el que trabaja. A veces para bien, a veces para mal.

En algunos se percibe una capacidad para la mejora que excede en mucho la capacidad técnica (inicial) de sus integrantes. La falta de experiencia hace que se reinventen muchas ruedas y se cometan muchos errores de esos que (tal vez pecando de un poco de soberbia) los desarrolladores de más experiencia catalogan de “típicos”, pero que son ampliamente compensados por la motivación a corregirlos, incluso en varias aproximaciones, intentando una y otra vez. Éste es el caso ideal en el que, en todo momento, la calidad del proyecto refleja todo el aprendizaje y la experticia del equipo.

Pero en otros se ve que el resultado, si bien funcional, no tiene la calidad que podría esperarse de acuerdo la experiencia de los participantes, o que surgen (en el peor de los momentos) problemas que derivan de errores que podrían haber sido detectados (e incluso corregidos) con relativa facilidad por los miembros de más experiencia, problemas que luego de un tiempo de incubación terminan impactando transversalmente en todo el proyecto volviéndose de difícil o imposible solución.

Mucho tiene que ver en la calidad de un proyecto la habilidad para resolver problemas de sus integrantes. Mucho más tendrá que ver la experiencia y muchísimo más la motivación.

Es la experiencia la que permite ganar tiempo aplicando soluciones ya probadas y enfocarse en aplicar la habilidad en resolver aquellos problemas que hacen único a cada producto de software. Pero es la motivación lo que lleva a utilizar la (mucha o poca) habilidad disponible y aprender (con mayor o menor velocidad) de los errores y aciertos (propios y ajenos), que es lo mismo que decir “adquirir experiencia”.

Pero una cosa es la motivación a aprender y otra la de aplicar el resultado de ese aprendizaje al proyecto en particular sobre el que se está trabajando y aprendiendo, y de ahí la brecha entre capacidades y realidades que mencionaba al principio. La mayoría aprende de los errores y ve posibilidades de mejora, pero son menos (muchos menos) los que desandan el camino para corregirlos o implementar esas mejoras en el código ya escrito. ¿Por qué?

Se me ocurren un par de factores que hacen de esa decisión (la de seguir sin mirar atrás) la más razonable:

• Si el alcance del proyecto es acotado y está próximo a entrar en una etapa de mantenimiento (¡exclusivamente!) correctivo, de poco o nada servirá mejorar lo que de todas maneras funciona (suponiendo que funciona razonablemente, ya que de no ser así no hay alternativa posible).

• Si el problema es transversal y está demasiado extendido, puede ser mejor será tratar de no cometerlo de aquí en más y corregirlo sólo en donde las modificaciones sean imprescindibles.

• En cualquier caso en el que el impacto sea menor que el esfuerzo que requiera la corrección. El problema aquí es la medición de ese impacto, para la que deberíamos considerar no sólo la situación actual sino también a futuro. Si estamos desarrollando un producto que se pretende mejorar y ampliar indefinidamente (en vez de “cerrar y entregar”) la acumulación de pequeños problemas terminarán afectando la calidad haciendo cada vez más difícil implementar nuevas funcionalidades y forzando una (mucho más riesgosa y costosa) reingeniería.

En definitiva, es cuestión de decidir en forma consciente y explícita si vale la pena el esfuerzo dada cada situación en particular. Pero hay otros factores, menos técnicos y más humanos o de organización, que bloquean las alternativas:

• Simple resistencia al cambio, el aferrarse a un estado en el que los problemas (graves o no) son conocidos.

• Una patológica actitud defensiva puede hacer que cualquier sugerencia se vea como una crítica.

• Soberbia, que impide ver los problemas y desventajas que inevitablemente están presentes en cualquier solución.

• Desinterés o el clásico “sólo hago lo que me ordenan”.

• Escaso trabajo en equipo o excesivamente compartimentado, que hace que se pasen por alto los problemas y posibles mejoras transversales.

Son estos factores son los que hay que detectar y combatir porque son los que llevan a decisiones irracionales o por defecto (aquellas que surgen de la no-decisión). El ideal es que el equipo tenga el control del proyecto, lo que implica ser consciente de los aciertos, de las cuestiones “mejorables”, de los errores que hay que corregir y de los que hay que soportar.

Trabajo remoto.

Las herramientas de comunicación han avanzado muchísimo, qué duda cabe. Es posible sentarse en el escritorio de la oficina desde casa de una forma razonablemente transparente utilizando una VPN, conversar con los demás miembros del equipo por chat, por voz o video a través de servicios que prácticamente todo el mundo utiliza de forma muy natural y cotidiana. Si pensamos en cómo este conjunto de tecnologías –de comunicación- ha impactado en la economía y las relaciones laborales veremos gran dificultad en imaginar en qué las transformará de aquí a 20 o 30 años.

En el rubro del desarrollo de software -integrado necesariamente por personas y empresas acostumbradas y abiertas a la tecnología- todos, en mayor o menor medida, utilizamos algunas herramientas de trabajo remoto. Aquellos con más experiencia recordarán con extrañeza los no tan lejanos tiempos en los que instalar, configurar, verificar un problema o arreglar una emergencia, eran todas tareas que implicaban moverse e ir a visitar al cliente.

De un tiempo a esta parte -apenas un par de años-, la “presencia virtual” se está extendiendo hacia dentro del equipo de desarrollo, al que siempre imaginamos como un montón de personas trabajando juntas en el mismo lugar. Si bien la imagen anterior sigue representando la norma, opciones de trabajo remoto comienzan a analizarse seriamente como una posibilidad por cada vez más organizaciones, y comienzan a configurarse otro tipo de equipos, a los que usualmente se nombra como equipos distribuidos.

Por otro lado, desde lo ágil siempre se ha dicho –y yo comparto- que la coordinación y comunicación es a la vez demasiado importante y demasiado compleja en el desarrollo de un producto de software, por lo que deberíamos optar, siempre que sea posible, por la forma más eficaz de coordinar y comunicar: cara a cara.

Debemos ser conscientes de que al utilizar estas nuevas tecnologías estamos, en mayor o menor medida, sub-optimizando la comunicación. Es una opción racional si -y sólo si- los beneficios superan el costo de esa sub-optimización. Es decir que si para una consultora argentina tener un cliente español no representa ninguna dificultad operativa seria, no por ello tiene sentido hacer una videoconferencia con otro cliente cuyas oficinas están a escasos 200 metros. Una software factory que alquile oficinas con espacio e infraestructura suficiente para todos sus empleados no se beneficiará de las posibilidades del trabajo remoto en tanto no reduzca el costo del alquiler o capitalice una mayor velocidad de respuesta como nuevos clientes o precios más altos en cada contrato, o en un aumento medible de la productividad.

Yendo un poco a lo personal, para los miembros de un equipo tener la posibilidad de trabajar remotamente implica libertad de horarios y –sobre todo- el aprovechamiento de esos momentos de inspiración o entusiasmo, esquivando la saturación. Si a uno se le ocurre una gran idea un domingo a la mañana y tiene ganas y tiempo de probarla lo antes posible, ¿por qué no? Si se nos hace cuesta arriba un lunes a la mañana o un viernes a la tarde y las fechas límite lo permiten, ¿no sería más productivo entrar tarde o irse temprano, descansar, distraerse, en vez de luchar por terminar algo que en otro momento de mayor motivación nos llevaría la mitad de tiempo?

Suena bien, pero tiene un límite. Recordemos los costos de los que hablábamos al principio: de poco servirá todo ese trabajo adelantado si la funcionalidad había cambiado (la cambió el analista trabajando tarde a la noche desde su casa) y el desarrollador no se enteró por no chequear el correo.

Sobrepasamos un límite cuando, más seguido que esporádicamente, unos quedan a la espera de poder comunicarse con otros y los horarios no coinciden y comienzan a aumentar los tiempos muertos. Desde lo personal, ese costo de la libertad puede pagarse en forma de constantes llamadas y comunicaciones disruptivas por temas laborales que impiden una desconexión completa.

Para complicar las cosas las personas son extremadamente diferentes en este sentido. Algunas preferirían trabajar todo el tiempo en forma remota y sin horarios y otros ir a la oficina con un horario fijo, salir y no ser molestados para nada hasta el día siguiente. ¿Entonces? Dependerá de cada equipo encontrar el punto justo en el que todos se sientan cómodos, lejos de los extremos del control estricto o de la amalgama entre vida personal y laboral.

Personalmente creo que las herramientas de trabajo virtual deberían estar disponibles para todos, sobre todo teniendo en cuenta que en general las empresas ya cuentan con el software necesario (o hay opciones gratuitas o de muy bajo costo) y que no deberían demandar mucha infraestructura adicional a la que una empresa suele tener sólo por estar en el rubro de sistemas. Pero que al mismo tiempo deben establecerse ciertas reglas. Un horario en el que todos deberían estar en el mismo lugar, ciertas reuniones a las que sea obligatorio asistir en persona, cierta flexibilidad diaria (2 o 3 horas en una jornada de 8), una cuota de horas a cumplir por mes, ese tipo de cosas.

Debemos, en definitiva, tratar estas herramientas como a todas las demás: por más casos de éxito que escuchemos, por más buzz que se haya generado alrededor de ella, tiene que ser adecuada para nosotros.

Curados de espanto.

No son todos malos hábitos los que adquirimos los programadores en el transcurso de nuestra vida profesional. Para nivelar un poco quiero traer a cuento varias características que casi todos compartimos, y que de seguro estarán presentes en un buen programador… tienen que estar presentes en un buen programador, ya que todas giran alrededor de un tema que es central en el desarrollo de software: los errores.

Todo software no trivial tiene errores (y como siempre digo, la mayoría de los triviales también). Y si por buena ventura un software en particular no los tiene seguro que los requerimientos que le dieron origen sí. Y si por alguna de esas casualidades cósmicas los requerimientos (y por tanto el software) son consistentes en los papeles, seguro que el usuario o el analista o el redactor o el programador se ha equivocado en su interpretación u omitido alguno de ellos con tal mala suerte que el resultado es consistente aunque, por supuesto, erróneo… y en el imposible caso de que todo esté bien… serán las necesidades del cliente las que cambien o las que cambiarán en breve.

Y hay que tener en cuenta que los innumerables errores detectados (ya sea durante el desarrollo o como defectos en el producto) son apenas una pequeña fracción de los que cometemos todos los días… y sin embargo aquí estamos.

Aunque a veces sucede, no es usual que ante un problema un programador se rasgue las vestiduras, se deprima, paralice o caiga presa de delirios apocalípticos. Esto es, básicamente, porque nuestra vida laboral es una eterna sucesión de problemas y soluciones… que generan más problemas.

¿Qué es lo que –al menos creo yo que- he aprendido?

El camino para estar a salvo de los problemas no es evitar que se produzcan (son inevitables) sino tener alternativas.  Para eso existen los resguardos, los procedimientos alternativos, las salidas de emergencia. Prevenir no es sólo prevenir el problema, sino también sus consecuencias.

Los manotazos de ahogado no sirven. La suerte existe, pero es escasa y no se puede confiar en ella. Hay que medir el costo de un intento a ciegas. ¿Podemos hacer una prueba rápida, a ver si funciona? ¿No romperemos algo más en el intento? Bueno, hagámosla. Pero no podemos perder tiempo tirando tiros al aire, la magia no existe y hay que pensar, buscar, investigar, rastrear, no queda otra.

Identificar precisamente el problema es siempre el primer esfuerzo. Tratar de arreglar “algo” que no se sabe qué es es sencillamente imposible. Trabajar sobre las consecuencias es una opción para ganar tiempo, pero nunca una solución a mediano o largo plazo.

No se puede resolver un problema de fondo sobre la emergencia. Cuando se presenta una emergencia hay que resolverla (en lo posible rápidamente) para aliviar la presión y poder pensar y resolver el problema de fondo con tranquilidad… Creo que en esto todos fallamos más de una vez, tal vez no tanto en la resolución rápida, sino en la disolución de la causa subyacente. ¿Cuántas veces dejamos parches provisorios como soluciones “definitivas” que no tardan en crear más y más graves apuros?

Presionando no se resuelve nada, por lo menos en sistemas. No es de mucha ayuda gritarle lo obvio al administrador de la red –que todas las terminales están fuera de servicio o que el mundo va a explotar-. Si encuentra la solución en un tiempo razonable será a pesar de ello y no gracias a ello. Ya habrá tiempo de repartir responsabilidades y amenazas luego, hay que concentrarse en buscar una solución.

Hay que dejar trabajar. Si nos es posible paliar las consecuencias o aliviar la presión, ésa es la forma de ayudar. Y si no está entre nuestras posibilidades hacerlo… mucho ayuda el que no estorba, dice el refrán.

Aprender por prueba y error implica resolver, aunque sea parcialmente, problemas de fondo. De cada problema, de cada situación, tenemos que quedarnos con alguna mejora. Puede ser pequeña, tal vez no una solución completa, tal vez apenas una alerta temprana para la próxima vez, algo, lo que sea. Si vivimos en un interminable devenir de emergencias, la única forma de salir de ello es de a poco, aprovechando el poco tiempo que nos queda para ganar más tiempo.