archivo

Archivo de la etiqueta: funcionalitis acechante

No hace mucho, estuve conversando con un usuario que quería hacer modificaciones significativas en un sistema de información, algunas de ellas eran totalmente razonables y otras, las más complicadas, se trataban de situaciones que se podían dar, pero que tras analizar la situación se podían producir una o dos veces al año (si acaso) y que en el caso de que se produjeran su no tratamiento en el sistema de la manera más óptima, no tendría consecuencias significativas.

Después de analizar con el usuario, los pros y los contras (incremento de la complejidad del sistema, esfuerzo (dinero) necesario para llevarlo a cabo, etc…), dijo finalmente “es cierto que si estos casos se producen se van dar en contadas ocasiones y no merece la pena hacer los cambios en la aplicación”.

Por tanto, en este caso, lo más productivo fue tomar la decisión de no implementar funcionalidades que no eran absolutamente necesarias (y no caer en antipatrones como por ejemplo “funcionalitis acechante“) y dedicar la atención y esfuerzo a aquellas que sí eran importantes.

Existe mucho respeto en entrar a valorar con los usuarios sus propias peticiones, pero es algo que es necesario y que el mismo usuario o cliente agradecerá en la mayoría de los casos (le ahorrarás dinero y tendrá un producto de mayor calidad). Es cierto que muchas veces no te harán caso, incluso en otras les podrá sentar mal, pero poniendo en una balanza beneficios y riesgos, merece mucho la pena intentarlo.

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).

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.

Otro antipatrón relacionado con la falta de simplicidad en la solución obtenida.

Son ya unos cuantos. Para quienes no crean que las mejores soluciones son las más simples que resuelvan un problema, creo que debería dar lugar, como menos, a reflexión.

Y os lo dice alguien que alguna que otra vez ha provocado este antipatrón por el deseo de agradar al usuario y que después se ha tenido que arrepentir por el esfuerzo invertido en hacer algo que no ha aportado prácticamente nada y que encima ha provocado problemas, es decir, el deseo por agradar a algún usuario provocó, aunque sea temporalmente, desagradar a otros y encima se requirió bastante trabajo para implementar las funcionalidades.

No se trata de no hacer lo que pide el usuario, sino de que este conozca las implicaciones que tiene el desarrollo que solicita y el coste que tiene consigo, con el objeto de que piense bien si realmente va a necesitar lo que está pidiendo.

Este antipatrón, va más allá de añadir funcionalidades que se podrían obviar, ya que hace referencia sobre todo a que esas funcionalidades se incorporen a costa de otros factores, como por ejemplo la calidad (que ya de por sí se ve afectada directamente por el incremento de la deuda técnica que tienen aparejadas esas nuevas funcionalidades que no se van a utilizar).