El sindrome de Estocolmo

En estos últimos años he estado en contacto con varios colegas de área de desarrollo de software que no están bien en sus respectivos empleos pero por algún extraño motivo se resisten a abandonarlo. Se quejan del ambiente, de algún jefe, de las herramientas que utilizan, de las horas que tienen que trabajar de más, caen enfermos con frecuencia, sufren muchas contracturas, engordan, en pocas palabras, sufren, pero aun asi no atinan a cambiar de trabajo.

No se si es algo aplicable a toda latinoamérica, pero aquí en Argentina, en estas épocas de bonanza, adonde la demanda de determinados perfiles supera amplia mente a la oferta eso es un poco... ilógico.

Aclaramos, no estamos diciendo que ante el primer pequeño problema o desmotivación hay que irse del trabajo. No, no es asi. Para ser claros, no estamos de acuerdo con el típico programador que salta de empresa en empresa, quedándose 3 A 5 meses antes de escapar a otra para evitar asumir cualquier responsabilidad o ganar dos centavos más.

Contexto laboral para el surgimiento del síndrome

Las situaciones a las que me refiero son bastante más enfermizas y de cierto maltrato. Esto no significa que los esclavicen con látigos o trabajando a destajo (eso se terminó hace algunos pocos años, jeje), no. Son maltratos mucho más sutiles.

En algunos casos se comienza por instalar una atmósfera rancia de presiones por alinearse con el proyecto en particular de una o varias personas. Surge luego un ambiente ligeramente amenazador adonde nadie se anima a decir en voz alta lo que piensa y termina con la instalación de amenazas veladas sobre que no estar de acuerdo implica despidos o degradaciones / humillaciones publicas o de cargos.

En otras empresas en cambio se da por una falta total de motivación causada por peleas políticas en las altas esferas que hace que cualquier proyecto se paralice y cambie de dirección mil veces antes de ser abandonado sin terminar, lo cual causa desmotivación, falta de interés seguido de aburrimiento y terminando en hastío.

A veces son simplemente ambientes estatales faltos totalmente de desafios e incentivos y en otras se generaliza la desmotivación cuando se premia cualquier cosa menos trabajar bien.

A quienes Afecta?

Son Programadores, Analistas, Arquitectos, personas capaces y responsables, viven quejándose, desmotivados, malhumorados, con cansancio crónico pero sin embargo no se dan cuenta que pueden irse de esas empresas. O cuando lo intenta, no alcanzan nunca a encontrar el trabajo ideal, ese que están esperando para irse.

Condiciones para la aparición del síndrome

Hace cierto tiempo había leído un articulo de Chad Fowler titulado : "Dead-End Jobs: Are You Suffering From Stockholm Syndrome?", el cual me pareció ciertamente un tanto exagerado. No obstante, ahora releyéndolo encuentro algunas similitudes ciertamente inquietantes.

En psicología el termino "Síndrome de Estocolmo" es utilizado para describir un comportamiento psicológico paradójico adonde un rehén desarrolla empatía y sentimientos positivos hacia sus captores.

Pueden leer el post de Chad Fowler que describe, seguramente mejor de lo que yo lo haré, las condiciones que se cumplen para que esto suceda en "Dead-End Jobs: Are You Suffering From Stockholm Syndrome?".

Fijense entonces las condiciones y después ustedes sacarán sus propias conclusiones.

A - Debe existir la percepción de una amenaza cierta a la supervivencia o integridad física o mental del Rehén.

B - Aislamiento del exterior y único contacto con opiniones y perspectivas de los captores.

C - Pequeños actos de bondad y cuidado de los abusadores a las victimas.

D - La percepción de la imposibilidad de escapar del abuso.

El punto 3 es esencial toda vez que si la conducta de un Captor hacia su victima es de violencia y agresión permanente el Rehén desarrollara odio o terror pero nunca se encariñará. Tiene que haber pequeños actos de bondad o que sean percibidos como tales para que la victima al tratar de evitar el miedo o el pánico se refugie en esos pequeños actos para protegerse mentalmente del miedo, de la perdida de control de su vida y del ataque a su autoestima.

Existen realmente los Trabajos-Captores?

Repito que a mucha gente, yo el primero, puede parecerle una exageración hasta aquí la relación entre sentirse atrapado por un trabajo y condiciones de secuestros reales adonde lo que esta en juego es la vida de la persona secuestrada. Pero si uno mira una a una las condiciones se pueden ver algunas similitudes.

Creo que es importante aclarar un poco mas sobre las condiciones que hacen que un empleo en particular tenga este efecto.

Como nos debemos a nuestra audiencia, para la proxima, prometemos desarrollar un mini-test de preguntas para ayudarnos a analizar si ese trabajo que te está haciendo pasarla mal te ha capturado, y lo peor es que no esta pidiendo mas rescate que tu salud.

Mantenibilidad vs Reusabilidad

