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).

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?

Complejo.

Hace semanas que vengo demorando una entrada sobre la complejidad. Es que hay tanto que decir sobre la complejidad que la cosa se vuelve un poco compleja… y soy poco dado a las cosas complejas.

Así que procrastinando otra vez el bendito post –que a estas alturas ya sé que nunca voy a escribir-, picando de aquí y allá en el reader, me encuentro con un -ya viejo- artículo de Joel: The Duct Tape Programmer.

Sencillamente imperdible, un compendio de frases impactantes delicadamente hilvanadas:

Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments […] and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes […]

Ya ven para donde apunta:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project.

Y básicamente eso es todo lo que hay que decir al respecto de la complejidad. Me hizo acordar a esta otra gran frase, que no recuerdo muy bien de dónde saqué:

“Los buenos programadores resuelven los problemas complejos, los grandes programadores los evitan”.

Resolver un problema es ganar una batalla. Eliminar la necesidad de resolverlo es evitar la guerra. Es como la depuración: no se trata de meter más código sino de quitar el que sobra, no se trata de conocer más patrones, frameworks, herramientas, plugins y la mar en coche, se trata de encontrar la combinación más simple que nos permita implementar la funcionalidad necesaria, y de simplificarla todavía más.

Para evitar un problema es imprescindible crear el ambiente propicio para esas preguntas que ponen incómodos a todos: “¿realmente hace falta hacer esto? ¿por qué? ¿para qué? ¿hay otras posibilidades? ¿qué pasa si no hacemos nada?” Son esas preguntas las que llevan al pensamiento lateral, y es por eso que la aparición de respuestas tautológicas nos alertan tempranamente de que estamos perdiendo el rumbo: “Porque sí”, “Porque el cliente lo pidió así” (es casi decir lo mismo), “No sé, pero hay que hacerlo”, “Esto ya está pensado”…

Lo complejo se torna complicado muy rápidamente, casualmente en el preciso momento en el que los ingeniosos desaparecen.

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.

Evitando la claustrofobia.

En LLeva a tus monitos de paseo divagaba sobre la importancia de “sacar” a los programadores al mundo real en cada oportunidad que se presente, llevarlos (no a todos juntos como a un grupo de jardín de infantes al zoológico, se entiende) a las oficinas de los clientes, a las reuniones, a los relevamientos, a las charlas de capacitación, etcétera.

En aquel post justificaba la actividad mencionando los beneficios de conocer las particularidades del negocio para el cual programan y diseñan, su entorno, los clientes, los usuarios: una transmisión más precisa de ese otro paradigma a los sistemas en los que se materializa, más sentido común en la interfaz del usuario, la posibilidad de encontrar nuevas ideas o herramientas… Beneficios, en definitiva, para el producto, para la empresa proveedora de software y para el cliente.

Ayer @rgil, que viene del lado de la consultoría, publicó El "arturo" y los estereotipos, cuya (breve) lectura recomiendo y de donde cito:

Hace unos días vino un consultor de una de estas grandes a una entrevista de trabajo. Le entrevistaban dos personas que, casualmente, habían trabajado en empresas de ese tipo [una de las Big Four]. Precisamente por eso, no podían dejar de reírse al comentar la entrevista y los términos que utilizaba "el arturo": "quiero pasar a cliente final", "¿cual es la denominación exacta del puesto?", "¿a quién debo "reportar"?", "¿cuales son las funciones y necesidades del puesto?", "¿cual será la estructura de mi equipo?"...

El consultor empleado de la gran empresa multinacional, tan empapado de esa cultura que ya no la reconoce como propia de un entorno particular, que la ha internalizado tan profundamente que choca al salir de ese entorno (aunque sea de esta forma que describe el artículo, más bien simpática, resultando ligeramente extravagante) es comparable al programador rodeado de programadores, algoritmos, patrones de diseño, clases, herramientas, e incapaz de sustraerse de ello.

Si cuando vemos una factura sólo vemos una relación cabecera-detalle, si cuando vemos una hoja de ruta sólo pensamos P=NP… tenemos un problema. El aislamiento profesional nos convierte en el estereotipo de nuestra profesión, de una manera que puede resultar desde simpática a patológica.

