Banco de experiencias (introducción)

Con este título, "Banco de experiencias", iré realizando (eso intentaré al menos, aunque aún no sé con qué frecuencia) aportaciones de mis experiencias en situaciones reales (no en laboratorio) y/o de sistemas en producción, probados en el mundo real.

Uso "banco de experiencias" como paráfrasis contrapuesta a "banco de pruebas", ya que ésto último, las pruebas, son el pan de cada día y sufrimiento diario de todos los arquitectos y desarrolladores de software. Y es que, a pesar de la cantidad de horas de desarrollo y buenas prácticas que tengamos encima, siempre tenemos la sensación de estar frente a algo nuevo. Y en realidad no es una sensación. Es la realidad. No hay dos sistemas iguales: siempre tienes que integrar con algo nuevo, siempre te encuentras que, cuando vas a hacer la instalación en producción resulta que el cliente no te había contado algo o que, simplemente, ni se te pasó por la cabeza y aparece algún elemento "metiendo ruido" como sacado de una chistera de repente.

El problema de la ingeniería del software, y del desarrollo, es que no se trabaja con materiales precisos, ni tenemos formas de medir objetivamente parámetros y tolerancias de los sistemas que nos permitan asegurar un mínimo de calidad. Además, contruimos sistemas "sobre" y/o "cooperativos" (sic) con otros (sean hardware o software) de los que no podemos tener mínimas garantías (y así lo podemos encontrar de forma expresa en las licencias de software privativo), con lo que no podemos garantizar tampoco el que construimos nosotros (suponiendo que pudiésemos).

Así, la "alta disponibilidad" se consigue, no garantizando sistemas que no fallen, sino garantizando que, cuando fallen (que lo harán) habrá otro sistema para ocupar su lugar. Un concepto éste, el de la "redundancia", ampliamente usado por los distintos generales de infantería de todos los ejércitos durante la historia. Ojalá pudiésemos implementar "alta disponibilidad" en el cuerpo humano a base de redundar el corazón, el cerebro...

En el mundo JEE, por ejemplo, me he encontrado muchas veces que una aplicación construida por nosotros tiene una falla inexplicable. Tras muchas pruebas y averiguaciones nos encontramos con un bug del servidor de aplicaciones o de la JVM...Los indicadores de ese tipo de fallos, así como los de los nuestros propios, y las soluciones aportadas nos van generando un conocimiento empírico, procedimental, que sedimenta formando lo que algunos llaman "expertise" o sabiduría. Por eso, los fallos que suele tener un programador novato no suelen ser los mismos que un programador experimentado. Los desarrolladores experimentados, como decía unamuno, comienzan a dar en el clavo porque han dado ya muchas veces en la herradura. Y digo bien: "experimentado". No todos los desarrolladores experimentados son expertos.

Dijo Aldous Huxley, que "La experiencia no es lo que te sucede, sino lo que haces con lo que te sucede". Y es cierto que hay unos pocos experimentados que acaban convirtiendo el error en experiencia, y son capaces de mezclar la experiencia propia y la ajena con su propia intuición creativa: ésos son los expertos (algún día tendré que hablar largo y tendido sobre el tremendo componente creativo que tiene el desarrollo de software, a pesar de lo que muchos puedan pensar).

La ventaja del mundo del software frente a nuestra vida cotidiana es que en lo que respecta al primero sí podemos aprovecharnos y aprender de la experiencia ajena: no hace falta que suframos el mismo problema que otro durante 20h hasta encontrar la solución, podemos ahorrarnos 19,5h si el otro nos cuenta su experiencia y nosotros la recordamos en ese momento.

De hecho, los patrones de diseño (una de las herramientas imprescindibles de cualquier desarrollador) no son más que un catálogo de experiencias resumidas: los problemas y sus soluciones aplicadas y comprobadas.


Hasta ahora he sido un usuario "pasivo" de esto de la blogocosa.... Pero creo que me toca ahora agradecer la generosidad de otros uniéndome a ellos, participando, compartiendo y aportando "my two cents" al acceso del conocimiento común y de la experiencia colectiva a través de mis propias experiencias y así, asumir mis propias disfunciones metacognitivas (gracias, Sr. Galli, por el magnífico artículo).

"Sólo una cosa es más dolorosa que aprender de la experiencia, y es, no aprender de la experiencia" (Laurence Johnston Peter, 1919-1990, Profesor y escritor canadiense).