¿Qué malos hábitos de la vida real te ha provocado la programación?

Esa pregunta en stackoverflow ha motivado la friolera de 457 respuestas, cada una más delirante que la otra. Es gracioso (¿o triste?) constatar que lo que uno imagina como pequeñas y personalísimas manías son en realidad taras compartidas por miles de programadores alrededor de todo el planeta.

Algunas de las tantas con las que me he sentido identificado:

I tend to take things hyper-literally. For example, my wife was annoyed when she used to ask "Do you want to take out the garbage?" (no) instead of "Will you take out the garbage?" (yes). […]

---

Q; Do you want tea OR coffee?
A: Yes

---

I really need control+Z in real world.

---

I find that sometimes I speak very precisely, and get irritated when somebody […] doesn't appreciate the precision of what I said, and treats what I said kind-of sort-of similar to what I said.[…]

---

Believing that being right is enough.

Believing that people will listen to reason.

[…]

---

If I ask a question that's yes/no, I have serious difficulty processing an answer that isn't either one of those.

For instance, Q: "Do you care if I flip the channel?" A: "I'm IMing my sister."

To me, this is like: public bool canFlip() { return "I'm IMing my sister"; }

The return value here is clearly a string, and supposed to be a bool. From the other person's end they're answering the question. From mine they've just committed an invalid cast error. If I ask again and they answer the same, well, that's throwing an exception in a catch block.

… y esas son sólo un par de las primeras, casi que las pondría todas.

Renovación y primeras impresiones de Windows 7

Los asiduos habrán notado una brusca caída del ritmo de publicación en estas últimas dos semanas. El trabajo tuvo algo que ver (no mucho). El inicio de clases, con las corridas y preparativos de última hora pesó un poco más. Pero la razón principal ha sido el fallecimiento de mi computadora de escritorio (una Pentium 4 HT 3.2Ghz).

Es posible que haya muerto de envidia. Su deceso se produjo a las pocas semanas de la compra de una Acer Aspire One (apenas una netbook, pero ya la superaba en performance). A través de este post le rindo un sentido homenaje…

Pero la vida sigue. No soy de jugar con el hardware. Cada vez que una máquina dice “basta” hago el esfuerzo y compro el equipo más potente que puedo para olvidarme del tema por un par de años, durante los que no me preocupo en lo más mínimo por su mantenimiento hasta que casca nuevamente.

Es ésa y no otra la razón de mi elección por un Intel Core 2 Quad Q8200, sobre un motherboard Intel DG31PR con 4Gb de RAM y una placa de video “decente” (no soy un fanático de los juegos), una GeForce 9400 GT.

Lo anterior solamente viene a cuento de poner en contexto lo que realmente me interesa, que no es el hardware sino el software. Hace un tiempo que venía con ganas de probar la beta del Windows 7, así que aproveché la obligada migración para distribuir un poco más racionalmente mis datos (después de un par de años programas, documentos, fotos, videos y desarrollos e instalaciones a medias convirtieron mis discos en una masa compacta, indivisible y desordenada de archivos) e instalarlo en una partición propia.

Preconceptos

La verdad es que si bien la muy respetable opinión (y entusiasmo) de uno de mis compañeros de trabajo cultivó mi curiosidad, era escéptico respecto de la nueva interfaz.

He visto el Windows Vista de lejos pero en la oficina sigo con el XP (que es, en mi opinión -y creo que en la de la mayoría de los usuarios-, el mejor sistema operativo de Microsoft al momento). Esperaba entonces más o menos lo mismo de siempre: muchos cambios estéticos, algunos realmente molestos, la mayoría simplemente inútiles o intrascendentes, y las opciones y funcionalidades de siempre redistribuidas de modo que se maximiza la frustración en las primeras semanas de uso, hasta el momento en el que uno se rinde y somete a los designios de la nueva UI.

Las críticas al Vista, y mi percepción de que el 7 seguiría a grandes rasgos la misma línea no ayudaban mucho. Escéptico por naturaleza, descreía del buzz positivo alrededor de la nueva versión. En resumen, esperaba el chiste de siempre: uno se pasa la primera media hora jugando y los dos o tres primeros días tratando de dejar todo como estaba.

Instalación

Primero hacer un poco de espacio: achiqué la partición de un disco de 300Gb (nota mental: es bueno tener por lo menos dos particiones –datos y sistema operativo-) con el Partition Magic y creé una nueva de 20Gb. Un par de errores y reintentos después los datos contenidos en aquel disco estaban perdidos. Empezamos bien.

Ya molesto por el trabajo de recuperación que se avecinaba inicié con el disco de instalación del build 7057 de Windows 7.

Primera sorpresa: Ok, empezaba con una partición limpia, pero eso no resta méritos. Siguiente-siguiente-siguiente, escasos 20 minutos y ya está. No lloró por drivers, ni pidió actualizaciones, no aparecieron las típicas e inútiles preguntas que interrumpen la instalación cada 5 minutos (obligándome a aburrirme cerca de la máquina), ni siquiera se equivocó con la distribución de teclado.

Me pasé el resto del día recuperando y reorganizando los archivos perdidos en el movimiento de particiones, para finalmente reformatear todo el espacio libre. Trabajo aburrido si los hay, pero tengo que reconocer que la vida es más fácil teniendo las cosas ordenadas.

Primeras impresiones

Sorpresa. Es lindo. Bueno, eso era esperable. Pero más que lindo… es casi… sobrio. No molesta. No pregunta. No aparecen mensajes extraños ni anuncios catastróficos compitiendo por mi atención para que baje, actualice o descubra.

Lo primero que llama la atención es la barra de tareas, con el famoso preview que aparece al pasar el cursor por encima del ícono del programa abierto.

Pero es más que un “chiche”. Moviendo el cursor sobre el preview la ventana emerge al frente mientras las demás se vuelven transparentes, desde allí mismo podemos cerrarla o minimizarla, o volver a la ventana anterior con sólo desplazar el mouse fuera del preview. Se puede agregar o quitar el acceso directo a ese programa en la barra de tareas desde allí mismo, por lo que ya no hay que “personalizarla”, uno lo va haciendo y deshaciendo sobre la marcha.

La otra característica que me impresionó desde el primer momento es el cuadro de búsqueda en lo que antes era el “menú de inicio”. Mantiene el foco siempre que esté abierto el menú y va mostrando los programas y opciones de configuración que concuerdan con lo que vamos tipiando. Creo que puede extenderse para buscar en internet desde allí mismo, pero todavía no lo he probado.