Salir, conocer otros ambientes, otros profesionales, otras personas, nos entrena no sólo para construir mejores sistemas (si sólo pensamos en función de eso, es el mismo problema), sino también para ser un poco más normales.

En LLeva a tus monitos de paseo los beneficios y la responsabilidad de establecer esa buena práctica estaban del lado de la empresa u organización. Aquí, ya que hablamos de beneficios (casi diría de necesidades) personales, tenemos que ubicar la responsabilidad de nuestro lado. En principio, responsabilidad de detectar el problema, de darnos cuenta de que estamos trabajando aislados profesional o personalmente para luego hacer algo al respecto.

Un equipo debe tener una fuerte cohesión, eso es indiscutible. Pero que la unanimidad sea la norma para todas las decisiones, que todos a nuestro alrededor adopten naturalmente el mismo punto de vista sobre temas controversiales o tiendan hacia las mismas soluciones o tengan los mismos gustos, pasatiempos y distracciones (¿son realmente distracciones?) debería, cruzada cierta frontera (difícil de establecer, pero desde el afuera se reconoce claramente), encender una alarma. Sentirse cómodo en el ambiente laboral es indispensable, pero demasiado cómodo ya es un poco preocupante… e incómodo fuera de éste es clara señal del problema.

La solución es tan simple y difícil como salir de vez en cuando. Si puede proponerse dentro de lo laboral, tomando responsabilidades o tareas que impliquen interacción con el afuera, mejor. Pero si esto no es posible habrá que buscar esas actividades y encontrar el tiempo para llevarlas a cabo. Es para nuestro propio beneficio, por lo que no debemos esperar a que un jefe o una oportunidad laboral nos lo sirva en bandeja.

Por suerte internet nos deja sin excusas para no conocer, aunque sea virtualmente, el exterior. Con tanto blog personal y profesional y conversación y web 2.0 las herramientas para la comunicación están ahí, al alcance de la mano. Es sólo cuestión de utilizarlas.

Más allá de eso, cursos, seminarios, ponencias, congresos… son buenas oportunidades para relacionarse con otros profesionales de nuestra área (pero de distintos entornos laborales). También podríamos participar de eventos no están relacionados con la informática o el desarrollo sino con el negocio para el cual servimos en un momento determinado.

Y creo que, si bien no es indispensable, es bueno tener alguna verdadera distracción, un verdadero hobby no tan relacionado a la vida profesional. Una actividad en la que refugiarse en momentos de saturación y que nos desconecte de vez en cuando.

La carrera.

Otro gran aporte de @Cerebrado, que esta vez ubicó en Izismile una serie de ilustraciones que recorren una conocida historia desmotivacional: The Management Rowing Race.

Lleva a tus monitos de paseo.

La semana pasada escribía sobre el paradigma que rodea cualquier actividad, sobre lo importante que resulta el conocimiento y la comprensión de éste para desarrollar con éxito un software alineado con el negocio, y lo difícil de su transmisión al equipo de desarrollo.

Rara vez es explicitado en manera alguna –decía- y cuando lo es –cuando pretende serlo- se materializa en forma de frases de compromiso que rara vez tienen que ver con la cosa real que dicen reflejar. Es un poco como la visión a la que tanta importancia le dan las normas de calidad: pocos saben qué es y de poco sirve saberlo -salvo para certificarse en algo- pero no se puede tener éxito sin ella. Análogamente, los negocios exitosos no son los que saben qué es un paradigma sino los que tienen un paradigma exitoso. Siempre es bueno racionalizar, poder poner en palabras, explicitar, pero lo indispensable es tener qué explicitar.

