archivo

Archivos Mensuales: enero 2013

El principio de Peter es consecuencia de la existencia de un solo sentido en la promoción profesional dentro de una organización, sin embargo, el principio de Dilbert, expuesto por Scott Adams, sí que tiene una base consciente por parte de la persona o personas que toman las decisiones y consiste en promocionar a empleados poco competentes a puestos en los que esté mucho más limitado y controlado el daño o pérdidas que son capaces de realizar.

¿Por qué es un antipatrón?, ¿no es está acaso salvaguardando la línea productiva y minimizando riesgos?. Desde luego que es una solución mucho mejor que no hacer nada, pero alimenta la cultura del “nunca pasa nada” (además de los costes adicionales de tener puestos vacíos o prácticamente vacíos de contenido), lo haces mal o pasas de todo y encima te ascienden a un puesto, en el que tal vez te aburras, pero en donde incluso vas a cobrar más.

El principio de Peter fue popularizado por los canadienses Laurence Johnston Peter y Raymond Hull en un libro homónimo publicado en 1969, con la famosa cita: “En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia… con el tiempo todos los puestos tienden a ser ocupados por un empleado que es incompetente para desempeñar sus funciones… El trabajo es realizado por aquellos empleados que todavía no han alcanzado su nivel de incompetencia”.

En ella trata de exponer uno de los principales inconvenientes de las organizaciones con promoción profesional vertical, en las que personas que son altamente competentes en unos puestos concretos, dejan de serlo en el momento en que ascienden a un puesto para que el que se requieren otras aptitudes.

De por sí, por típico en nuestro sector, podría ser considerado un antipatrón más. Sin embargo, en este artículo vamos a ver una versión de dicho principio directamente aplicada al desarrollo de software.

¿En qué consiste? Pues en el deterioro progresivo que sufre un software como consecuencia de su evolución y mantenimiento. Esto es una circunstancia que de manera general se produce en el desarrollo de software si bien puede ser contenida con buenas prácticas o acelerada en el caso contrario.

El antipatrón surge cuando un sistema está en continua evolución y no se toman medidas para mantener bajo control la deuda técnica y para seguir simplificando en lo posible su arquitectura y sus funcionalidades, de manera que si el sistema fue alguna vez útil, dejará de serlo poco a poco.

Como es algo que se suele producir lentamente y que tarda en detectarse, sobre todo si no estás acostumbrado a tener en cuenta estos aspectos, muchas personas consideran que es una forma de muerte silenciosa del sistema de información.

El principal motivo es la falta de cultura de producto por parte de los desarrolladores centrados principalmente en una cultura de proyecto orientada a la agenda y, por encima de ellos, de las organizaciones proveedoras y clientas de este tipo de servicios, que dejan en un segundo plano la calidad del software para centrarse en costes y beneficios.

Llegado un momento se toma la decisión de hacer una nueva versión de un sistema de información porque se entiende que está obsoleto tecnológicamente (resulta complicado encontrar desarrolladores para ese lenguaje de programación, el sistema de gestión de base de datos o el servidor de aplicaciones ha quedado sin soporte, etc…) o porque el coste de mantenimiento es muy alto y es necesario hacer modificaciones sobre funcionalidades ya existentes o el desarrollo de otras nuevas, etc…

Ese producto de partida conseguía su propósito y era utilizado de manera productiva por los usuarios y por la organización (lo cual no quiere decir que todo su camino para llegar a esa situación fuera sencillo o que nunca hubiera problemas).

Este antipatrón surge cuando se quiere aprovechar el nuevo sistema para incluir todas (muchas) las “cartas a los Reyes Magos” que usuarios, gestores y desarrolladores habían estado guardando todos estos años (más otras que se le ocurran sobre la marcha).

Una mala selección de las mismas dará lugar a un nuevo sistema que habrá sobrepasado con creces el presupuesto de partida, sin que exista un incremento de valor proporcional, mucho más grande que el que realmente se necesita, igual o más complejo de mantener que el anterior, en el que que tendrá problemas a la hora de implantarse porque será mucho más difícil de utilizar y administrar y con una más que probable importante tasa de errores y deficiencias funcionales de partida.

Arreglar esta situación es muy complicado, en algunos casos casi que lo más recomendable es empezar de nuevo.

A todo esto hay que añadir que el sistema anterior pesará como una losa sobre los desarrolladores porque los usuarios (los del día a día, más que aquellos que han intervenido en la definición de la nueva versión) siempre lo tendrán como referencia y lo estarán comparando continuamente y además, y sobre todo, los gestores verán como procesos que antes se desarrollaban de manera eficiente ahora cuesta más trabajo hacerlos, con el consiguiente coste económico que eso tiene, y pedirán cuentas por no tener un retorno de la inversión a la altura del desembolso realizado. Todo esto creará una situación de presión y unas prisas que poco bien harán para la mejora paulatina del sistema.

El término “Efecto segundo sistema” fue utilizado por primera vez por Frederick Brooks en su libro “The Mythical Man-Month”.

Este antipatrón surge cuando se ha llegado a un punto en el que la mejoras a realizar en un determinado producto software o tarea requieren un esfuerzo mucho mayor que el valor que se obtiene con las mismas.