Ese primer día me la pasé explorando y tocando opciones… y dejé todo como estaba. No, no dejé todo igual al XP, dejé todo igual a la configuración por defecto.

La convivencia

Luego reinstalé el XP en otra partición (hay que conservarlo, no olvidar que esto es una beta), y obviamente eso rompió la instalación del 7. Reparé la instalación del 7 desde el CD (identificó el problema –XP instalado después del 7 o Vista embarulla la configuración del multiboot- y lo reparó puntualmente, sin reinstalar) y –obviamente- rompió el XP (bueno, algunas cosas no cambian nunca). Indagando un poco me enteré de que el viejo y sencillo boot.ini fue reemplazado por el retorcido y complicado BCDEdit, que superó en largo mi paciencia para estos temas, con lo cual decidí simplemente borrar todo, instalar primero el XP en una partición, luego el 7 en otra y a otra cosa mariposa (¿ven para qué es bueno tener datos y archivos propios por separado? Yo aprendí de la manera difícil). Pero más allá de esos primeros roces los dos sistemas operativos conviven y comparten el resto de las particiones sin problemas.

Un par de días después

Me rindo, tengo que reconocerlo: Windows 7 es muy, pero muy bueno. Me molesta trabajar con XP, simplemente me molesta. Las nuevas características (sobre todo las dos mencionadas arriba) son tan naturales que es tan fácil acostumbrarse a ellas como difícil resignarlas luego.

Es obvio que Microsoft ha escuchado mucho a sus usuarios y se ha adaptado más a ellos que en otras versiones, abandonando esa actitud de –me parece- imposición de visiones en la forma de interacción con el sistema.

El rendimiento es impecable, aunque es obvio que si no lo fuera en esta máquina ya sería el colmo. Me han comentado que se degrada elegantemente en equipos con menos recursos, pero no lo he probado personalmente.

Han cascado varios programas (por mérito propio), y por supuesto que programando y probando he metido un par de bucles infinitos, ejecutado algún que otro código malicioso, y llevado la máquina casi al límite (con un par de máquinas virtuales haciendo de servidores de base de datos y de páginas web al mismo tiempo) y el sistema operativo ha respondido siempre sin problemas. Dudo que alguna vez le exija más que eso y estoy seguro de que un usuario medio tampoco.

Conclusión

De que Microsoft le ha vuelto a robar ideas se ha vuelto a inspirar en Apple, a Ubuntu y demás no caben dudas. De que nos vuelven a usar como beta testers gratuitos han escuchado a los usuarios tampoco. También es verdad que para mí, por primera vez desde aquel traumático primer pasaje del NT 3.11 al 95 (¡¿dónde están mis grupos?! ¡¿Qué es esto del escritorio?!) la transición es suave, relajada, para nada traumática, y, en definitiva, muy positiva.

Windows 7, en beta y todo, ya es mi sistema operativo por defecto desde hace una semana completa, en la que me he dedicado más a trabajar que a jugar (aunque he vuelto a jugar bastante, ahora que puedo) y tengo que reconocer que es más que cómodo. Por primera vez Microsoft ha logrado que su interfaz llegue velozmente al objetivo: volverse invisible al usuario.

Ahora no hay excusas para volver al ritmo habitual. Nos leemos.

Jueguitos de viernes: Unfair Traps

Unfair Traps recuerda mucho al Rick Dangerous, (que merece su lugar en la Wikipedia, y que pueden descargar aquí, o jugar online en versión flash). Sólo que con más... "mala onda". Bloques que desaparecen, púas, piedras, trampas, y carteles que sólo están allí para hacernos enojar más.

No es apto para personas irascibles.

¿Armamos la polémica? Discutamos sobre lenguajes.

Nunca fui un gran fanático del deporte, pero la mayoría de mis compañeros de secundaria sí. Casi todos de fútbol, aunque era también importante el subgrupo del tenis, y el del básquet.

Era inevitable, en cada salida, el momento en que, como buenos hinchas o fanáticos, desplegaran todo su conocimiento estadístico-enciclopédico en intrincadas polémicas acerca de si tal equipo, jugador o escuadra era el mejor o peor en determinado momento.

Las frecuentes discusiones sobre lenguajes y plataformas de programación me recuerdan mucho a esos momentos en los que escuchaba fascinado una sucesión interminable de nombres, fechas y anécdotas que no entendía demasiado y de la que no retenía absolutamente nada… alineaciones, torneos ganados, goles a favor y en contra, números y afirmaciones de dudosa procedencia y que nadie se preocupaba demasiado en corroborar.

En un entorno más “geek” se mencionan comunidades, herramientas disponibles, eficiencia en tiempos de ejecución, en consumo de recursos, seguridad, escalabilidad… uf, un montón de cosas, potenciadas además por la meta-discusión acerca de los criterios por los que se debe realizar la evaluación (ver por ejemplo Todas las discusiones sobre lenguajes son absurdas… que confirma iniciando otra discusión absurda).

Como discusiones de café están muy bien, no por absurdas dejan de ser divertidas, y el intercambio siempre aporta algo interesante. Pero… ¿y en la vida real?

En la vida real (y aquí viene el puntapié inicial de mi propia discusión absurda, inútil y divertida) la elección debería ser clara, natural. Que no lo sea es señal de problemas.

¿En qué lenguaje tenemos experiencia, con cuál venimos trabajando? Debería ser la primera elección. Pero podría no ser técnicamente aplicable, o estar volviéndose obsoleto (por ejemplo ASP, Visual 5 o 6, para dar ejemplos no demasiado discutibles), o la experiencia anterior pudo no haber sido buena. Entonces habría que repetir la pregunta, buscar opciones en la experiencia previa de los integrantes del equipo tomados individualmente.

¿Siguen sin aparecer opciones? Mmmm…. ¿Ven lo que digo? Señal de problemas. Ya estaríamos ante una situación bastante inusual, ¿en qué extraño –para nosotros- proyecto estamos metidos? Yo diría que el paso siguiente es buscar experiencia ajena, indagar un poco acerca de la combinación lenguaje/plataforma más utilizado en proyectos similares y adoptarla. Y sería más que recomendable incorporar a alguien con experiencia, porque la ajena es mala consejera.

Se me dirá conservador. En este tema lo soy. No me es difícil pensar en adoptar un nuevo lenguaje,  pero sí vería con recelo adoptarlo en un desarrollo profesional sin estar acompañado de alguien con experiencia. Es lindo experimentar pero negocios son negocios, y ponerse a jugar con chiches nuevos aumenta en mucho el riesgo del proyecto y probablemente estemos sacrificando calidad en el producto final (porque al fin y al cabo en eso se traduce la experiencia). Luego, cuando los resultados no son buenos, es fácil culpar a la plataforma, cuando en realidad el problema es que no la hemos utilizado correctamente.

