archivo

Archivo de la etiqueta: minimalismo

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

Presenta el mismo objetivo que el antipatrón ancla de barco, simplificar el sistema de manera que a nivel funcional, a nivel de código o a nivel documental, nos quedemos exclusivamente en cada momento con lo que representa al sistema.

Este antipatrón está orientado básicamente a esos trozos de software que dejan de tener utilidad y que no terminamos de eliminar (métodos o clases que no se utilizan, dependencias con librerías que ya no se usan, trozos de código comentados, objetos de bases de datos que ya no sirven, etc…).

Las ventajas las tendremos en una reducción de la deuda técnica, código más limpio e inteligible, reducción de efectos colaterales, etc…

Conforme va evolucionando un sistema de información, existen determinadas funcionalidades que dejan de tener utilidad y no se utilizan. Lo más normal es que estos módulos se sigan transportando entre una evolución y otra del sistema de información, como además, no paran de crecer las funcionalidades nuevas, que se retocan y que terminan quedando obsoleta tenemos cada vez una mayor carga en la espalda.

Se considera este comportamiento como un antipatrón, ya que además va en contra del principio de conseguir la mayor simplicidad posible en el software. Es como comprar muebles nuevos en casa y no tirar los antiguos.

Eliminando esos módulos liberarás deuda técnica, evitarás posibles incidencias debida a los mismos, no ya por su uso, sino por su posible relación con otros módulos, además de tener que continuar cargando con ellos a nivel de gestión de la configuración.

En muchas ocasiones, considerar algo como una pérdida de tiempo es una cuestión de percepción, es decir, para alguien puede serlo, para otros no (y en medio, toda una escala de grises).

En otros casos, no hay lugar a la interpretación, se trata de pérdidas de tiempo.

Comentan Tom DeMarco y Tim Lister que: “El mayor pecado de la gestión es hacer perder el tiempo a la gente”, esto unido a su reflexión sobre los días de trabajo que se pierden, nos debe hacer pensar sobre algunas decisiones que provocan pérdidas de tiempo (a las que habría que añadir todos los malos hábitos productivos que tengamos a nivel de organización e individual).

Una mala selección de prioridades suponen una pérdida de tiempo, ya que estamos dedicando nuestro esfuerzo y atención (enfoque) a una serie de tareas y funcionalidades que no son críticas, dejando de lado otras que sí lo son. Sobre esto, se podría pensar que al fin y al cabo son cosas que tarde o temprano habría que hacer, sin embargo, la incertidumbre de los proyectos y las limitaciones presupuestarias y de tiempo no aseguran que lo que hemos dejado para después se pueda llegar a hacer, por lo que lo mejor es empezar siempre por lo que realmente es importante y trascendente. A esto, habría que sumar el hecho de lo que se deja de ganar o producir por realizar más tarde las tareas y funcionalidades que realmente tienen un impacto.

Una mala selección de funcionalidades también suponen una pérdida de tiempo. Es importante matizar esto.

El desarrollo de software es de naturaleza evolutiva, donde la aproximación a la solución que satisfaga a las expectativas de los usuarios se llega generalmente (que no siempre) mediante aproximaciones iterativas e incrementales. Bajo esta perspectiva, basada en el feedback del usuario (y de todos los stakeholders en cada iteración), no acertar en la definición de una funcionalidad forma parte en sí de la propia naturaleza del desarrollo y por tanto no se debería considerar una pérdida de tiempo. También es importante matizar esto.

El desarrollo iterativo incremental no es lo mismo que un ensayo y error a ciegas, sino que cada intento debe tener una intención y debe ser resultado de un proceso previo de reflexión. Claro que se puede fallar, claro que pueden ser necesarios ajustes, sin embargo, no se trata de probar por probar porque en este caso sí que estamos perdiendo el tiempo y capacidad para desarrollar otras funcionalidades prioritarias, ya que estamos invirtiendo el esfuerzo en dar vueltas sobre lo mismo.

Es importante también un enfoque minimalista en el desarrollo, evitando funcionalidades que finalmente no se van a utilizar o que van a tener un uso residual. El desarrollo de estas utilidades, también supone una importante pérdida de tiempo (y no solo eso, un lastre para el resto del proceso de desarrollo y el mantenimiento).