archivo

Archivos diarios: febrero 4, 2012

Es una variante del antipatrón “Otra reunión más lo resolverá” en la que lo que cambia es el escenario, trasladándose al correo electrónico.

Surge cuando tras tratarse un determinado tema a través de este medio que ha dado lugar a un hilo de correos en el que han participado diferentes personas y en la que la discusión se ha podido prolongar durante días, sucede alguna de las siguientes circunstancias:

– No se llegó a ninguna conclusión o alguien no estuvo de acuerdo con la decisión adoptada y decide continuar el debate o iniciar uno nuevo en el mismo hilo o en otro independiente.

– No se llegó a entender (o no se recuerda) algunos de los temas tratados y para aclararlo, en lugar de buscar otra alternativa o dirigirse específicamente a la persona o personas que se lo pueden aclarar, decide volver al hilo o crear otro independiente.

Al final tenemos una recopilación de hilos sin fin, en los que en muchos casos, se desvía el tema principal a otros que en muchos casos ni siquiera tienen que ver con la actividad laboral, cuando no se generan conflictos, la mayoría de ellos derivados por la aparición del antipatrón “el correo electrónico es peligroso“.

El impacto de esto en la productividad individual y global resulta evidente.

Se trata de un caso particular de “reinventar la rueda” o de “reinventar la rueda cuadrada” y se produce con cierta frecuencia a la hora de realizar una nueva versión de un sistema de información o de informatizar un proceso que hasta ahora se venía gestionando de manera artesanal.

Este antipatrón lo tenemos cuando ante estas circunstancias se decide hacer tábula rasa, realizando un análisis desde cero y no teniendo en cuenta nada más.

Esto es un error, ya que si bien se ha decidido cambiar la herramienta que gestiona el proceso y habrá sus razones (en muchos casos más tecnológicas que otra cosa), también es cierto que hasta ahora han podido hacer el trabajo con ella (de mejor o peor manera) y que por tanto hay que aprender tanto lo que no gustaba o lo que hacía mal, pero también sus virtudes.

Si no tenemos en cuenta todo esto, corremos el riesgo no solo repetir los errores sino también de no reflejar en nuestra solución sus aspectos positivos.

En el antipatrón “los arquitectos no programan“, nos encontrábamos con que la organización consideraba que este tipo de perfil era lo suficientemente caro como para que participasen en el proceso de implementación del software, aunque sea como supervisores del trabajo que se está realizando o para resolver diferentes dudas que se encuentren los programadores en aspectos relacionados con el diseño o con la arquitectura.

Otra vertiente de ese antipatrón (que en muchos casos se produce de manera conjunta con la anterior) era el hecho de que los arquitectos prescindan o no den suficiente peso a la opinión de los analistas o programadores que van a tener que realizar el desarrollo.

Este antipatrón es una variante del anterior y se produce en alguna de las siguientes situaciones:

– El arquitecto aplica el antipatrón “arrojar al otro lado del muro“, es decir, ellos hacen lo que entienden que es su trabajo y después que sean los analistas y programadores los que se entiendan con el problema.

– Cuando se decide subcontratar el proceso de construcción, se envían las especificaciones y la arquitectura a utilizar y se vuelve a aplicar el antipatrón “arrojar al otro lado del muro”.

La verdad es que el nombre de este “antipatrón” podría ser aplicado a toda una infinidad de casuísticas dentro del proceso de desarrollo de software, sin embargo, se le proporciona un enfoque concreto aplicado al campo de la programación.

Este antipatrón se produce cuando se capturan excepciones y no se les aplica un tratamiento o el tratamiento que se les aplica no sirve absolutamente para nada, como si lo que se quisiera hacer es precisamente esconder las mismas bajo la alfombra.