¿Java, VB, C#, PHP, Python, Ruby…? Estoy seguro de que en cualquiera puede desarrollarse un producto excelente, escalable, rápido y bonito, así que no es ésa la discusión. La discusión es en cuál podemos hacerlo nosotros.

10 Plantillas SMS para tiempos de crisis.

Advertencia: si no te va el humor negro mejor no sigas.

En estos tiempos de crisis que corren ya no son suficientes las clásicas plantillas para responder SMS del tipo “Estoy llegando”, “Nos vemos allá” o las más impresentables “Te quiero”, “Yo también te quiero”.

Creo que (y por desgracia) las siguientes se han vuelto muy útiles, sobre todo porque llegada la ocasión suelen enviarse en masa:

1. Lo siento mucho.
2. Vas a ver que termina siendo para mejor.
3. Fue un gusto.
4. Todos te queríamos.
5. Que no se corte.
6. Algún mediodía nos juntamos.
7. Quedate tranquilo que vas a encontrar rápido.
8. Se te va a extrañar.
9. No vamos a encontrar otro como vos.
10. ¡Así que fuiste vos el que me afanó la taza!

Que no por estándar son menos sinceras, cuando me toque las voy a agradecer.

Frases: Iniciativa.

Rara vez publico un insulto aquí, en esta “sección” de frases, pero ésta que remata la tira de hoy de Dilbert me pareció muy buena:

“Your head is where ideas go to die”,

sobre todo por el contexto (vean la tira). Hace mucho, en la cursada de “Sociología de las organizaciones” tuvimos la visita de un gerente de una mutual del estado. Un tipo joven, lleno de iniciativa, con verdaderas ganas de mejorar no sólo el servicio sino también la calidad del trabajo.

Hablaba sobre todo de management y algo que hoy sería como empowerment (eran otras las palabras pero era eso, al fin y al cabo). No todas sus ideas me parecieron buenas, y le comenté mis reparos sobre alguna de ellas, relacionada, justamente, con la iniciativa. Me contestó algo que recién ahora empiezo a valorar (esto no es textual, por supuesto):

“Mirá, son ideas. La mayoría ni siquiera son mías, sino de la gente con la que trabajo. Cuando vienen a quejarse por algo o con problemas en general ya tienen una solución en la cabeza, y en principio yo lo único que hago es decir sí y ayudarlos a que ellos la pongan en marcha. Si luego no funciona ellos mismos vendrán con otra, y con otra y así… bueno, en algún momento va a salir ¿no?

Lo importante no es tanto el éxito de una iniciativa como el hecho de demostrar a la gente que presentar esa iniciativa vale la pena, que si piensan proactivamente eso se transforma en cosas reales. Si yo cajoneara las iniciativas que me parecen malas –muchas me parecen malas- perdería también las buenas. Total, ya te digo, si no funciona… probamos otra vez”.

Chrome Canopy.

Es increíble lo que se puede hacer con javascript… y un navegador como la gente. No me funciona en IE, no investigué si a propósito o no… en todo caso es un lindo efecto.

Twitteado por @mattcutts.

Code Monkey.

Me lo encontré en Back Door mientras navegaba por Bitácoras.

Frankenstein, el líder de proyecto (XVII).

ATENCIÓN: ¡No sigas si no has leído la dieciseisava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: siguiendo las órdenes de Frankenstein al pie de la letra la criatura silenció los errores, por lo que ante su inevitable ocurrencia el módulo descartó los datos silenciosamente. Luego de un mes de operaciones el equipo descubre que el módulo de Pago a Proveedores nunca funcionó.  Frankenstein, desesperado, recurre al líder técnico, quien le niega su apoyo comprometiéndose solamente a reescribir el módulo lo más rápido posible… que no es mucho.]

Frankenstein salió de la sala de reuniones con la vista clavada en la punta de sus zapatos. Una vez sentado frente a su escritorio su atención vagabundeó distraídamente por la oficina posándose finalmente sobre su creación, que fijaba la suya en la pantalla.

Ya no lo soportaba. La presencia de aquel inútil arreglo de carne y huesos no hacía más que impedirle pasar el mal trago de los últimos días, cargados de cuestionamientos y vanas explicaciones.

Pasó algún tiempo y poco más. La recodificación del módulo avanzaba a cargo del líder técnico. La criatura continuaba cumpliendo pacientemente el ritual de entrada, espera y salida, al que ahora se había sumado Frankenstein. Expulsado de los círculos de confianza de la empresa, se encontraba falto de nuevos proyectos o iniciativas propias.

No tardó mucho en comprender que el equipo lo invitaba a partir. Sabía que eventualmente podría recuperar la confianza de sus superiores pero no el respeto de sus colaboradores. Ante ellos este episodio había descubierto su visión –su incomprensión, dirían ellos- del desarrollo de software. Una visión que no solamente no compartían, sino que despreciaban.

Redactó una carta de renuncia, que presentó la semana siguiente.

Pasaron un par de meses antes de que el líder técnico, sin saber qué hacer con aquel extraño programador caído en desgracia, se decidiera a despedirlo.

- ¿Qué tengo que hacer ahora? –preguntó ingenuamente la criatura luego de que se le comunicara la decisión.

- No sé… –respondió el líder, incomodado por la pregunta- depende de vos ahora… estoy seguro de que buscando podés encontrar algún lugar en el que te sientas cómodo…

La criatura se encontró, en una tarde lluviosa de viernes, parado en una esquina del microcentro porteño. A su alrededor una corriente silenciosa de personas se abría paso entre las bocinas de los autos y colectivos. Sin saber qué hacer, caminó hasta el estudio de Frankenstein.

- ¿Qué hacés acá?

- Me… dijeron que me vaya. ¿Qué tengo que hacer ahora?

- ¿Te echaron? Era de esperarse… fue un error, nunca tendría que haberte creado, ahora lo entiendo.

- ¿Qué tengo que hacer ahora?

Su mirada vacuna revelaba el sinsentido de su existencia. Frankenstein lo miraba horrorizado, no soportaba lo que aquella criatura le decía sobre él mismo, sobre su tozudez, su soberbia, su adicción al poder, al control.

- Hacé tu vida, no quiero volver a verte –le dijo mientras cerraba.

La criatura detuvo la puerta firmemente, y así quedaron por unos segundos. Frankenstein, incrédulo ante aquel atrevimiento y la criatura inmóvil, la vista perdida, intentando resolver aquel enigma… ¿qué hacer ahora?