Las causas que pueden dar lugar a esto son muy variadas:

– Tareas sobreestimadas en las que los desarrolladores deciden ocupar todo el tiempo disponible en la misma (ver Ley de Parkinson).

– El intento de mejorar ciertos aspectos del producto o de los entregables del proceso que tienen un buen nivel de acabado y en donde introducir mejoras resulta complejo (ver Ley de Pareto).

– Inclusión de funcionalidades por parte de los desarrolladores o perfeccionamiento de las ya existentes, sin haber consultado con el área usuaria y que lo mismo no resultan necesarias o tienen un efecto negativo sobre las ya desarrolladas.

– Tratar de seguir realizando tareas sobre el proyecto para continuar facturando o para demostrar que se está ocupado: creación de necesidades inexistentes, inclusión de funcionalidades que se utilizan en muy contadas ocasiones y por un grupo reducido de usuarios, refactorización sin efecto o prácticamente sin efecto sobre la deuda técnica, etc…

Los efectos de este antipatrón no solo se centran en un mal aprovechamiento de los recursos disponibles (que de por sí ya es importante), sino en la inclusión de una mayor complejidad en el sistema, de nuevos posibles errores, de la modificación o creación de elementos documentales, etc…, cada uno de los cuales añade un coste adicional innecesario al sistema.

Es un caso particular del antipatrón “software inflado“, en el que se invierte más esfuerzo del necesario en hacer los productos más robustos, seguros y complejos de lo que realmente necesitan.

Pero, ¿es malo que un software sea más robusto o más seguro? En absoluto, siempre y cuando no olvidemos cuáles son sus prioridades, es decir, si hacerlo más robusto o seguro de lo que necesita implica que tengamos que invertir esfuerzo en estas actividades y restarlo de la adecuada evolución del producto, no solo no estamos haciendo un uso eficiente del presupuesto, ya que lo invertimos en actividades que proporcionan menos valor, sino que además podemos poner en riesgo la propia línea de desarrollo del sistema, si es que nos quedamos sin dinero y no hemos cubierto las necesidades funcionales más prioritarias.

A lo anterior, hay que sumarle el riesgo de que se produzca un incremento de la complejidad del producto, ya que querer hacer el sistema más robusto o más seguro, no implica que se acierte con la estrategia, técnica o programación utilizada, lo que implica que aunque se consiga ese objetivo es posible que el producto sea más complicado de evolucionar (mayor deuda técnica) o que incluso se haya invertido un esfuerzo y que el sistema se haya quedado más o menos como estaba.

Otro aspecto que no hay que perder de vista, es que llega a un momento en el que no es posible mejorar la robustez, seguridad o complejidad del sistema, ya que lo que se termina mejorando en un punto, se termina estropeando en otro (ver Ley de Tesler).

El principio de Pareto no suele fallar, el 80% del objetivo se consigue con el 20% del esfuerzo. Saber donde parar es importante, no solo por el ahorro económico sino también por la propia calidad del producto.

En cualquier caso, el producto final que satisface las expectativas del usuario estará por encima de ese 80% y ahí es donde el peso de los detalles crece exponencialmente.

Y si algo tiene el desarrollo de software son detalles, si algo marca la diferencia son los detalles. Un solo detalle, una sola instrucción mal codificada puede dar al traste con la implantación de un sistema en los plazos marcados y esto puede suponer mucho dinero y pérdida de confianza.

Charles Eames, en otro campo donde los detalles son importantes, como la arquitectura y el diseño, tuvo un gran acierto con la siguiente reflexión, perfectamente aplicable al desarrollo de software y a otros muchos ámbitos: “Los detalles son los detalles. Ellos hacen el producto”.

El antipatrón “techo de cristal” trataba sobre barreras invisibles, basadas en criterios subjetivos o con falta de transparencia, en las que se impedía la promoción profesional de un trabajador o de colectivos concretos de trabajadores.

En este caso, la “pared de cristal” trata de un aspecto diferente, aunque tiene en común la aparición de resistencias de gran intensidad basadas en criterios subjetivos u opacos, que dificultan el avance de un proyecto o de un objetivo más general, hasta tal punto de ponerlos en un grave riesgo.

Una “pared de cristal” podría ser el resultado de la labor de un “generador de resistencias“, pero hay una diferencia que hace que sean dos antipatrones diferentes: el “generador de resistencias” aplica su criterio a todos los proyectos (o a una gran mayoría de ellos) y quien crea “paredes de cristal” lo hace a proyectos u objetivos concretos, que tienen alguna característica que no les gusta, ya sean decisiones técnicas, funcionales, económicas o por el simple hecho de que no se llevan bien o no les gusta alguna de las personas que intervienen.

Un proyecto puede ir muy bien y una “pared de cristal” convertirlo en algo insufrible. En lugar de invertir el esfuerzo en el proyecto, se invierte en el lugar equivocado, en intentar sortear un obstáculo que artificialmente se ha añadido en nuestro camino. Lo peor de todo es que el obstáculo no es un objeto inanimado, tratará de evitar que lo superes y si lo haces, no te extrañe que vuelva a intentar ponerte las cosas más difíciles de lo que ya son.