archivo

Archivos diarios: diciembre 30, 2011

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.