- ¿Có… cómo me llamo? –preguntó.

- No sé -Nunca le había dado un nombre. La criatura soltó la puerta. Un golpe seco retumbó en los pasillos del edificio. Frankenstein observó por la mirilla mientras ésta volvía sobre sus pasos y desaparecía por el ascensor.

Salió del edificio, hacia la lluvia, y se perdió por las calles de Buenos Aires.

…fin.

Jueguitos de viernes: Gurabitchon.

Gurabitchon es... raro. Ingenio, habilidad, paciencia...

Lo que es seguro es que es muy divertido. Como (casi) siempre, aporte de @Cerebrado.

Frankenstein, el líder de proyecto (XVI).

ATENCIÓN: ¡No sigas si no has leído la quinceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: con el sistema ya en producción y en medio de una calma absoluta, el departamento de SAC (Servicio de Atención al Cliente) recibe un informe de error de parte del área de pago a proveedores. El jefe de SAC revisa la base de datos del cliente y consulta al analista a cargo del proyecto, quien luego de confirmar el error renuncia precipitadamente.]

“Esto no hace más que confirmar mis teorías –pensaba Frankenstein luego de leer la carta del analista renunciante-. Este tipo está claramente desequilibrado, qué duda cabe. Se comporta normalmente hasta que un buen día empieza con problemas, se queja de la calidad de su propio trabajo, intenta eludir el compromiso… finalmente lo asume, trabaja a destajo para corregirlo, lo logra… y cuando todo es un éxito… renuncia. Así, sin más explicaciones salvo esta carta de agradecimiento…”.

Estaba de buen humor. Se sentía lleno de energías y nuevos proyectos. Las presentaciones y los informes le habían dado la oportunidad de ganar la confianza de clientes y accionistas y él la había aprovechado. El camino para su nuevo proyecto estaba prácticamente allanado.

“En un año, tal vez en menos –pensaba-, mi único problema, las personas, será sólo un mal recuerdo. El analista será el primero en ser reemplazado por una nueva criatura. El líder técnico está por irse, lo presiento, y será el siguiente. Con un aliado a la cabeza de cada área controlaré el desarrollo. No habrá que preocuparse por los demás, el que no se adapte será reemplazado”.

El jefe de SAC pasó por la puerta de la oficina, interrumpiendo sus ensoñaciones.

- Me imagino por tu buen humor que todavía no viste el reporte que ingresé ayer al sistema. Yo que vos apuraría eso.

Frankenstein ingresó al sistema y leyó el reporte. Dos veces. Con los codos apoyados sobre el escritorio y las manos tomándose la cabeza, bajó la vista y conoció el infierno. El mismo que ya habían atisbado el líder técnico y los demás programadores, sólo que desde otro punto de vista. Todo estaba, como había indicado el líder técnico, irremediablemente perdido.

- Imagino que ya leíste el reporte –el líder técnico, al tanto de la situación desde temprano, estaba ahora sentado frente a él.

- No entiendo… ¿cómo pasó esto?

- Ya te dije que el chico no piensa, que no tiene criterio, que sólo es un muy mal traductor, ni siquiera un intérprete. Supongo que… alguien… le habrá indicado que el módulo debía pasar las pruebas, que no debían verse más errores… o algo por el estilo. Supongo que fuiste vos, ya que no acepta órdenes de nadie más.

- Yo… yo le dije que…

- Le dijiste lo que terminó haciendo. El módulo funciona con los casos de prueba y no se ven errores. ¿No era eso? El problema es que sólo los casos de prueba funcionan y que jamás muestra errores. Así que ahora hay que decirle al cliente que todo el sector de pago a proveedores estuvo un mes entero ingresando datos en un sistema que simplemente los descartaba silenciosamente, que no sabemos por qué, y que tampoco sabemos cómo solucionarlo rápidamente.

- Voy a pedir la documentación de respaldo… les digo que la necesitamos para verificar… lo que sea. Decíle a los programadores que la vayan ingresando al sistema manualmente. Mientras corregí el módulo.

El líder técnico tenía emociones encontradas. Por un lado se sentía íntimamente reivindicado por los acontecimientos. Su visión del mundo se había tambaleado, pero finalmente prevalecido. Lo tranquilizaba el confirmar que aquello que para él era importante lo era también realmente.

Pero al mismo tiempo había confirmado un fracaso, uno importante e inesperado, no sólo personal sino colectivo (todos los éxitos y los fracasos son colectivos, sólo que los primeros suelen ser apropiados por alguien y la responsabilidad de los segundos suele quedar diluida). No sólo Frankenstein se había equivocado con la nueva incorporación y la asignación de responsabilidades. Los gerentes la habían aceptado, los programadores fueron indiferentes, el analista sometido a la voluntad de un programador menos que mediocre y él mismo no había revisado la marcha del módulo hasta demasiado tarde… y encima se había dejado convencer, a pesar de toda su experiencia, de que aquello había funcionado.

“Es hora de aceptarlo y dejar que las cosas caigan por su propio peso”, pensó.

- Er… no –el líder técnico se sentía incómodo. De alguna manera Frankenstein siempre lograba obligarlo a apretar el freno antes que frenar él mismo cuando hubiese correspondido-.

- ¿Cómo?

- Mirá, tenés un equipo de programadores, no los voy a poner a cargar datos… aunque probablemente el nuevo no tenga problema en hacerlo, creo que es el hombre para la tarea. De todas maneras el módulo es, aparte de inútil como su creador, ininteligible e inmodificable.

- Pero tenemos que hacer algo…

- Odio tener que decirlo de esta manera, pero… “Tenemos” me suena a manada, eso ya no es mi problema.

- ¿Qué me estás diciendo?

- Mi trabajo es arreglar este desastre. Arreglarlo en serio, no seguir dando manotazos de ahogado en medio de un pantano, y eso lo que voy a hacer. Desgraciadamente los tiempos y los costos no serán del agrado de nadie, no esperes milagros. Esta es la realidad, y hacer que gerentes, clientes y usuarios la entiendan y acepten es tu trabajo, no el mío.

Frankenstein calló.

El líder se retiró e inmediatamente reunió al equipo de programadores.

- Volvemos a 0. Necesitamos recodificar el módulo de proveedores, lo más rápido posible. Así que todos vamos a trabajar en ello. Lean las especificaciones, mañana a primera hora vemos cómo distribuirnos las tareas.

- ¿Él va a participar? –La pregunta se refería a la criatura, que continuaba aislada en su rincón. El líder la miró. De algún modo percibió que estaba prestando atención, que lo sucedido no le era indiferente. Dudó por unos instantes.

