archivo

Archivos Mensuales: diciembre 2011

Este antipatrón se puede relacionar con todos aquellos en los que se trata la introducción de complejidad innecesaria en el desarrollo o en el producto final (por ejemplo “funcionalitis acechante” o “complejidad no indispensable“) y con aquellos donde una solución base que resuelve en determinados casos problemáticas concretas o que son aptas para proyectos concretos, se entienden que valen para cualquier problemática o concepto que se encuentra dentro de ese dominio de actuación (obviando otros factores) e incluso se extienden fuera de ese ámbito (por ejemplo, los antipatrones “todo lo que tienes es un martillo” o “bala de plata“).

En este caso la complejidad adicional al sistema se incluye al intentar hacer una analogía del mismo con otro que tiene alguna o algunas características comunes (ámbito de negocio parecido, funcionalidades semejantes, mismo tipo de cliente, mismo cliente, idéntico entorno tecnológico, etc…), es decir, se toma como base otro y en lugar de profundizar en las expectativas reales del usuario o en la complejidad del problema o del proyecto que tenemos ante nosotros, se pone la atención en intentar adaptar esa idea o esa solución.

Esto, además de poder estar alejado a lo que los usuarios quieren realmente, pueden incorporar una mayor complejidad al proceso de desarrollo y/o al propio sistema de información, haciendo necesario un mayor esfuerzo, dificultando su posterior mantenimiento y empeorando la experiencia del usuario (cuando no el cumplimiento de sus expectativas).

Hay que entender que una organización quiera normalizar los desarrollos que se realizan para la misma, con el objeto de tener un control sobre las tecnologías y soluciones utilizadas en los trabajos y de esta forma reducir el riesgo de cautividad del proveedor (aunque en muchos casos, este riesgo viene dado por su conocimiento funcional) y disminuir los costes de mantenimiento.

De hecho, considero una buena práctica que una organización tienda a eso porque de lo contrario lo que se tiene es un caos tecnológico muy complicado y caro de gestionar.

Ahora bien, cualquier medida llevada al extremo no suele ser positiva. Puede que exista algún tipo de desarrollo que requiera (para ser mucho más óptimo) que la arquitectura, tecnología, metodología de desarrollo o procedimientos de testing, sean distintos a los establecidos.

La aceptación de esa alternativa no debe quedar a expensas de un capricho o de una decisión de carácter individual sino que debe ser expuesta dentro de las posibles alternativas de solución al conjunto de personas que dirijan el desarrollo y mantenimiento de sistemas de información dentro de la organización.

La cultura del miedo es una mala estrategia, por un lado afecta a la iniciativa de los empleados que buscarán siempre que sea posible la aprobación de un superior antes de realizar una acción o de entregar un trabajo (incluso por encima de los que marquen los procesos establecidos en la organización, si es que existen).

También afectará a su productividad porque saltarán siempre más dudas de las necesarias antes de ejecutar cualquier acción.

La creatividad también se verá afectada ya que existirá temor por salirse de la línea establecida.

Y yo destacaría, sobre todo, que va a afectar a la propia comunicación dentro de la organización y la credibilidad de los datos que se manejan. En un cultura del miedo, donde por cada acción que se entienda incorrecta puede dar lugar a consecuencias severas, quien quiera conservar su posición o su puesto de trabajo, tenderá a maquillar resultados y a ocultar información, haciendo todavía más daño tanto a él como a su propia organización (ver, por ejemplo, el antipatrón “migración de coste“).

Es lógico que si alguien comete errores y los mismos tienen impacto, que estos tengan consecuencias, pero tras un análisis objetivo de qué es lo que ha pasado, conociéndose previamente qué tipo de actuaciones pueden dar lugar a acciones por parte de la organización (que no necesariamente pasan por el despido o por tocarte el variable).

Por tanto, el personal de la organización debe saber que si actúa de manera positiva tendrá recompensas y si actúa de manera negativa (sobre todo negligente), todo lo contrario y también ser consciente de que no se está trabajando en un entorno donde cualquier error, sea del tipo que sea, provocará una reacción en su contra que además será desproporcionada en la mayoría de los casos.

Tan negativo como la cultura del miedo es la cultura de la tranquilidad o la cultura del nunca pasa nada, es decir, pase lo que pase o haga lo que se haga prácticamente nunca tendrá consecuencias ya sea al conjunto de empleados de la organización o a un grupo de empleados concretos de la misma (ver, por ejemplo, el antipatrón “el niñito de oro“).

Hace más de un año que publiqué la lista de los 25 artículos que hasta entonces habían sido los más visitados en mi blog. Hoy os lo actualizo y os pongo los enlaces de acceso, por si hay alguno que no hayáis leído y os interesa hacerlo.