El problema es, volviendo al primer párrafo, que el equipo de desarrollo necesita conocer el paradigma real que subyace al modelo de negocio para derivar de él lineamientos concretos con los que diseñar un software. Imaginemos por un segundo que creamos un sistema de gestión para una empresa de la industria farmacéutica partiendo de que, tal cual rezan sus documentos sobre políticas internas, “la base de nuestro negocio es proveer los medicamentos para curar todos los males de la humanidad”… Imaginemos ahora la cara de los directivos cuando mostremos nuestros reportes y panel de control de gestión conformados por indicadores tales como tasa de mortandad, calidad de vida, reducción de casos de tal y tal enfermedad… cuando midamos el éxito de un producto de acuerdo a la cantidad de pacientes que se han curado gracias a él… “¡Hey! ¿Dónde está el estado financiero? ¿Y la cotización en bolsa? ¿Dónde se muestra el ROI?”.

Entonces, para conocerlo y comprenderlo cabalmente se requiere estar ahí. Es tarea propia de analistas funcionales, representantes comerciales y demás. Pero, normalmente, los programadores no pueden estar ahí y la solución propuesta por metodologías ágiles como XP –tener al usuario dentro del equipo- no siempre rara vez es posible. Surge entonces, como siempre en el desarrollo de software, el problema de la comunicación.

Pero… ¿No pueden estar ahí? ¿Nunca? ¿Ninguno? ¿Ni de visita? ¿Ni por un rato? Difícil de creer. A pocos se les da la oportunidad de conocer a los usuarios en su entorno real de trabajo. Incluso cuando esto es posible, incluso cuando es sencillo encontrar la oportunidad. Más raro aún es que esta actividad sea establecida formalmente entre las tareas de un programador durante el proceso de desarrollo.

Para los que han tenido esta experiencia -como parte de una visita formal o no- ha sido casi reveladora. Día a día, inevitablemente y de forma intuitiva, encerrados tras una muralla de código, los programadores derivan, imaginan, se forman una imagen del negocio para el cual programan. Lo hacen a partir de los requerimientos, del diseño propuesto para las pantallas, de las funcionalidades. Pero es muy difícil que esta imagen, condicionada por su experiencia y sus propios paradigmas, coincida con la realidad.

Creo que es una práctica fácil, barata y muy productiva el llevar a los programadores “de paseo” al entorno del cliente en cualquier oportunidad que se presente (oportunidad para tomarles fotos vestidos decentemente… ¡o hasta de saco y corbata!). ¿Para qué? Para que conozca a los usuarios, su nivel, su entorno, su trabajo. Por ejemplo…

¿Son usuarios avanzados en el uso de una computadora en general? Hace ya mucho tiempo (no creo que esto pueda suceder ahora) me di cuenta de que el significado de los íconos más básicos y estándar –guardar, abrir- de la barra de tareas del sistema eran completamente oscuros para el usuario de nuestro sistema, que utilizaba sólo el menú porque allí decía “Abrir”, “Guardar”, haciendo todo de una manera muy incómoda. El detalle cool (para mí) de poner íconos grandes y sin texto hacía que la barra fuese completamente inútil. El gesto –tan natural para mí- de poner el cursor encima de un ícono para ver una descripción de su funcionalidad era imposible en esta persona.

¿Son jóvenes, personas mayores? ¿Necesitan algún tipo de accesibilidad para utilizar el sistema? Allá lejos y hace tiempo tuve un compañero de trabajo, un contador –creo- que era tan corto de vista que tenía que usar la lupa… y les aseguro que el sistema se veía MUY diferente de esa manera.

¿Su trabajo les exige interacción constante con el sistemao es más bien esporádica? ¿Tienen otros sistemas abiertos? ¿Tienen que consultarlos alternativamente? ¿Llevan a cabo varias tareas al mismo tiempo? Esa transacción, que nosotros imaginamos como una rápida carga de datos y un enter final tal vez requiere de varios minutos entre ingreso e ingreso para conseguirlos. Otra de las cosas impensadas que vi fue un usuario que primero copiaba todos los datos necesarios a un archivo de texto. Lo hacía desde diferentes planillas, sistemas, desde el navegador y luego abría el sistema de presupuestos y los pegaba desde allí. ¿Por qué? Era obvio, porque temía perderlos y el sistema no le dejaba grabar el registro –aunque sea localmente o en un repositorio temporal- si no tenía los datos completos. Esta era una funcionalidad que yo había discutido tercamente por demasiado problemática en relación al beneficio –según mi propio punto de vista- que representaba para el usuario. Cuando lo vi no discutí más.