- No –“Y realmente lo siento”, pensó.

…continuará. Actualización: capítulo XVII.

Internet en la oficina.

Me ubico discretamente al lado del diablo, que es donde me gusta estar, y le susurro un par de cosas al oído.

“¿Te preocupa que tus empleados, subordinados, súbditos, estén perdiendo el tiempo en vez de trabajar? ¿Te preocupa que te estén tomando el pelo, vagueando mientras te jugás el puesto en cada proyecto del que sos, en última instancia, responsable? En general los hombres juzgan más por los ojos que por la inteligencia, pues todos pueden ver pero pocos comprenden lo que ven”.

Sé que le preocupa. Por eso restringe, por ejemplo, el acceso a internet. No sea cosa que se la pasen navegando por allí en vez de trabajar. Hay mucho que hacer.

“Estás cometiendo un error –sigo-. Para perder el tiempo basta un jueguito, un solitario, un buscaminas, un café… No castigues nunca a la fiera que no puedas aniquilar. Y no podés aniquilar eso. En cambio… internet es algo que podés al menos controlar”.

Me mira, incrédulo.

“Sí, podés controlarlo, pero ni siquiera hace falta”.

Sonríe. No me cree.

“Es simple: dejá que hagan lo que quieran. Pero que a fin de mes cada uno de ellos reciba un reporte con los sitios que ha visitado y el tiempo que les ha dedicado. La liberalidad se devora a sí misma, pues a fuerza de ejercerse se agota”.

No entiende para qué, es un poco duro.

“No hace falta que controles –susurro- basta con que quede claro que, si hay problemas también habrá, por lo menos, un registro objetivo que indique el grado de… compromiso de cada uno”.

Hay gente que se abusa, dice.

Ingenuo. “Y tendrás pruebas para demostrarlo. ¿No es una buena excusa para tener a mano y tomar medidas en caso de que… ¿abusen? Cuando se hace daño a otro es menester hacérselo de tal manera que le sea imposible vengarse”.

Ocupan un recurso que es necesario para las operaciones, dice.

“Vamos… asigná un ancho de banda fijo para las operaciones, dejálos que se maten entre ellos por las sobras”.

Que van a llenar de virus toda la empresa, dice.

“Nadie dice que tengas que dejar que instalen nada. Hablando de virus, ¿qué otras formas hay de que ingresen a la red? ¿estás ya controlando todas esas? ¿No son puertas más grandes y más abiertas?”

No quiere pensar en eso, le da escalofríos. Mejor así, retruca, que ni siquiera pueden ponerse a perder el tiempo.

“Entonces si hay un retraso no es culpa de ellos”, le digo. “Es culpa tuya”.

Ahora me presta atención.

“Internet sirve, les sirve… Todos los Estados bien gobernados y todos los príncipes inteligentes han tenido cuidado de no reducir a la nobleza a la desesperación, ni al pueblo al descontento”.

Levanta una ceja. 

“Para que puedan hacer trámites y operaciones que de otra manera les insumirían más tiempo, tiempo de tu tiempo. Y se capacitarían solos sin que te cueste un centavo, y no habrían excusas para no saber hacer algo”.

Pero se la pasan hablando mal de la empresa, dice.

“Eso es inevitable, pueden hacerlo desde cualquier otro lado y en una forma mucho más anónima que desde aquí… ¿no es más fácil eliminar las razones de que lo hagan? ¿No mejoraría eso la imagen de la empresa? ¿La tuya? Pocos ven lo que somos, pero todos ven lo que aparentamos”.

Sé que lo piensa…

"Es de gran importancia disfrazar las propias inclinaciones y desempeñar bien el papel del hipócrita", le digo, y me reconoce.

NOTA: A no rasgarse las vestiduras, que esto está bajo “humor”. El que no entienda el chiste que no se ría.

Frankenstein, el líder de proyecto (XV).

ATENCIÓN: ¡No sigas si no has leído la catorceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: El sistema –incluyendo el módulo de pago a proveedores- se instala y el proyecto es un éxito. Frankenstein alaba la participación de su criatura y critica en duros términos la del resto del equipo en un informe que es presentado a la gerencia. En un clima de calma, el líder de técnico busca un nuevo trabajo mientras que la criatura… no hace nada.]

La semana –la cuarta desde la puesta en producción del sistema- transcurría, como las anteriores, con calma. Calma de la que disfrutaban analistas, programadores, líderes, gerentes y clientes, abocándose a tareas rutinarias, a la búsqueda de nuevos horizontes o a la nada misma, dependiendo el caso.

El trabajo recaía sobre el sector de soporte al cliente. Enfrentados a un nuevo sistema de gestión los usuarios inundaban las líneas con un sinfín de consultas y problemas menores. Pero si bien el trabajo había sido duro en las primeras semanas la gravedad de los incidentes estuvo siempre dentro de los parámetros normales y había entrado rápidamente en una suave pendiente negativa.

El jefe de SAC (Servicio de Atención al Cliente) miraba, un poco aburrido, las estadísticas de las consultas.

- Mirá qué loco… “Incidentes nivel 2 (defectos)… discriminados por módulo… Pago a proveedores… 0”. Ni un error. O no lo están usando o estamos a la vista de un milagro.

- Lo están usando –respondió uno de los operadores telefónicos-. Hay una señora que me estuvo volviendo loco ayer y hoy. Es la encargada de los informes del área y están cerrando el mes. Muy amable y simpática… tenía anotados todos los pasos para sacar los informes en una libretita… “Escribir fecha de inicio, arriba a la izquierda”, “Botón Aceptar”… y claro, ja ja, con el sistema nuevo la libretita voló a la mi…

Sonó el teléfono. El operador señaló el tubo con una sonrisa, dando a entender que se trataba, otra vez, de su nueva mejor amiga. Después de unos minutos –el jefe de SAC jugaba un solitario- cortó.

- Uf… logró sacar el informe. Ahora dice que algunos números no le cierran. Me lo estuvo explicando todo (te lo anoté en el reporte del incidente) y creo que tiene razón. Te lo paso.

- Ya decía yo… no podía ser –respondió el jefe. Leyó el incidente y revisó la documentación del informe.

- Ja, mirá, me juego la vida que es esto. Acá en el documento de análisis dice que hay dos clases de proveedores con los que se pactan diferentes modalidades de pago…  bla, bla, bla… cuestión que lo que dice la señora es que son tres, y me juego a que el informe no está mostrando los registros del tipo que falta. A ver…

