“¿Me podrías construir un avión?” a lo que el constructor contestó: “¿Cómo lo quieres? ¿Grande o pequeño? ¿Bimotor o cuatrimotor? ¿De pasajeros o de carga? ¿Militar o civil?”. Tras unos segundos pensando se dijo. “No sé. Que sea configurable y ya veremos como lo utilizamos”.
Esta respuesta que parece una barbaridad en el caso del avión por el alto coste que supondría hacer un avión multiproposito por no decir que llega a ser inviable por trabajar con materiales físicos, a simple vista parece que no lo es tanto en el desarrollo de software, aunque en realidad también lo es llevarlo de manera sistemática.
No hay que olvidar que las diferentes lógicas y las casuísticas que puede tener una aplicación conllevan un coste aunque sea un objeto intangible. La labor de un analista es conseguir definir lo más exacto posible el sistema para que no haya que realizar cambios en un futuro. Sin embargo, nos podemos encontrar con casos en el que no se conoce el objetivo del proyecto.
El problema crece cuando se pregunta si se debe hacer de la forma A o B y la única respuesta es que sea configurable en vez de esperar o indagar más en el problema para descartar la opción incorrecta. El analista consigue su función que es contemplar los requisitos necesarios del sistema. Pero lo que no se ve es que ha solicitado más requisitos de los necesarios por lo que se realiza desarrollo que no se tuvo que hacer.
Si se sigue una política de todo configurable antes la duda a medio/largo plazo se llegará a un software que se desconoce con exactitud que debe hacer no pudiendo resolver las consultas de manera inmediata y se tendrá de un enorme código para un comportamiento simple dificultando la compresión del código fuente.
Por ello, antes de decidir desarrollar que se comporte de forma A o B eligiendo una de ellas de manera configurable, piensa si en realidad necesitarás A y B o solo uno de ellos.