Ya hace bastante tiempo que vengo haciendo entrevistas para contratar Programadores. Aparte del hecho de que es una actividad que depara no pocas sorpresas (ver sino: the-nonprogramming-programmer), y a la que debemos evidentemente darle alguna vuelta de tuerca, como hacer pair programming con el candidato, llenar de brea a los mentirosos o algo asi, no es el objetivo de este post charlar sobre técnicas de entrevistas sino sobre una pregunta que suelo hacer durante las mismas.

Recientemente un compañero, con el que estaba haciendo una búsqueda en particular entrevistando junto a mi, se reia cuando al promediar cada una de las entrevistas disparo la misma pregunta "Qué es lo más importante a tener en cuenta al programar un sistema? La Reusabilidad o la Mantenibilidad? Si te tuvieras que quedar con una de las dos, cual elegirias?". Luego de un par de segundos de desconcierto, la respuesta llega, siempre, invariablemente, la misma: " La Reusabilidad, claro".

Porqué? porqué?, cuando?, quien?, En que momento metimos en las cabezas de los programadores que el objetivo fundamental a perseguir cuando uno programa es la reusabilidad, es hacer componentes que puedan ser reusados una y otra vez?

Con una mano en la biblia del programador ("The art of computer programming", de Knuth?) cuantas veces recuerdan haber reutilizado un componente escrito para un sistema anterior? o Para el sistema presente? Vamos, recuerden que esta bajo juramento!

Ahora, cuantas veces recuerdan haber buscado en el código (o internet) un codigo parecido al que tenes que trabajar, copiarlo , pegarlo y modificarlo (POC/P: Programacion Orientada a Copy/Paste) ? Muchas?

Lo cierto es que a lo largo de la carrera profesional de un desarrollador siempre, invariablemente hemos visto como el marketing de un determinado framework proclama a viva voz : "Es para permitir armar componentes reutilizables", "Este framework generico te permite escribir ABM genericos, de manera de poder reutilizar las pantallas (los formularios, la ui)", "Este lenguaje permite extenderlo para facilitar la reusabilidad", incluso la POO fue vendida inicialmente como la panacea para lograr componentes reusables y extensibles.

A ver, que no se malinterprete, el código que uno desarrolla DEBE ser lo más reusable posible pero siempre, subrayo siempre, se debe dar prioridad en el diseño y el desarrollo a la MANTENIBILIDAD.

Porque?

Simple y sencillamente porque el hecho de que algo vaya a ser reusable depende de decisiones y acciones futuras con una determinada probabilidad mientras que la Mantenibilidad se necesita en el 100% de los casos y desde el primer dia de vida del sistema a lo largo de tooodo su ciclo de mantenimiento (notaron? Mantenimiento y Mantenibilidad? que casualidad), siempre claro, que el sistema entre en produccion.

Como uno no puede preveer el futuro, y no sabe si realmente va a reutilizar el componente que esta diseñando hoy, hacerlo más genérico de lo necesario implica hacerlo mas complejo de lo necesario para el caso en cuestion y esto a su vez lo hace mucho, mucho más dificil de mantenerrrrrrr!!!

Increible como parezca el mantenimiento de un sistema representa del 60% al 80% del costo total de un sistema, siendo el otro 20%-40% el costo del proyecto inicial de desarrollo (y estoy siendo conservador, conozco algunos que .... pero mejor no entro en detalles...por ahora). Reducir este costo es crucial y solo se puede lograr con un sistema lo mas simple posible, refactorizado y con amplia cobertura de tests de unidad. Esto último es esencial porque además si un sistema es mantenible los tests de unidad facilitan luego su extensibilidad porque es fácil modificarlo sin pisar alguna mina antipersonal y que todo el sistema explote!

Y La reusabilidad, que?

La reusabilidad de un componente, si viene, no viene dada por la clarividencia de un arquitecto iluminado sino por la repetida necesidad de una solucion similar a un mismo problema, que se refactoriza y extrae, utilizando justamente técnicas de refactoring y patrones de diseño (Ver GOF "Design Patterns", "Refactoring" de Martin Fowler o más recientemente Refactoring to Patterns, de Joshua Kierevisky). Es Posterior a la primera implementación, solo cuando uno se encuentra con el segundo ejemplo del problema o, mejor aún, el tercero, comienza a pensar en que está faltando un método o un componente (Clase) reutilizable (o cualquier otro síntoma de problemas con el codigo, ver Code Smells en el libro de Refactoring).

Entonces?

Entonces, chimpances entrenados, en todos los sistemas que hemos realizado lo más productivo ha sido tener, siempre y en todo momento, a la mantenibilidad como valor más alto.

El truco es que justamente al enfocarse en que nuestro código sea mantenible aumenta la reusabilidad!!! El código mantenible es más simple, tiene métodos y clases cortas, con menos acoplamiento, mayor cohesión, su intención y proposito es más claro, todo lo cual hace más fácil extraer comportamientos comunes y al refactorizar descubrir componentes faltantes que puedan ser reutilizados. Haciendolo al revés, se los digo por experiencia, no da el mismo resultado (el orden de los factores SI altera el producto, y no saben en que medida).

Ahora, hablar de "cómo?" hacerlo más mantenible es tema de otro Post, diría de una serie...., pronto en sus salas de blog más cercano!