Un par de horas después (permisos, explicaciones, autorizaciones) el jefe de SAC se conectaba a la base de datos del cliente.

- Ups… –dijo después de un rato, y salió precipitadamente de la oficina.

Fue directamente a hablar con el analista que estuvo a cargo de las pruebas del módulo, con quien tenía –como casi todos- una muy buena relación. Le explicó detalladamente el problema y lo que había encontrado en la base de datos.

- Ajá. Sí, definitivamente tenés razón –respondió éste luego de ver los datos en la base por sí mismo. Mientras se preparaba para salir-. Mirá, tengo que salir temprano hoy. Pasá el incidente al área de desarrollo, por mí está confirmado -juntó con parsimonia todo lo que había sobre su escritorio, guardándolo prolijamente en un maletín rígido. Saludó a todos y salió. Al día siguiente la empresa recibió un telegrama de renuncia de su parte y Frankenstein una afectuosa carta de agradecimiento por “estos años compartidos”. Nunca más se supo de él.

Entre idas y vueltas se habían hecho las siete de la tarde. Frankenstein recibiría el incidente al día siguiente por la mañana.

El jefe de SAC volvió a su oficina y juntó sus cosas, dispuesto a irse.

- ¿Qué hacemos con la señora de pago a proveedores? Está desesperada, dice que necesita el informe para mañana.

- Decíle que se vaya tranquila. Que pasamos el informe al área de desarrollo y que no hay nada que ella –“o nosotros”, pensó- pueda hacer. Esto va para largo. Me voy. Mañana va a ser un día de aquellos…

…continuará. Actualización: capítulo XVI.

¡¡¡Es OTRO trabajo!!!

¿Por qué es tan difícil de entender?

Del inefable GeekHeroComic.

Cuando se cumple con los requisitos y no sobra nada.

Examen de literatura

Ejercicio: Realice una composición literaria que incluya los siguientes tópicos:

• Sexo
• Monarquía
• Religión
• Misterio

Respuesta: Se follaron a la reina, ¡y el rey no estaba! Por Dios, ¿quién habrá sido?

Otro gran aporte de @Cerebrado, y vaya uno a saber de dónde lo sacó.

Jueguitos de viernes: Ice Breaker.

Ice Breaker es un juego muy original, en el que tenemos que rescatar a éstos vikingos varados en un paisaje helado ayudados sólo con una herramienta para cortar el hielo en forma conveniente.

Es muy difícil.

Frankenstein, el líder de proyecto (XIV).

ATENCIÓN: ¡No sigas si no has leído la treceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: Luego de ver el código del módulo -vasto e ilegible- el líder técnico habla con Frankenstein anunciándole el fracaso en el desarrollo, situación que éste, enfurecido, no acepta. Mientras tanto la criatura termina las correcciones de acuerdo a las instrucciones de Frankenstein y el módulo supera las pruebas. El sistema está oficialmente terminado.]

Frankenstein pasó una semana entre instalaciones, presentaciones, capacitación, ajustes de último momento y reportes finales. El sistema estaba, por fin, instalado y funcionando a plena capacidad.

La tormenta había pasado. El líder de proyecto redondeó su balance y lo presentó a la gerencia.

“El proyecto ha resultado un éxito rotundo. […]

[…] El nuevo integrante del equipo ejecutó impecablemente sus tareas, ajeno a distracciones e inmune a los problemas que afectan a los demás programadores: cansancio, falta de motivación, falta de compromiso.

Si hubo un punto oscuro en esta experiencia, fue que el resto del equipo no estuvo a la altura.

Por un lado, los analistas han demostrado su incapacidad para producir especificaciones completas y correctas en un principio, y para enmendarlas con la debida celeridad después. La velocidad de este programador, su capacidad para trabajar sin descanso a lo largo de varias jornadas, ha compensado estas faltas.

Por el otro, los programadores –y en especial el líder técnico- han confirmado que sólo estarán disponibles cuando los tiempos sean laxos y la tarea de su agrado.

En mi experiencia como líder de proyecto, falto de alternativas, he aprendido a someterme –lo más veladamente posible- a sus caprichos. Veo en la actitud de éstos, taciturna y esquiva hacia mí, y en la tenacidad con la que dejan sentado en todo momento que ninguno de ellos tuvo participación en el módulo encargado al nuevo integrante del equipo, la respuesta típica de quienes ven amenazada la posición dominante que han ostentado desde siempre en esta empresa. […]

[…] Creo que es hora de iniciar un proceso de recambio. Estoy abocado a la elaboración de una propuesta para incorporar más personal con las mismas características sobresalientes de este elemento, con el que conformar un nuevo equipo que […]”

Durante ese tiempo y en las semanas que siguieron, los programadores corrigieron y ajustaron los últimos detalles.

El líder técnico trataba de asumir el golpe. Su autoridad había sido socavada por la imposición de un nuevo miembro al equipo y por la asignación a éste -con buenos resultados- de responsabilidades que le eran propias. Había irrumpido con fallidas visiones apocalípticas que, en definitiva, fueron interpretadas como un berrinche ante la pérdida de poder...

“…y lo que es peor –pensaba-, todo funciona. Todo está bien. Tal vez sea yo… nosotros… tal vez todo esto de la legibilidad, de la resistencia del código a los cambios sea, finalmente, una cuestión menor a la que los resultados son indiferentes…

¿No he pecado de falta de pragmatismo? ¿No son los resultados los que importan? ¿Estoy buscando elegancia, claridad o belleza en una simple herramienta? ¿Cuál es la diferencia entre este módulo y el resto del sistema? ¿Que su código es feo, que es inmodificable? Este tipo ha demostrado que feo no importa y que inmodificable no es, que él puede programar así… habrán, seguramente, más como él… ¿entonces?”

Cansado, desmotivado, aburrido, perdía sus horas leyendo, buscando respuestas en una bibliografía que por primera vez resultaba contraria a su experiencia… buscando también un nuevo trabajo.

“Si todo esto es así, sólo me queda huir lejos de esta gente, lejos de estos proyectos… buscar el lugar en donde el esfuerzo por crear algo bello aparte de funcional tenga sentido… no de cara a los resultados, a los clientes, a los gerentes, sino para mí y para las personas que me rodeen…”

Recorrió la oficina con la mirada, casi a modo de despedida. En el rincón opuesto el programador, inmóvil, la vista al frente, los brazos colgando inertes a los costados del cuerpo, esperaba una nueva asignación. Habían pasado ya tres semanas desde la puesta en producción del sistema. Aún sin nada que hacer la criatura llegaba y se retiraba puntualmente todos los días, que pasaba inmóvil, la vista al frente, los brazos colgando inertes a los costados del cuerpo, esperando una nueva asignación.