¿Están cómodos? No es lo mismo utilizar el sistema localmente que hacerlo a través de un escritorio remoto, o sentado cómodamente en un escritorio que de parado frente a un rack de servidores.

Siempre hay, en definitiva, alguna cosa rara. Se me dirá que es cuestión de hacer lo que los analistas o diseñadores nos piden y listo, que al fin y al cabo ellos han estado allí –o ha leído un documento redactado por alguien que ha hablado con alguien que estuvo allí-, pero eso nos limita a lo que ellos consideran fácil o posible.

Esto último me hizo acordar algo que había escrito en La “respuesta” a “¿Cuál es el error?”, la ambigüedad, su resolución y, finalmente, la realidad:

[…] ya lo dijimos, vivimos en un mundo imperfecto. Muchas veces (en todo proyecto real esta situación es más que frecuente) el cliente no está disponible […] o no entiende la pregunta. ¿Entonces?

[…] hay veces que hay que adivinar y seguir adelante, rellenar los huecos en las especificaciones apelando al sentido común […]

Cultivar el “sentido común” -al que apelan los programadores cuando tienen que inventar algo para tapar algún hueco- mostrándoles “la vida real” del proyecto para el cual trabajan ahorraría innumerables idas y vueltas entre desarrollo y producción y seguramente haría que surjan ideas y mejores posibilidades para el sistema.

Crisis, ajuste, motivación, productividad, oportunidad.

Corren tiempos de crisis. Traducido al argentino esto implica, aunque sea implícitamente (vía inflación, que aquí el que no corre vuela y el margen de beneficio a corto plazo se valora incluso más que la supervivencia), “ajuste” de salarios. Escribo “ajuste” y no ajuste porque con el entrecomillado pretendo denotar que “ajuste” no es ajuste sino un eufemismo para baja que suena feo. Y es baja y no “congelamiento” o “suspensión de aumentos” debido al pequeño detalle de la inflación mencionado más arriba.

Pero bueno, es lo que marca el mercado y si el golpe de la crisis se distribuye justa o injustamente entre capital y trabajo (o la suposición de que justicia y economía están relacionadas de alguna manera) no es el tema de este post.

Por otro lado, en la industria del del software (y supongo que en cualquier otra cuya base esté mayormente conformada por trabajadores del conocimiento) motivación y productividad están fuertemente relacionadas, si es que no son la misma cosa (¿podría decir que está motivado un programador que no produce? ¿por qué otra razón que no sea falta de motivación podría no producir un programador? Es decir, el que está motivado llega a un resultado, que puede no tener un gran nivel o calidad, pero producir produce).

Mi hipótesis es que si el mencionado “ajuste” afecta a la productividad en esta industria es -por lo menos principalmente- a través de esta forma indirecta, por su impacto en la motivación.

Es un buen momento para recordar aquello de que el motivador más caro es el dinero (creo que es una frase célebre pero no puedo encontrarla, tal vez esté formulada de otra manera). Es por ello que me cuidé de escribir que el ajuste “afecta” a la productividad y no que la disminuye o aumenta, ya que la productividad depende de la motivación y la motivación no necesariamente del dinero.

Me parece una explicación bastante sencilla de por qué hay emprendimientos o proyectos en los que la productividad aumenta considerablemente en tiempos de crisis: hay ajustes monetarios pero la motivación, y por tanto la producción (el desarrollo) se mantiene (o incluso aumenta) y la productividad (la relación entre recursos utilizados y avance obtenido) mejora.

Y también de por qué hay otros proyectos que florecen velozmente una vez pasada la tormenta: si el aumento de productividad es en la práctica una mejora en el proceso de desarrollo el proyecto actúa tal cual un resorte que absorbe el impacto primero e impulsa al equipo, empresa, organización o producto cuando la crisis pasa.

Y de por qué otros proyectos, incluso sobreviviendo a la crisis, no logran volver a ser lo que eran. Hay un punto en el que la motivación cae de tal manera que luego (parafraseando a un gran amigo) “a esto no se lo levanta ni con plata”.

