Desarrollo de software. Evitar la complejidad. Tratamiento a diferentes escalas.
Un amigo me comentó que efectivamente estaba de acuerdo que las aplicaciones tenían más complejidad funcional de la realmente necesaria y que en muchos casos hasta las funcionalidades más importantes no tenían la solución más simple lo que las hacía más pesadas al usuario (y provocaba que fueran más complejas de mantener) y afectaban a su productividad.
La complejidad se debe tratar a diferentes escalas:
Escala general: Sobre el conjunto del sistema. Reducir la complejidad implica dedicar tiempo a conocer el negocio y a entenderlo en la extensión que afecta al sistema de información. Tratar una parte concreta obviando el resto puede dar lugar (es lo más probable) a una solución más compleja. Pero, ¿cómo casa esto con un enfoque iterativo e incremental?, ¿cómo casa esto en un enfoque que se aleje del ciclo de vida clásico?.
Es perfectamente compatible solo que en los primeros ciclos el peso de tareas que ayuden a comprender el negocio será mayor que el de las dedicadas a programación. Dependiendo de la complejidad del negocio, del conocimiento que se tenga del mismo y de la actitud del área usuaria será mayor el número de ciclos en el que el peso de entender el negocio será mayor que el de la construcción.
Escala de detalle: Podemos haber trabajado en una solución simple a nivel general y después haber realizado una ejecución de la misma que la llene de complejidad. En este caso se trata de buscar la solución más simple para una funcionalidad concreta o (a un poco de más alto nivel), un módulo o un subsistema.
Jummp 