…continuará. Actualización: capítulo XV.

Una breve historia de COBOL.

Me ha encantado la entrada El Cobol. Bonus Track: el “Virus del Milenio” publicada por Macluskey en El Cedazo (gracias Cerebrado).

El autor repasa la historia del lenguaje en tono coloquial. Alguna vez lo aprendí -después de BASIC-, pero desgraciadamente no quedó nada de él en mi memoria salvo un odio irracional por las columnas 4 y 8.

Realmente transmite mucho cariño por la herramienta (me ha enternecido). A ver si de acá a 20 o 30 años sigo publicando en algo parecido a este blog… “en mis tiempos había que teclear todo el código… deberías ver lo que era aquello”.

Vale la pena seguir hacia atrás las entradas del autor que conforman Historia de un Viejo Informático.

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

Frases: Planificación.

"Los planes son inútiles, pero la planificación es indispensable”.

No fui yo quien lo dijo, sino Eisenhower.

Vista al fondo de Capital riesgo y nuevas tecnologías, de La Pastilla Roja.

Metáforas: la deuda técnica (technical debt).

Paying Down Your Technical Debt, de Coding Horror, trae a cuento esta metáfora pergeñada por Ward Cunningham.

La deuda técnica es, muy básicamente, aquella en la que se incurre cuando se desarrolla funcionalidad rápidamente posponiendo cuestiones menos urgentes tales como legibilidad, escalabilidad, simplicidad, etcétera. La implementación “sucia y rápida” es el capital de esta deuda que, como toda deuda, genera intereses que el equipo va pagando en forma de aumento de costos de mantenimiento y dificultades al desarrollar nuevas funcionalidades. La única forma de quitarse el peso de ese interés es pagando el capital, o sea refactorizar la funcionalidad.

Martin Fowler la desarrolla muy bien en su blog en la entrada TechnicalDebt (en inglés, por supuesto). Para los que prefieran leer en castellano, el blog “Qué quieres desarrollar hoy?” ha publicado un post reciente al respecto.

A leer, que se acaba el mundo.

¿Aburrido?

Hace ya un tiempo que tengo agendada para comentar esta entrada de The Daily WTF. El artículo clasifica los proyectos de software según el interés que pueden representar para los programadores.

Así, el software “aburrido” tiene nombre y apellido:

[…] information systems. And while the purpose of an information system changes from company to company, as do the specific requirements, they all are essentially the same. There’s a database that models the real world, rules to define how the data may be changed, an interface to the database, and lots of different reports.

…que es casi todo software que soporte algún tipo de negocio, en contraposición con el software “divertido” que representa

[…] the type of things that we use on a regular, day-to-day basis: SVN, Google Maps, Visual Studio, Firefox, etc. In fact, as software developers, we rarely have to use boring software ourselves.

En realidad se refiere a este último tipo de software como “sexy”, lo que me lleva a poco serias reflexiones sobre las inclinaciones del autor del artículo.

Pero más allá de eso descubro, no sin cierta sorpresa, que he dedicado mi vida a proyectos “aburridos”… es más, les he dedicado años de estudios universitarios (soy Licenciado en Sistemas de Información de las Organizaciones, que bajo este punto de vista es casi lo mismo que Licenciado en Sistemas Aburridos)… este blog, habrán notado, está también dedicado a ellos en gran medida.

El artículo me ha dejado pensando. He llegado a la conclusión de que… es verdad. Ese software es aburrido. Es innegable, un hecho de la vida.

Es aburrido para los usuarios, no cabe duda: no me imagino al cajero de una de las salas de juego que utilice el sistema de gestión de la empresa para la que trabajo saltando de alegría cuando el sistema le indique que “ha completado la venta del ticket” o algo por el estilo. Tal vez sí me imagino al gerente festejando luego de consultar un reporte de beneficio, pero no creo que se deba al hecho de utilizar el sistema.

Y puede ser aburrido para los programadores, dependiendo de lo que a éstos les interese.

Si sólo te parece divertido pasarte una semana testeando diferentes tipos de algoritmos de ordenamiento para bajar el tiempo de respuesta de un servicio en 100 o 200 milisegundos… sí, probablemente este tipo de software te parezca aburrido.

Si sólo te motiva quemarte las pestañas estudiando complejas fórmulas matemáticas para lograr que esa estúpida computadora diferencie un auto de una vaca… si, un arqueo de caja es aburrido.

Si únicamente saltas de alegría cuando ese driver que estás desarrollando para que otra impresora funcione en otro sistema operativo logra imprimir un “hola mundo”… y, probablemente que el sistema arroje un error comprensible para el usuario no te parecerá un gran logro.

Esas pueden ser las motivaciones de muchos. Están muy bien, ya que gracias a ese tipo de programadores tenemos sistemas de archivos resistentes a fallos, bases de datos cada vez más rápidas, lenguajes de cada vez más alto nivel, una miríada de sistemas operativos para cada necesidad, librerías de reconocimiento de imágenes y un montón de innovaciones espectaculares para revolucionar negocios y organizaciones (no saben cuánto puede agradecer alguien como yo el “simple” Plug & Play y los drivers transparentes).

Pero las mías (y creo que por suerte las de mis compañeros de equipo también, y las de muchos otros) son otras: quiero hacer software útil para una organización.

Ese objetivo puede implicar optimizaciones, reconocimiento de imágenes, interacción con otros dispositivos (de hecho hemos tenido que hacer o utilizar algo de todo eso eventualmente) y otras cosas “divertidas” (que les aseguro que finalmente no lo son tanto), pero lo que me ha llevado a enfrentar esos problemas ha sido siempre la satisfacción de cumplir un requerimiento de la organización, y sólo en menor medida la satisfacción de resolver un problema difícil con un algoritmo ingenioso.

La gracia del desarrollo de estos sistemas no está tanto en la codificación, que efectivamente es 90% rutinaria (consulta a base de datos, operaciones simples sobre colecciones, algunos cálculos, ingreso de datos del usuario, validaciones, grabar en la base de datos y listo).

La gracia está

• en los problemas que representa un entorno de desarrollo cambiante y muchas veces caótico, con clientes que desesperan, analistas que deliran, jefes de proyecto que dicen sí a todo y programadores que cometen (cometemos) más errores de comprensión del negocio que de codificación (a no enojarse por las referencias, ya ven que hay palos para todos);

• en la necesidad de armar y mantener una estructura que soporte esas constantes modificaciones y que al mismo tiempo sea simple y fácil de usar;