Ejemplo un poco burdo: imaginemos tres equipos enfrentados a la misma crisis. En la práctica (aparte del “ajuste”), lo que sucede es que faltan horas/hombre de analistas funcionales para las pruebas, que el recurso de las horas extra está agotado (es decir, los actuales analistas están agotados) y que no hay posibilidades de contratar más.

• Equipo I: no hay respuesta. El equipo hace lo que siempre hizo: programar y punto. El proyecto se atrasa, el producto no mejora, se codifica pero no se prueba y las modificaciones no salen, etcétera. Para cuando pasa la crisis hay un retraso importante respecto de la tecnología y de los competidores que han sabido aprovechar o por lo menos capear el temporal.

• Equipo II: el equipo pone el hombro y se pone a probar. No son buenos probando pero hacen lo posible y la productividad sufre pero las cosas salen. Si pasa la crisis se vuelve al ritmo normal, y tal vez con más recursos se logra recuperar el tiempo perdido, aunque con gran esfuerzo extra.

• Equipo III: no se resignan a producir menos ni a trabajar más, por lo que buscan la forma de trabajar mejor. Así que buscan la forma no de cubrir las horas faltantes sino de requerir menos horas de pruebas. Descubren (imaginemos que no las conocían) las bondades de la programación orientada al test, herramientas para automatizar tests unitarios y funcionales, reducen costos con máquinas virtuales, programan simuladores de componentes y un largo etcétera. Para cuando la crisis pasa están mejor parados que al principio y cuando se recuperan los recursos éstos se utilizan para hacer más que antes logrando una gran expansión sobre un mercado depurado de competidores.

¿Cuál habrá sido el nivel de motivación en cada equipo antes de afrontar la crisis? ¿Y al final?

Una mala costumbre.

Identificado 100% con la última tira de Sinergia sin control. No hay nada que hacer: los programadores cometemos errores, probamos mal, nos vamos por las ramas, ignoramos las reglas más básicas del negocio… y los PM hacen este tipo de cosas (del tipo que ilustra la imagen de aquí al lado)… todo el tiempo y en todos lados. Aunque mal de muchos consuelo de tontos… por lo menos entiendo que no es algo personal.

Tal vez peque de corporativismo… no puedo dejar de pensar que hay una diferencia sustancial. Los programadores no podemos dejar de cometer errores, sin importar cuánto lo intentemos… cualquiera que se de un paseo por allí verá que (en general) de todas maneras hacemos un gran esfuerzo por evitarlos. ¿Es igualmente imposible no comprometer el tiempo de los demás sin consultarles? ¿No es de sentido común?

Se ve que no.

Soft Cero: Un proyecto en tiempo real.

Cerebrado anda muy movedizo en estos días, mucha novedad, mucho cambio, por suerte con buenas perspectivas a futuro.

Soft Cero es su nuevo blog, en el que está relatando el devenir de uno de sus proyectos actuales, haciendo nuevo equipo con JUNIOR y NERD (?). El blog comenzó con el proyecto y todo esto es bastante reciente, así que les recomiendo ponerse al día desde la primera entrada.

Es realmente interesante ver cómo se van desarrollando las cosas desde la etapa de las grandes definiciones hasta los detalles (a los que todavía no han llegado), ojalá tenga final feliz. No dejen de participar, quién sabe, tal vez un pequeño comentario tenga gran influencia en el resultado final.

Mejorando el trabajo en equipo.

Saltando desde el blog de Sebastián Hermida me encontré en abetterteam frente a una buena implementación de una encuesta incluida en el libro Art of Agile Development, de James Shore y Shane Warden.

El cuestionario evalúa el estado de un equipo de desarrollo ágil (se basa en XP, aunque creo que podría aplicarse a otras metodologías, con algunas salvedades) en 5 aspectos: Thinking, Collaborating, Releasing, Planning y Developing.

Hay una corta serie de preguntas Si/No para cada uno de ellos. Al final se presenta un panorama general del estado del equipo y se sugieren prácticas ágiles concretas para mejorar los puntos flojos detectados. También propone la posibilidad de registrarse para evaluar el progreso del equipo.

La encuesta comienza aquí.