archivo

Archivos diarios: diciembre 20, 2011

Como no podía ser de otra forma, se considera como antipatrón, toda complejidad funcional, en arquitectura o en código que no aporta, en proporción, una solución mejor que una solución más simple.

A este antipatrón se puede llegar también a través de otros antipatrones como el de la lava seca o el ancla de barco.

Ya resulta tremendamente complicado llevar a cabo de manera efectiva un proyecto de desarrollo de software como para andar introduciendo complejidad de manera gratuita.

Coger una pala y echar al sistema más deuda técnica, añadir funcionalidad que no se va a utilizar, es hacer más grande el problema y lo mismo se llega a un punto donde resulta complicado seguir desarrollando y/o manteniendo el sistema con los medios disponibles.

Por ese motivo hay que analizar bien qué decisiones se toman (viabilidad, complejidad, utilidad, prioridad, riesgos, etc…) y siempre que sea posible realizar acciones que permitan simplificar la solución.

Existen multitud de circunstancias que llevan a situaciones de crisis en los proyectos, por lo que lo más probable es que tarde o temprano en el proyecto en el que estás trabajando ahora tendrás un momento de crisis y si tienes la suerte de que en este no te encuentras ninguno, no pasará mucho tiempo en que te toque uno en el que la sufras.

Cuando hay crisis, hay presión, presión ejercida en muchos casos por personas que no alcanzan a comprender la complejidad del problema y que solo quieren un resultado. Esa presión a su vez es recibida por los gestores del proyecto y estos de una u otra manera la transfieren al resto del equipo.

Es importante en este tipo de circunstancias, que cada cual sepa qué es lo que nos estamos jugando, para eso es necesario informar, explicar y no simplemente dar instrucciones porque sí.

La crisis puede durar semanas, incluso meses, la presión, el exceso de trabajo, hará mella en el equipo y es conveniente tratarlo de manera adecuada, intentando comprender las circunstancias individuales de cada uno dentro de un contexto global en el que o todos colaboran en la consecución de un objetivo o lo que queda es el desastre.

Si durante la crisis no has actuado bien, te has dejado llevar por la presión y no has tratado de manera adecuada a tu equipo o al resto de stakeholders, te condicionará el proyecto. Puede que hayas apagado un fuego, el que se ve, pero has podido provocar otros que no se ven.

Otro modelo de gestión, perfectamente complementario con otros modelos de gestión que también son antipatrones, es aquel que está basado en la toma de decisiones sin escuchar lo que terceros pueden aportarte.

No hay que confundir esto, con que en determinadas circunstancias tengas que tomar de manera individual determinadas decisiones. Cuando se cae en este antipatrón es cuando esa forma de gestión se convierte en norma.

Creerse dueño de la verdad absoluta es un error y dan igual tus conocimientos y experiencia. Es muy probable que haya personas más cercanas al problema que puedan aportarte información necesaria para una toma de decisiones más correcta o es posible que a alguien se le haya ocurrido algo que puede resultar bastante interesante y ese alguien puede ser incluso alguien que lleva, como quien dice, cuatro días en el mercado laboral (las ideas están ahí, no hay que rechazarlas porque se entienda que proceden de alguien sin el bagaje profesional necesario).

Otro tipo de gestión de equipos de trabajo y personas a las que estamos, desgraciadamente, muy acostumbrados.

Se trata de una gestión en la que se mantiene en la opacidad informativa a los subordinados, los cuales prácticamente se limitan a ejecutar las tareas que se les encomienda.

En un mundo de robots, tal vez ese modelo de gestión funcione, pero en un mundo de personas, no.

No se trata de tener que dar explicaciones por todo, sino de informar cómo van las cosas, por qué se han tomado determinadas decisiones, solo eso. No es tan difícil.

Este tipo de gestión, además del malestar que causan, da lugar a continuos malentendidos porque al final siempre existe determinado tipo de información que se filtra hacia abajo, pero que no suele llegar completa y donde cada uno de nosotros se encarga de llenar los huecos que faltan.

Partamos de la base que estoy absolutamente a favor de delegar funcionalidad del sistema en componentes ya construidos que estén lo suficientemente probados y rodados, independientemente de que sean propios o de terceros, siempre que de estos últimos exista la posibilidad de tener un soporte y actualizaciones mediante un contrato de servicios y/o licencias claro, en los que se impida la imposición de futuras condiciones abusivas.

De lo contrario estaríamos ante otro antipatrón, que es el de reinventar la rueda o lo que es lo mismo, invertir esfuerzo en resolver un problema que ya está resuelto.

El bloqueo del vendedor se produce cuando se delega funcionalidad de una aplicación en un componente de un tercero tomar las precauciones necesarias que te protejan ante una posible situación de cautividad ante él.

Es posible que el componente no afecte a una parte esencial del sistema y sea fácilmente sustituible por otro, sin embargo, hay veces donde afecta al propio núcleo del sistema y la sustitución puede requerir un importante tiempo y esfuerzo que lo mismo no están disponibles.

Confianza ciega, un problema que afecta a una gran cantidad de programadores, no haciendo caso a una cita de Doug Linder que indica una de las características fundamentales que debe tener un buen programador: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido”.

Confianza ciega es todo lo contrario. Se desarrolla una funcionalidad o se corrige una incidencia y no se prueba lo suficiente y/o no se tienen en cuenta efectos colaterales.

Siempre hay que hacer testing, lo mismo te parece una pérdida de tiempo, pero a la larga, haciendo sumas y restas, será mucho más el tiempo de desarrollo que te has ahorrado que el que has invertido haciendo pruebas.