archivo

Archivos diarios: enero 4, 2012

Lo más importante en el desarrollo de software son las personas. Cualquier fractura en el equilibrio dentro de los equipos de trabajo o entre los propios equipos de trabajo tiene consecuencias en el proyecto.

En el desarrollo de software hay presión, desgaste y circunstancias en muchos casos poco agradables que hacen, si cabe, todavía más daño si en el proyecto participan personas que resultan difíciles, conflictivas o que funcionan de manera absolutamente al margen de lo que es cualquier trabajo en equipo o de un comportamiento solidario y que rompen con la armonía del grupo.

El mantenimiento de estas personas en los proyectos (o en la organización) pese a su comportamiento y actitud da lugar a este antipatrón.

Este antipatrón surgió inicialmente para designar a prácticas realizadas por programadores en las que no existe una división efectiva en capas del sistema de manera que lógica de acceso a datos, negocio y de cliente se entremezclan.

Si esta situación se extiende a un sistema de un cierto tamaño, cualquier actividad de mantenimiento puede convertirse en toda una aventura, lo que te obliga a que salvo que sea absolutamente necesario, estés casado, sin divorcio posible con la solución implementada.

En general, este antipatrón se puede extender a cualquier situación en la que exista una dependencia de un elemento o de una serie de factores que dificultan el mantenimiento o evolución del sistema.

El término cargo cult surgió poco después de la Segunda Guerra Mundial en ciertas comunidades del Pacífico Sur donde con el objeto convocar como un Dios a los aviones que habían traído carga, regalos y provisiones durante la guerra, realizaban maquetas en madera de los mismos y simulaban pistas de aterrizaje.

Se ha establecido un paralelismo entre esa práctica y otras en el mundo de la programación, ingeniería del software y la gestión empresarial, considerándose cada una de ellas como antipatrones.

Todas ellas tienen en común la adopción de un aspecto que no se entiende, que se desconoce o que entendiéndose o conociéndose se ha incluido en una solución por el simple hecho de intentar mimetizar otra solución que ha tenido éxito en otro contexto.

En el caso de la programación consiste en copiar ciertas prácticas que podrían ser consideradas (no siempre) buenas prácticas sin saber muy bien los beneficios o ventajas que proporcionan. Esto provocará en muchos casos esfuerzo innecesario en el proyecto para incorporarlas y en otros casos incluso traerá consigo problemas (se están utilizando soluciones que no se sabe muy bien cómo funcionan o para qué sirven).

En el mundo de la programación también nos lo podemos encontrar con el propio copia y pega de código. Se sabe que este código permite realizar tal funcionalidad y lo trato de adaptar en el programa sin saber muy bien cómo funciona.

En el caso de la ingeniería del software, sucede lo mismo con la aplicación de metodologías, frameworks o tecnologías que se han visto que producen éxito en terceros (o por el simple hecho de que están de moda), sin saber muy bien qué ventajas ofrece respecto a cómo se venía trabajando hasta hora, por qué producen esas ventajas y si son adecuadas al proyecto.

En el caso de las metodologías ágiles hay mucho cargo cult, como ya comenté en el artículo: “Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología“.

A nivel organizativo o de gestión de empresas el caso es el mismo. Se intentan copiar prácticas o estrategias de la competencia que se entiende que son las que les está permitiendo alcanzar un cierto éxito, sin realizar un análisis de si realmente esa conclusión es adecuada o no, de si esas prácticas se adaptan a la cultura actual de la empresa y a la tendencia del mercado, etc…