1.-Ahora más que nunca hay que mirar al software libre.
2.-Desarrollo de software. Ciclo de vida RUP (Rational Unified Process)
3.-Orientación al producto
4.-Mantenimiento adaptativo
5.-La importancia de un buen análisis funcional
6.-Desarrollo de software. El analista funcional y el analista orgánico
7.-Mantenimiento correctivo y mantenimiento evolutivo
8.-LCOM4 y la falta de cohesión en las clases
9.-Empresas de desarrollo de software: ¿estructura vertical u horizontal?
10.-La crisis del software
11.-Desarrollo de software. Programación extrema (eXtreme Programming: XP)
12.-Complejidad ciclomática
13.-Un proyecto de construcción de Datamart para la explotación de indicadores de gestión y de estado III
14.-Proyectos de desarrollo de software: La importancia de las métricas y de la documentación
15.-Desarrollo de software. Ciclo de vida iterativo incremental
16.-Certificaciones personales
17.-El paso a producción
18.-PMD: Security – Array is stored directly
19.-Un buen entorno de preproducción
20.-Un proyecto de construcción de Datamart para la explotación de indicadores de gestión y de estado II
21.-¿Cuál es el objetivo de tu empresa este año?
22.-Reducción de tiempos muertos
23.-El papel de los usuarios en un proyecto de desarrollo de software
24.- Lo importante de las Metodologías de desarrollo en un proyecto de desarrollo de software
25.-Desarrollo de software. Método de desarrollo de sistemas dinámicos (DSDM) III

El antipatrón software inflado hace referencia a múltiples circunstancias que se pueden producir en un proyecto de desarrollo de software, aquí os indico algunas de ellas:

– Desarrollar un software sin tener en cuenta una utilización adecuada de los recursos.

Es cierto que el precio de los recursos hardware y los avances tecnológicos dan mucho margen de maniobra, sin embargo esto no quita que el mantenimiento de un CPD sea caro, que en entornos de producción coexisten multitud de aplicaciones que comparten recursos y que un uso inadecuado de los mismos por parte de una puede provocar problemas de disponibilidad y/o rendimiento en las otras.

Por tanto, es un antipatrón desarrollar sin tener en cuenta que es necesario optimizar la utilización de recursos externos al sistema (incluyendo, también, ¿por qué no? recursos software).

Pero no todo es software y hardware. También están las personas y un software desarrollado con alta deuda técnica también se debe considerar un software inflado porque el coste de mantenimiento del mismo será muy importante en relación al costo del mismo. Además, hay que tener en cuenta que muy probablemente el software que presente este tipo de características, hará un uso no adecuado de los recursos hardware y software.

– Desarrollar un software con más funcionalidades de las precisas o con complejidad adicional que no resultaba necesaria. (Otros antipatrones asociados: Ancla de barco, lava seca, complejidad no indispensable y funcionalitis acechante).

Abandonar el objetivo de simplicidad en el desarrollo del producto software lleva a esto, a matar moscas a cañonazos o a desarrollar funcionalidades o módulos que no se van a utilizar o que van a tener un uso residual. Es cierto, que muchas veces, a priori, determinadas funcionalidades parecen ser necesarias y que es tras el uso del sistema por parte del usuario cuando se descartan, sin embargo, en lugar de eliminarlas del producto software aprovechando alguna de las evoluciones del sistema, se dejan en el sistema de información.

Unos amigos me han comentado, tras la lectura del artículo “Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología” que independientemente de que sea importante conocer la naturaleza de los desarrollos ágiles, será siempre mejor que el mayor número de profesionales posibles apliquen esta filosofía de trabajo aunque sea por la simple aplicación de una metodología concreta.

No les quito razón, pero ellos mismos utilizaron una expresión que considero importante: “filosofía de trabajo” que al fin y al cabo sería equivalente a actitud, aunque yo le quitaría la coletilla de trabajo, porque la agilidad no se tiene porque circunscribir a tu labor profesional, la agilidad es extensible a tu forma de actuar y considerar la vida.

Y una filosofía, para ser bien aplicada, es necesario conocer sus fundamentos y eso no lo proporcionan los instrumentos metodológicos.

Además, hay que tener en cuenta que las metodologías no pueden prever todas las contingencias que pueden ocurrir en un proyecto, por lo que resulta fundamental que tras ellas se encuentre un framework que sí puede servir de base para enfocar cualquier problema (independientemente de que acertemos o nos equivocamos) y ese no es otro que los principios ágiles.

Nuestro deseo de implementar sistemas que deleguen funcionalidad en terceros ya implementados, que intercambien información con otros o de utilizar librerías y frameworks que ahorren tiempo de desarrollo, es razonable ya que por un lado disminuye el esfuerzo de desarrollo, lo que nos permite centrarnos en los objetivos del proyecto y por otro permite avanzar en la consecución de un ecosistema de aplicaciones interoperable en una organización, rompiendo la filosofía de sistemas estancos que está implantado en muchas.

Ahora bien este objetivo, que es razonable y deseable no puede pelearse con la realidad y con un objetivo todavía de mayor importancia.

No puede pelearse con la realidad en el sentido de que para delegar funcionalidades en terceros componentes y para interoperar de manera sostenible con otros sistemas, es necesario que los mismos sean estables, además de que los cambios que se realicen en los mismos estén controlados. De lo contrario estaremos ante una situación parecida a un sistema de cañerías de los antiguos, donde se pierda agua en las juntas de las tuberías.

En el caso de los sistemas de información, llegaremos a una situación donde estaremos apagando fuegos más de lo deseable, donde éstos aparecerán cuando menos te lo esperas (y por supuesto, cuando sean más inoportunos) y donde es posible que al final, resolviendo estos problemas terminemos gastando más dinero que el que pretendíamos ahorrarnos (sin contar con los costes tangibles e intangibles de un sistema inestable).

Tampoco puede pelearse con un objetivo mayor que es conseguir igualar o sobrepasar las expectativas del cliente y/o el usuario, no puedes poner en juego las mismas, por el deseo de implementar una dinámica entre sistemas cuando todavía no se ha alcanzado en ellos un nivel suficiente de madurez, como para evitar los problemas descritos en los párrafos anteriores.