• en hacer que esa codificación rutinaria sea lo más rápida y limpia posible (o incluso automática), para tener más tiempo para lo que es realmente importante: diseñar, mejorar, innovar, simplificar;

• en la coordinación e interacción con otros compañeros de equipo u otros equipos que desarrollan otros módulos del sistema;

• en la comprensión del flujo de la información de un negocio en particular y en descubrir cómo el software puede optimizarlo, ayudando a las personas a preocuparse menos por tareas rutinarias (para eso está el sistema) y más por lo que sólo ellas pueden aportar mediante su esfuerzo.

Por supuesto, estos componentes están presentes en todos los sistemas (en los “divertidos” y en los “aburridos”), sólo que en unos tiene mayor importancia que en otros.

Más que buscar o crear chiches nuevos para integrar a nuestro proyecto,  partimos de los requerimientos y buscamos aquello que represente la mejor manera de satisfacerlos.

Así, si he aprendido a programar en entornos web ha sido porque un negocio lo requería. Si adopté MVC no fue por probar el nuevo framework de Microsoft sino porque tenía un enredo entre datos, negocio y presentación que necesitaba ordenar. Si experimenté con AOP fue porque encontraba requerimientos transversales, y así…

Creo, entonces, que no hay sistemas aburridos y divertidos. El mundo del desarrollo es enorme, así que está en cada uno encontrar el lugar en el que los requerimientos encajen en las propias motivaciones.

Así que si estás aburrido… ¡muévete!

Frankenstein, el líder de proyecto (XIII).

ATENCIÓN: ¡No sigas si no has leído la doceava parte! Y si no has leído nada empieza por el principio.

---

[Resumen: Finalmente el líder y los programadores acceden al código de la criatura y a través de él intuyen su naturaleza. Esta visión los horroriza primero e inspira tristeza y lástima después. Pese a su apariencia humana, la criatura no es otra cosa que “un paso más, mecánico, transparente e inútil entre el analista y el software”.]

El líder técnico intentaba imaginar el origen de aquel vacío pero no podía. Luego de algunos minutos vagando entre terrores imposibles entendió que tenía que seguir. Reunió sus escasas fuerzas en un solo impulso con el que logró alcanzar la oficina de Frankenstein, desplomándose en la silla frente a éste.

Frankenstein había escuchado aquel grito y observado la escena desde su cubículo de paneles de vidrio. No entendió qué era aquello que horrorizaba tanto a los programadores pero sí que había un problema, uno grave y, por sobre todas las cosas –esto era lo que más le molestaba-, otro inesperado.

Se acomodó en su sillón, cargado de ansiedad. Si bien -a través de los años- había aprendido a tratar a las personas y sus problemas, hacerlo implicaba para él un trabajo consciente, constante y muy cansador. En momentos de tensión –los clientes presionaban, los directivos presionaban, todos presionaban- esta sobrecarga amenazaba con romper los límites de su autocontrol. Era cuando adoptaba esa actitud resolutiva y enérgica -casi agresiva- tan valorada por sus superiores y el delicado equilibrio entre los medios y los fines se rompía, inclinando la balanza siempre hacia estos últimos.

- ¿Qué pasa? –preguntó al líder técnico que, desparramado en la silla, había agotado sus fuerzas para llegar hasta allí y no lograba iniciar la conversación.

- Ya está, no hay nada que hacer. El módulo de pago a proveedores no sirve… no existe, en realidad. No hay nada que hacer.

- ¿De qué estás hablando? ¿Qué pasa?

El líder describió lo que había visto y lo que ello implicaba.

- ¿Qué tonterías son éstas? –exclamó Frankenstein. Por primera vez en muchos años estaba desbordado-. Escucháme, no me interesan estas boludeces ahora. El módulo está ahí, lo puedo ver, lo puedo usar. Tiene errores y hay que corregirlos, punto. Somos profesionales, tenemos un resultado comprometido y tenemos que cumplir con ese compromiso. Eso es lo único que te pido.

- Lo que me pedís es imposible, ya te expliqué.

- ¿Qué estás diciendo? ¿Cómo imposible? Andá y terminá con esto, por favor. No me interesa cómo, en una semana a más tardar quiero el módulo terminado –Frankenstein estaba fuera de sí. Normalmente el líder técnico hubiese reaccionado, tal vez con violencia. Pero en ese momento estaba demasiado cansado para eso.

- Víctor, no va a estar. Simplemente no va a estar. Ni en una semana, ni en dos ni en tres.

- ¿Entonces cuándo?

- No sé –el líder respondía maquinalmente, sin pensar en las consecuencias de lo que decía-. Ni la documentación del módulo ni su análisis ni su codificación pasaron nunca por mí. Todo fue asignado al nuevo y él no sirve. Estamos en cero.

- No me podés responder eso… es tu responsabilidad…

Por primera vez el líder levantó la vista. Miró fijamente a Frankenstein, que estaba rojo de ira. Una profunda convicción acerca de la imposibilidad de hacer nada a tiempo lo tranquilizaba.

- No creo que sea mi responsabilidad -interrumpió. -Mi primer error fue ceder cuando asignaste esa responsabilidad a un sólo programador, y el segundo quedarme tranquilo confiando en que sabías lo que hacías. Tal vez podría haber evitado todo esto, pero eso no me hace responsable. No es tan importante, de todas maneras. Ya está, el resultado es el mismo.

Frankenstein apenas podía contenerse. Se levantó, recorrió toda la oficina hasta llegar al puesto de su criatura.

- ¿Terminaste las correcciones?

- Sí.

Se dirigió hacia el equipo de analistas y testers.

- Quiero ese módulo probado para hoy a última hora. La que sea.

Y volvió a su oficina. El líder técnico todavía estaba allí.

- No voy a tolerar esto. Esto no va a quedar así. Tengo que ocuparme de esto yo mismo, pero después vamos a hablar. Andá.

El líder trasladó su cuerpo desde la oficina de Frankenstein hasta su escritorio, donde permaneció todo el día leyendo distraídamente. Cuando el reloj marcó la hora de salida tomó sus cosas y se retiró. Frankenstein lo siguió con la mirada.

- ¿Te vas?

- Sí. No tengo nada que hacer.

Un par de horas más tarde un analista tocó en la oficina de Frankenstein.

- ¿Terminaron las pruebas?

- Sí. Está OK, el sistema está cerrado.

… continuará. Actualización: capítulo XIV.

¿Necesitas un nuevo trabajo?

Monster
Cargado por baronrojo

Gracias a Cerebrado por el vínculo.