Doble jornada

Camino rápidamente por la casa donde he vivido mucho tiempo... o viví mucho tiempo; veo a seres de mi infancia y presente mezclados con tal perfección que parecen conocerse; desgraciadamente no cuento con el tiempo para ahondar en esta sui géneris convivencia. Salgo rápidamente, un cliente me llama al mismo tiempo que mi esposa... por un alta voz escucho la conversación lejana.

Camino por el campo, cerro que recorrí muchas veces para llegar a la ciudad... no noto como esto carece de lógica, pero lo percibo. Difusas cortinas quitan claridad a los automóviles que están frente a mi oficina - donde entro - veo a mis compañeros y a mi perra y gato, ambos platicando con un compañero de trabajo. ¿cómo llegué aquí? no importa... ya estoy aquí.

Tengo que entregar un proyecto que paradójicamente nunca he visto; pero todos me hablan como si fuera el único que carece de dicho conocimiento, el cliente asistirá en 5 minutos a la sala Canadá; hasta ahora me entero que existe semejante lugar aquí en el Centro del Software Lincoln, en Halifax.

Camino, vuelvo a ver personajes, indíferentes pero turbiamente conocidos... probablemente hace tiempo, recuerdo que unas noches atrás conviví cercanamente con más de alguno, pero ahora esa historia me parece lejana... inclusive, no se se si existió en verdad. Hago una escala en la playa... amigos, compañeros, proveedores de regreso a la oficina...

¡la presentación! termino de escupir unas cuantas líneas de código que tenía pendientes... resuelvo realmente un problema que llevo tiempo sin lograr mitigar... ¡listo! me paro frente a un estrado... para hacer la presentación

Comienzo a hablar, un leve frío irrumpe en la entrepierna: me doy cuenta que olvidé ponerme pantalones.

despierto

Apenas comienza el día y voy por mi segunda jornada de trabajo...

Incansable terquedad de dos posibles verdades

Somos desarrolladores, emberrinchados por hacer, producir, crear y ceder a las siguientes generaciones de nuestro nuevo proyecto el producto de nuestra propia genialidad. Como buenos machos cabríos, nuestras ideas mueren con nosotros; hoy no fue la excepción.

Antes que entrar en materia, generemos un concepto. Existe una diferencia clara entre un soldado y un mercenario; el primero supone tener un código de ética y un objetivo lleno de valía hacia si mismo y su comunidad. El segundo, en contraste, se rije por la conveniencia de sus propios intereses; sin importar los principios y valores que éste viole, logra el objetivo impuesto por un tercero.

En menos palabras, el primero piensa y actúa y el segundo actúa de acuerdo a lo que alguien más pensó... sin más ni más, así como así - como viene -

Vamos a poner a nuestro sujeto en la mira; dicho sujeto paradójicamente es un desarrollador de software. De nueva cuenta bicho extraño al microscopio. La pregunta actual, ¿qué tanto un desarrollador debe cuestionar la lógica detrás de un análisis? más específico aún, ¿qué tanto debe cuestionar a un analista acerca de su propio análisis? o aprovechando el viaje, ¿qué tanto debe ser un mercenario o un soldado al momento de codificar?

La obviedad de la vida nos indica que todos creamos, crecemos, reproducimos y matamos errores. El análisis de un sistema es algo complejo de donde generalmente se gestan infinidad de indefiniciones, ambigüedades y, ¿poqué no?, contradicciones. Cuando tenemos un acervo de 300 requerimientos y una sola mente orquestándolos; no una, si no varias patinadas de mosca salen a relucir: innegociable.

Bajo esta premisa, ¿es válido cuestionar el análisis de un analista en su lógica de negocio?... regresando al inicio, ¿porqué hoy no fue la excepción? acérrima discusión se armó hoy en Innox intentando discernir el principio veraz de dicho cuestionamiento... conclusión: ninguna

Punto 1. El soldado. El desarrollador debe cuestionar a su analista la lógica cuando detecta, por efímero que sea el sentimiento, que existe una ambigüedad o una carencia de uniformidad con el resto del sistema o la lógica misma de este mundo que nos rodea.

Punto 2. El mercenario. El desarrollador no debe cuestionar la lógica a su analista ya que significaría no confiar en su trabajo; o bien, en caso de hacerlo y recibir una respuesta como 'así es porque si', acatar marcialmente la recomendación y tomarla como dogma de fé.

Voy a corregir lo que acabo de decir tres párrafos antes; si existió una conclusión. Depende del nivel de chismosidad de una persona para que la correctud entre estos dos puntos salga a relucir. Es correcto que el desarrollador debe confiar en el trabajo de su analista; pero también está bien entender a plenitud todas las cosas que no comprenda por completo.

La divergencia se encuentra en el nivel que una persona quiera realmente entender lo que se hace y actuar más lento en consecuencia, o ver periféricamente el contexto, atacar el problema y codificar lo previamente analizado.

¿Conclusión? permítanme especificar de nueva cuenta: no hay conclusión; hay cosas que ni qué, ¿tengo o no tengo razón?